Мы в «Первой Форме» развиваем BPM-систему на базе low-code для автоматизации бизнес-процессов: документооборота, CRM, HR, PM и Service Desk. Мы работаем с B2B-клиентами, у которых платформа живет внутри реальных процессов компании: согласований, заявок, договоров, кадровых маршрутов, сервисных сценариев и внутренних регламентов. В такой модели у нас постоянно появляется поток запросов на доработку системы.

На первый взгляд кажется, что основная сложность начинается там, где нужно реализовывать изменения в конфигурации. На практике мы увидели другое узкое место. Самая дорогая и плохо масштабируемая работа начинается раньше: в момент, когда нужно превратить клиентскую формулировку в точную постановку для внедрения. В статье расскажем, как упорядочили этот процесс с помощью AI.

В чём состояла проблема

Типичный клиентский запрос выглядит нормально с точки зрения бизнеса, но недостаточно определенно с точки зрения внедрения. Например: «сделайте согласование удобнее», «добавьте контроль перед оплатой», «пусть система напоминает ответственному», «сделайте как в другом процессе», «уберите лишние поля на этапе».

Клиент не обязан формулировать запрос на языке категорий, полей, переходов, ролей и правил автоматизации. Он описывает проблему так, как видит ее в работе. Поэтому на вход команда получает не техническое задание, а намерение, ожидание или жалобу. Далее нужно понять, о какой сущности идет речь, где именно находится нужный этап, какие роли участвуют в процессе, какие поля уже существуют, какие проверки работают сейчас, какие ограничения есть у этой конфигурации и что изменится в соседних сценариях. 

Иными словами, проблема заключалась не в нехватке идей и не в сложности самой настройки. Проблема заключалась в том, что между бэклогом и внедрением существовал трудоемкий участок, где сильный специалист фактически выполнял роль переводчика между тремя языками: клиента, конкретной клиентской конфигурации и исполнимых изменений.

Этот этап дорого стоит по времени, зависит от опыта специалистов и плохо масштабируется. Если входные формулировки остаются сырыми, команда тратит много ресурса на уточнения, сверку контекста, поиск аналогов и снятие двусмысленности.

Что такое для нас ЧТЗ

Нам было важно не просто ускорить обсуждение задач, а получить понятный и воспроизводимый результат. Таким результатом стало ЧТЗ, то есть частное техническое задание.

В нашем контексте ЧТЗ не означает большой бюрократический документ на десятки страниц. У нас это по сути атомарная, точная и исполнимая постановка на изменение конфигурации. Это такой формат, в котором уже понятно, что именно нужно менять, где это менять, при каких условиях должна работать новая логика, кто участвует в процессе и какой результат система должна выдавать.

Разница между обычной формулировкой и ЧТЗ принципиальна. Фраза «улучшить согласование» не задает объект работы, а вариант «в категории согласования договоров добавить этап повторной проверки, сделать обязательным поле причины возврата, ограничить переход для роли согласующего и отправлять уведомление инициатору при отклонении» уже превращает намерение в конкретную единицу работы. 

Как в процессе появился AI

Вокруг AI много ожиданий, связанных с полной автоматизацией. Но для производственного контура такой подход даёт больше рисков, чем пользы. Если просто отдать модели сырую задачу и попросить придумать решение, она начнет достраивать недостающий контекст. В настройке корпоративной системы это опасно, потому что ошибка возникает не только в формулировках, но и в самих изменениях.

Поэтому мы используем AI как механизм подготовки структурированного черновика постановки на основе конкретных источников. Он позволяет быстро собрать контекст, сопоставить сущности, вытащить релевантные ограничения, опереться на похожие примеры и привести все это к единому формату. Иными словами, мы автоматизируем не принятие решения за эксперта, а подготовку материала, с которым эксперту проще и быстрее работать.

Такой подход оказался гораздо устойчивее. Он лучше соответствует реальному устройству внедрения и снимает с команды не ответственность, а самую дорогую часть рутины.

Как устроен наш пайплайн подготовки ЧТЗ

На входе в систему приходит клиентская задача — сырой текст из поля «Подробное описание» задачи бэклога, написанный бизнес-языком клиента или бизнес-аналитика. Например, это может быть такой запрос: «Сделайте согласование удобнее. Сейчас согласующий не понимает, почему документ вернули, и приходится переписываться в чате. Нужно, чтобы было понятно сразу в системе».

Далее система проходит следующие шаги:

1. Сортировка. Система классифицирует задачу: является ли она конфигурационной. Если это баг отчёта, ошибка интеграции, UI-баг SPA или массовая ручная работа — промпт выдаёт вердикт с типом и адресатом, не генерируя ЧТЗ. Это предотвращает бесполезную генерацию на 54% бэклога, который не относится к конфигурации. В нашем случае это конфигурационная задача, категория «Согласование договоров».

2. Подтягивание контекста. Система подгружает конфигурацию клиента

   • Категория: Согласование договоров (SubcatID 5574)

   • Состояния: Черновик → На согласовании → Согласовано → Отклонено

   • ДП: Статус согласования, Комментарий согласующего, Причина отклонения

   • Переход «На согласовании → Отклонено» сейчас не требует обязательного комментария

   • Уведомления: инициатор получает письмо при смене статуса, но без деталей.

3. Генерация ЧТЗ. AI переводит описание в формат ЧТЗ по заданным правилам. Выход состоит из двух секций: нужные новые категории, параметры, состояния и права; нумерованные правила. Черновик от AI будет выглядеть так:

   Сделать ДП «Причина отклонения» обязательным при переходе «На согласовании → Отклонено» Добавить ДП «Комментарий согласующего» (текст, 500 символов) в карточку задачи, видимый на этапе «Отклонено» Переименовать ДП «Комментарий согласующего» → «Пояснение к решению» [УТОЧНИТЬ: правильно ли название?].

   Дополнительно AI-ассистент прописывает нужные автоматизации:

   При переходе «На согласовании → Отклонено». Фильтр: ДП «Причина отклонения» не заполнено. Действие: блокировать переход, показать сообщение «Укажите причину отклонения».

   При переходе «На согласовании → Отклонено». Фильтр: ДП «Причина отклонения» заполнено. Действие: установить ДП «Дата решения» = текущая дата.

   После перехода «На согласовании → Отклонено». Действие: отправить уведомление инициатору с шаблоном «Документ отклонен. Причина: {ДП Причина отклонения}. Пояснение: {ДП Пояснение к решению}».

   [УТОЧНИТЬ]: Клиент пишет «согласующий не понимает, почему документ вернули» — это про инициатора (кто отправил на согласование) или про самого согласующего (кто принимает решение)? Влияет на то, кто видит поле «Причина».

4. Человеческая валидация. Черновик ЧТЗ попадает к бизнес-аналитику или руководителю проекта. Ответственный видит маркер [УТОЧНИТЬ] и возвращает уточнение: «Речь про инициатора. Согласующий — тот, кто отклоняет, он и так знает причину. Нужно, чтобы инициатор видел причину в своей задаче». , который проверяет корректность, уточняет спорные места и утверждает итоговую постановку.

Готовое ТЗ со всеми уточнениями отправляется в отдел внедрения, где с ним уже можно работать.

Что изменилось для команды

После внедрения такого подхода мы получили эффект не только в скорости подготовки задач. Выросло качество входа для следующего этапа работы.

Стало меньше двусмысленности. Задача приходит к специалисту уже в более структурированном виде, а не в виде свободного пересказа клиентской боли. 

Сократилось число возвратов на уточнение. Система заранее собирает значимую часть контекста.

Снизилась зависимость от конкретного сильного эксперта, который раньше держал весь переводческий слой у себя в голове. Команде стало проще передавать задачи между людьми. Когда постановка собирается по более стабильным правилам, снижается стоимость переключения и повышается повторяемость качества. 

На пилоте из 13 задач сортировка сработала корректно во всех случаях, ложных ЧТЗ сгенерировано не было.

При этом человек из процесса не исключается. Во-первых, клиентский контекст почти всегда содержит нюансы, которые не лежат на поверхности, и их нужно уточнять. Во-вторых, даже хороший черновик нужно соотнести с реальными ограничениями площадки и приоритетами конкретного проекта. В-третьих, часть решений по определению требует экспертной оценки, а не только структурирования информации.

Поэтому надежность этого подхода строится на правильно ограниченной роли модели. Мы не просим ее выносить финальное решение, но она должна качественно подготовить материал для человека, который это решение принимает и валидирует.

Для компании это важно не только как локальная оптимизация, но и как шаг к более зрелой производственной модели. 

Выводы

Этот кейс важен для нас не только как внутренняя оптимизация процесса подготовки доработок. Он показывает ещё принцип применения AI в корпоративных системах — для формализации задачи на входе.

Поэтому один из самых продуктивных сценариев применения AI в enterprise состоит не в том, чтобы сразу автоматизировать последний шаг, а в том, чтобы стабилизировать самый дорогой слой подготовки. Если компания умеет превращать хаотичный вход в понятные, проверяемые и воспроизводимые единицы работы, она ускоряет не только отдельную операцию, но и весь контур исполнения.

Для нас переход к ЧТЗ стал именно таким сценарием. В результате мы получили более понятный вход для команды, более стабильное качество постановок и более управляемый процесс подготовки изменений. Для нас это история о том, как с помощью AI можно упорядочить один из самых трудоёмких участков enterprise-внедрения: перевод человеческого запроса в исполнимую конфигурационную задачу.