Продолжаем сценарии, где ИИ помогает IT Интегратору
В будущей (но опубликованной ранее) лабораторной работе №3 мы пытались понять, можно ли автоматизировать выполнение процессов без привлечения офисных сотрудников. Видео или статья как это было.
Еще раз - "лабораторные работы" это работающие стенды для автоматизации работы IT интегратора с использованием программно-методологического комплекса ERP-tools и безграничных возможностей программирования от LLM и локальными LLM
На этот раз мы решили взять другую задачу. Она постоянно возникает у 1С-интеграторов и, казалось бы, гораздо лучше подходит для применения LLM.
Всего у нас наметилось 3 последовательные группы задач, которые образуют львиную часть операционного процесса IT интегратора. Номера агентов отражают не их очередность, а именно начало их разработки.
Агент№2. Менеджер пресейлов
Агент№3. Процессный менеджер
Агент№1. Проектный аналитик
Подготовка коммерческого предложения на внедрение 1C ERP
Клиент присылает ТЗ или короткий бриф с описанием задач и ожиданий от внедрения 1C ERP. Нужно его прочитать, понять требования, разобраться в текущей системе, найти интеграции, определить функциональные рамки, прикинуть состав команды, посчитать трудозатраты, построить график и в конце сделать файл коммерческого предложения.
То есть вроде бы идеальная работа для искусственного интеллекта. Прямо хочется закинуть эти файлы в Чат подороже и на выходе увидеть чудо - красивое оформленное КП с оценками, которые безусловно позволят одержать победу. Можно бронировать место на конференции Infostart с докладом "Я заставил LLM угадывать правильную цену проекта".
Мы решили проверить, что происходит когда мы накапливаем знания о прошлых проектах, имеем описанную методологию (и не даем каждому РП придумывать собственную), в общем, вкладываем усилия в автоматизацию и стандартизацию.
Что автоматизируем
Как правило, лид приносит небольшой файл с кратким описанием видения проекта заказчиком. На основании этого документа и нужно сделать подробное КП.
Обычно я участвовал в таком процессе работы
Отдел продаж передает лид руководителю портфеля.
Руководитель портфеля находит руководителя проекта и просит заполнить excel-калькулятор.
Через недельку заполненный калькулятор передается в отдел продаж.
Отдел продаж готовит драфт презентации тоже где-то через недельку.
РП должен уточнить прочие параметры в презентации, для этого нужно перечитать исходные файлы (а для начала найти их, а лучше заново запросить), чтобы выявить ограничения
Итоговый вариант отправляется заказчику.
Ничего страшного - есть не выиграем. Там "мутный" клиент был.
Ничего плохого в этом процессе нет, просто он занимает 2-3 недели и очевидно - процесс дорого обходится Интегратору и эффективно РП может участвовать не более чем 2-3 пресейлах одновременно, что физически ограничивает возможную воронку продаж.
А потом клиент говорит:
«А теперь покажите вариант без склада»,
"А есть такое же, но с перламутровыми пуговицами?"
— начинается второй круг.
Мы поставили цель реализовывать этот процесс за пару часов, чтобы добиться выставления КП за 24 часа с момента получения первичного обращения. Фактически говорим о Фабрике пресейлов по переходу на ERP, чтобы дать возможность интегратору участвовать в 5 раз большем количестве пресейлов и повысить вероятность выигрыша минимум на 50% (пока это гипотезы).
«Дано» для лабораторной работы
Очевидно, что для правильной оценки нужно определение функциональных рамок, ограничений и дорожные карты. Эти подсистемы присутствуют в ERP-tools, то есть система сможет стать шаблоном для проектов разного типа.
Оставалось сделать инструмент, который сможет взять документы заказчика и провести РП через эту методику. В качестве ожидаемого результата мы сформулировали задачу достаточно жёстко. Хотелось получить не просто текст:
«По моему мнению, внедрение будет стоить 25 миллионов, но давай предложим 35».
Нам нужен был нормальный проектный результат. Чтобы после работы с документами появился заполненный калькулятор, из него получился график с трудозатратами, а затем данные можно было передать в ERP-tools и использовать при подготовке коммерческого предложения, а в случае победы - накопленные данные трансформировались в начальные настройки проекта без необходимости снова погружаться в вопрос "а что мы там выиграли?"
При этом форма калькулятора, поддерживающая проектную методологию, была создана еще ранее (Ссылка). Поэтому создание Агента№2 - "Менеджер пресейла" происходит не в чистом поле, а над существующей инфраструктурой и главное - вообще без методических вопросов - то есть нужно просто соединить калькулятор и ERP-tools и попробовать использовать LLM.
Решение
Мы взяли за основу существующий калькулятор и добавили туда LLM модель, чтобы помогал извлечь данные каждого шага из файлов заказчика.
Организация пресейлов внутри ERP-tools
Немного об организации пресейлов в ERP-tools. Программа позволяет хранить множество Проектов обособленно. Но когда мы входим в пресейл мы не заводим отдельный проект "Завод ЖБИ", так как вероятность победы - не 100%. Мы используем отдельные проекты "Пресейлы ERP", "Пресейлы ЗУП" и так далее. И внутри каждого проекта мы заводим нового "Клиента" (company) и рисуем его дорожные карты (варианты КП) обособленно. Если в тендере добиваемся победы, то уже создаем отдельный Проект и переносим контент из проекта Пресейлы.
Этот подход позволяет в проекте Пресейсы ERP хранить эталонные данные, например, для 1 шага - перечень эталонных анкетных вопросов, а для 12 шага - перечень эталонных "переменных" для заполнения текста коммерческого предложения.
Подготовка
Для начала работы мы загружаем полученные файлы от заказчиков (это может быть и расшифровка интервью) в калькулятор.
При выполнении каждого шага где работает LLM возможна и необходима экспертиза человека и корректировка данных. Мы еще не Palantir.
Шаг 1. Анкетные данные
На 1 шаге мы заполняем анкету клиента, а показатели мы импортируем из ERP-tools из проекта "Пресейлы ERP" (на картинках это проект "ИИ-Агенты в ep-tools"), достигая стандартизации показателей. Стандартизация - это путь к повторному использованию данных на новых проектах.
Нажимаем кнопку "Проанализировать документы для текущего шага" и LLM начинает изучение этих документов и пытается найти там ответы на анкетные вопросы
И опять никакого чуда. Довольно простая задача и LLM находит эти данные и подставляет их в текущую таблицу. Там, где РП читал бы документ полчаса и может быть и упустил их, LLM справляется за секунды.
Шаг 2. Бизнес-функциональные требования
Пока не учили LLM извлекать эти данные. Основная проблема - нет подходящего пресейла, где бы заказчик сделал эту работу качественно. В будущем - обязательно подключим
Шаг 3. Текущий и предполагаемый информационный ландшафт
Аналогичный поиск указанных в документации информационных систем, которые есть, системы которые уходят и приходят.
Шаг 4. Текущие интеграционные потоки
LLM выявляет описанные интеграции между системами, их объекты (если есть), направление обмена.
Шаг 5. Будущие интеграционные потоки
LLM выявляет предполагаемые потоки, в т.ч. если на место системы приходит другая (ERP вместо УПП), то предполагает, что у новой системы сохранятся потоки с существующими.
Шаг 6. Слои учета
"Эталонные" слои мы берем из ERP-tools, а LLM ищет их упоминание в тексте.
Шаг 7. Функциональные разделы
Аналогично предыдущему шагу "эталонные" топики мы берем из ERP-tools, а LLM ищет их упоминание в тексте. При необходимости корректируем данные.
Шаг 7.5. Дерево процессов
Данный шаг пока не используется, но он позволяет еще на уровне КП предложить клиенту готовую структуру бизнес-процессов, на основании опыта уже реализованных проектов. Мне кажется это может увеличить шансы на победу, если заказчик поймет - что он не будет для нас первенцем в этой отрасли. А чтобы отрисовать схему процессов для клиента данной отрасли у нас в доступности есть ERP-tools, где уже реализованные проекты с актуальным процессами лежат и ждут повторного использования данных.
Шаг 8. Функциональные рамки проекта
Наиболее ценная таблица фактически показывающая функциональные рамки проекта. Пока заполняется человеком, но если ТЗ от заказчика будет содержать такие данные, то сразу же подключим LLM. Обратите внимание, что когда вас просят "внедрить планирование" - нужно указать - планирование в каких разделах? Это значительно меняет объем проекта.
Основная задача этой таблицы - оградить вас от ИС и интеграций, которые неожиданно нарисуются в будущем. Ну и если у вас будут отмечена флажками вся карта "морского боя" - то вы проиграли:) Проект выглядит слишком сложным.
Шаг 9. Команда
На этом шаге LLM не применяется - просто мы загружаем рекомендованную вашей компанией команду на выполнение подобного проекта. Цену и себестоимость указывает человек
Шаг 10. Рабочие часы по месяцам
Также обошлось без LLM - загружаем с публичного сайта производственный календарь на следующий год, чтобы сделать расчет максимально аккуратным.
Шаг 11. Этапы и итоговый расчет
Начинаем оценку проекта. На первом этапе загружаем перечень эталонных этапов из ERP-tools для данного типа проекта, указываем длительность и сдвиг этапов. LLM нам не нужна - этапы все знают.
РП отрисовывает состав команды на каждый месяц, позволяет сбалансировать команду, если этапы накладываются друг на друга, крутит-вертит, пытается уложиться в бюджет, сроки.
Этот шаг остается на совести РП, у нас есть понимание как LLM может помочь - только сравнением проектов аналогичных предприятий аналогичной отрасли похожих анкетных данных. Но это "честный" анализ, когда все данные есть. Допустим - пищевое производство, выручка 5-10 млрд. рублей, MES + ERP - обычно стоит Х миллионов... Хотя все ждут что LLM из космоса достанет оценку.
Шаг 12 Данные для КП
Здесь получаем перечень данных, необходимых ERP-tools, чтобы сформировать красивое коммерческое предложение. В теории LLM может на основании других пресейлов предзаполнить данные, чтобы они было лаконичными, без ошибок и повышали конверсию.
На стороне ERP-tools
Нажимаем кнопку Выгрузить и в ERP-tools создается экземпляр дорожной карты
Создаются ветки дорожных карт в иерархии клиента. Таким образом, можно сохранить несколько вариантов предложения. Внутри каждого элемента подробная информация об экономике, потребности в сотрудниках и исходные файлы для калькулятора.
А также картинки для КП, анкетные данные и переменные для КП
Остается последний шаг - запустить генерацию документа
Сколько понадобилось времени, чтобы сформировать файл КП?
Если работать в тестовом режиме (не перечитывать документацию), то работа с калькулятором занимает примерно 10 минут, из них половина - это моделирование сроков и длительности этапов, состава команды. Раньше заполнение калькулятора вручную можно было оценить в 1 час - то есть LLM помощник действительно помогает, при этом он действует аккуратнее, так как часто такие документы читаются человеком "по диагонали".
Далее была работа в ERP-tools по воссозданию структуры дорожной карты. если калькулятор под руками, то его ручной перенос требовал не менее 60 минут - в частности. из-за необходимости в каждом этапе записывать отдельными строками каждого сотрудника на весь срок проекта. И если честно - выполнять эту работу было сложно и ее мы не делали. То есть мы сознательно не накапливали базу знаний о проектах, где мы проиграли. Молодцы. Теперь мы не можем попросить LLM ее проанализировать и, возможно, найти истинную причину.
Сейчас эта выгрузка происходит за пол-секунды, причем обновление данных - ранее занимало большое количество времени, ведь нужно было подвигать всех сотрудников.
КП и раньше формировалось автоматически, как и сейчас, но перед каждым обновлением нужно было аккуратно обновить данные для КП, а также картинки. Сейчас этой работы нет и в целом от получения файлов до генерации КП проходит не более 15 минут.
Далее нужно распечатать КП, взять красный маркер и начать читать исходные документы и отмечать в КП - правильно ли указано или нет. Ну это не более 1 часа. При необходимости почти мгновенно подгрузить проект обратно в калькулятор, поправить и повторно выгрузить в ERP-tools.
А теперь самое интересное: где здесь LLM?
На этом месте мы посмотрели на получившуюся систему и задали себе тот же вопрос, который задаем в любой лабораторной работе.
А где здесь искусственный интеллект?
Он действительно есть.
Он читает документы. Находит нужные фрагменты. Извлекает значения. Предлагает соответствия. Может объяснить, почему считает найденный фрагмент относящимся к конкретному полю. Довольно полезный ассистент вечно занятому руководителю проектов, который просто может запутаться в разных документов разных заказчиков.
Но если посмотреть на весь процесс целиком, становится видно, что LLM не делает большую часть работы. Нет "вау эффекта" - делает много по-мелочи, как настоящий работяга-сотрудник.
Она не считает график. Не рассчитывает стоимость. Не управляет производственным календарём. Не хранит варианты проекта. Не контролирует права доступа. Не формирует саму структуру дорожной карты. И это оказалось хорошей новостью - мы опять не придумали "черный ящик, который потребляет токены и скрывает логику".
И главное - все происходит внутри стандартной методологии. Все артефакты - процессы, слои, требования, топики - зафиксированы, описаны и понимаются всеми участниками процесса идентично. Таким образом LLM не должна перепридумывать определения, а выполнять достаточно простую работу. Или, например, нет необходимости генерировать макеты КП через LLM - если есть автоматизация.
Вывод - берем результаты в долгосрочную работу с реальными кейсами и приглашаем присоединяться к нам.
Что использовали в лабораторной работе
ERP-tools
Хранение стандартных анкет
Хранение стандартных реквизитов в текст коммерческого предложения
Хранение веток "дорожных карт", загруженных из Калькулятора
Автоматическая генерация файла коммерческого предложения на основании шаблона
Web-приложение - калькулятор
Django
Ollama/Qwen
Если интересно посмотреть на сам стенд или обсудить результаты эксперимента — пишите в комментариях.
