Мы в «Первой Форме» развиваем BPM-систему на базе low-code для автоматизации бизнес-процессов: документооборота, CRM, HR, PM и Service Desk. Мы работаем с B2B-клиентами, у которых платформа живет внутри реальных процессов компании: согласований, заявок, договоров, кадровых маршрутов, сервисных сценариев и внутренних регламентов. В такой модели у нас постоянно появляется поток запросов на доработку системы.
На первый взгляд кажется, что основная сложность начинается там, где нужно реализовывать изменения в конфигурации. На практике мы увидели другое узкое место. Самая дорогая и плохо масштабируемая работа начинается раньше: в момент, когда нужно превратить клиентскую формулировку в точную постановку для внедрения. В статье расскажем, как упорядочили этот процесс с помощью AI.
В чём состояла проблема
Типичный клиентский запрос выглядит нормально с точки зрения бизнеса, но недостаточно определенно с точки зрения внедрения. Например: «сделайте согласование удобнее», «добавьте контроль перед оплатой», «пусть система напоминает ответственному», «сделайте как в другом процессе», «уберите лишние поля на этапе».
Клиент не обязан формулировать запрос на языке категорий, полей, переходов, ролей и правил автоматизации. Он описывает проблему так, как видит ее в работе. Поэтому на вход команда получает не техническое задание, а намерение, ожидание или жалобу. Далее нужно понять, о какой сущности идет речь, где именно находится нужный этап, какие роли участвуют в процессе, какие поля уже существуют, какие проверки работают сейчас, какие ограничения есть у этой конфигурации и что изменится в соседних сценариях.
Иными словами, проблема заключалась не в нехватке идей и не в сложности самой настройки. Проблема заключалась в том, что между бэклогом и внедрением существовал трудоемкий участок, где сильный специалист фактически выполнял роль переводчика между тремя языками: клиента, конкретной клиентской конфигурации и исполнимых изменений.
Этот этап дорого стоит по времени, зависит от опыта специалистов и плохо масштабируется. Если входные формулировки остаются сырыми, команда тратит много ресурса на уточнения, сверку контекста, поиск аналогов и снятие двусмысленности.
Что такое для нас ЧТЗ
Нам было важно не просто ускорить обсуждение задач, а получить понятный и воспроизводимый результат. Таким результатом стало ЧТЗ, то есть частное техническое задание.
В нашем контексте ЧТЗ не означает большой бюрократический документ на десятки страниц. У нас это по сути атомарная, точная и исполнимая постановка на изменение конфигурации. Это такой формат, в котором уже понятно, что именно нужно менять, где это менять, при каких условиях должна работать новая логика, кто участвует в процессе и какой результат система должна выдавать.
Разница между обычной формулировкой и ЧТЗ принципиальна. Фраза «улучшить согласование» не задает объект работы, а вариант «в категории согласования договоров добавить этап повторной проверки, сделать обязательным поле причины возврата, ограничить переход для роли согласующего и отправлять уведомление инициатору при отклонении» уже превращает намерение в конкретную единицу работы.
Как в процессе появился AI
Вокруг AI много ожиданий, связанных с полной автоматизацией. Но для производственного контура такой подход даёт больше рисков, чем пользы. Если просто отдать модели сырую задачу и попросить придумать решение, она начнет достраивать недостающий контекст. В настройке корпоративной системы это опасно, потому что ошибка возникает не только в формулировках, но и в самих изменениях.
Поэтому мы используем AI как механизм подготовки структурированного черновика постановки на основе конкретных источников. Он позволяет быстро собрать контекст, сопоставить сущности, вытащить релевантные ограничения, опереться на похожие примеры и привести все это к единому формату. Иными словами, мы автоматизируем не принятие решения за эксперта, а подготовку материала, с которым эксперту проще и быстрее работать.
Такой подход оказался гораздо устойчивее. Он лучше соответствует реальному устройству внедрения и снимает с команды не ответственность, а самую дорогую часть рутины.
Как устроен наш пайплайн подготовки ЧТЗ
На входе в систему приходит клиентская задача — сырой текст из поля «Подробное описание» задачи бэклога, написанный бизнес-языком клиента или бизнес-аналитика. Это может быть одно предложение, 3–5 предложений, пакетный список из 5–15 пунктов или полное описание бизнес-процесса со скриншотами. Далее система проходит следующие шаги:
Сортировка. Система классифицирует задачу: является ли она конфигурационной. Если это баг отчёта, ошибка интеграции, UI-баг SPA или массовая ручная работа — промпт выдаёт вердикт с типом и адресатом, не генерируя ЧТЗ. Это предотвращает бесполезную генерацию на 54% бэклога, который не относится к конфигурации.
Подтягивание контекста. Система подгружает конфигурацию клиента: категории, дополнительные параметры с ID, состояния и переходы, группы пользователей, существующие SMART-скрипты. Это критически важно, потому что один и тот же запрос «сделать согласование удобнее» означает разные изменения на разных площадках.
Генерация ЧТЗ. AI переводит описание в формат ЧТЗ по заданным правилам. Выход состоит из двух секций:
Нужные новые категории, параметры, состояния, права. Например: «Создать ДП “Тип работы”» или «Переименовать ДП “Статус оплаты” → “Статус выплаты”».
Нумерованные правила в формате: событие + переход + фильтр + действие + параметры. Например: «После перехода Оценка — Согласование. Фильтр: ДП Бренд = ВкусВилл. Действие: установить ДП Срок подписи = 3 дня». Или: «После смены статуса Новый пакет запрашивать динамическую подпись Архивариуса (группа 1068, первый пользователь) с одной резолюцией Подписать».
Промпт получает имена в ID, использует словари событий, действий и фильтров. Если ID не найден — помечает [ID не найден]. Если описание неоднозначно — [УТОЧНИТЬ], не додумывая.
Последний, четвёртый шаг — Человеческая валидация. Черновик ЧТЗ попадает к специалисту отдела внедрения, который проверяет корректность, уточняет спорные места и утверждает итоговую постановку.
Что изменилось для команды
После внедрения такого подхода мы получили эффект не только в скорости подготовки задач. Выросло качество входа для следующего этапа работы.
Стало меньше двусмысленности. Задача приходит к специалисту уже в более структурированном виде, а не в виде свободного пересказа клиентской боли.
Сократилось число возвратов на уточнение. Система заранее собирает значимую часть контекста.
Снизилась зависимость от конкретного сильного эксперта, который раньше держал весь переводческий слой у себя в голове. Команде стало проще передавать задачи между людьми. Когда постановка собирается по более стабильным правилам, снижается стоимость переключения и повышается повторяемость качества.
На пилоте из 13 задач сортировка сработала корректно во всех случаях, ложных ЧТЗ сгенерировано не было.
При этом человек из процесса не исключается. Во-первых, клиентский контекст почти всегда содержит нюансы, которые не лежат на поверхности, и их нужно уточнять. Во-вторых, даже хороший черновик нужно соотнести с реальными ограничениями площадки и приоритетами конкретного проекта. В-третьих, часть решений по определению требует экспертной оценки, а не только структурирования информации.
Поэтому надежность этого подхода строится на правильно ограниченной роли модели. Мы не просим ее выносить финальное решение, но она должна качественно подготовить материал для человека, который это решение принимает и валидирует.
Для компании это важно не только как локальная оптимизация, но и как шаг к более зрелой производственной модели.
Выводы
Этот кейс важен для нас не только как внутренняя оптимизация процесса подготовки доработок. Он показывает ещё принцип применения AI в корпоративных системах — для формализации задачи на входе.
Поэтому один из самых продуктивных сценариев применения AI в enterprise состоит не в том, чтобы сразу автоматизировать последний шаг, а в том, чтобы стабилизировать самый дорогой слой подготовки. Если компания умеет превращать хаотичный вход в понятные, проверяемые и воспроизводимые единицы работы, она ускоряет не только отдельную операцию, но и весь контур исполнения.
Для нас переход к ЧТЗ стал именно таким сценарием. В результате мы получили более понятный вход для команды, более стабильное качество постановок и более управляемый процесс подготовки изменений. Для нас это история о том, как с помощью AI можно упорядочить один из самых трудоёмких участков enterprise-внедрения: перевод человеческого запроса в исполнимую конфигурационную задачу.