Регламент для AI-агента: как описать процесс

TL;DR: Обычный регламент в Word написан для человека, который сам додумает недостающее. AI-агент не додумывает: он спотыкается на каждом пробеле в описании. Чтобы ИИ выполнял процесс, в регламенте нужны явные триггеры, формат передачи на стыках между отделами, границы ответственности с точками эскалации и проверяемый критерий «сделано».

Ко мне приходят с одинаковой формулировкой: «у нас всё описано, давайте посадим на это ИИ». Открываю регламент. Двенадцать страниц в Word, заголовок «Положение об обработке заявок», дата последней правки полтора года назад. Читаю первый абзац: «Менеджер обрабатывает поступившую заявку в установленном порядке и при необходимости согласует с руководителем».

Этот текст бесполезен для агента. Не потому что плохо написан. Написан он как раз гладко. Бесполезен потому, что адресован человеку, у которого в голове уже лежит половина процесса.

Почему человек читает регламент, а ИИ нет

Дайте этот же абзац менеджеру, который проработал в компании хотя бы полгода. Он прочитает «при необходимости согласует с руководителем» и достроит остальное сам. Он помнит, что «необходимость» это сумма выше 300 тысяч. Знает, что руководитель это Марина, а если Марина в отпуске, то Сергей. Понимает, что «согласовать» означает написать в чат и дождаться плюса. Всё это нигде не записано. Это осело у него в памяти после десятков прошлых заявок, пары разговоров на кухне и одного скандала, когда отгрузили без согласования и попали на возврат.

Регламент дал ему контур. Остальное он добрал из контекста.

У AI-агента этого контекста нет. Он берёт ровно то, что написано, и ни буквой больше. «При необходимости» для него не команда, а дыра. На этой дыре он либо встанет и будет ждать, либо придумает себе правило сам. Придумает, скорее всего, не то.

Я называю это зазором между текстом и исполнимым процессом. Обычный регламент пересказывает процесс тому, кто и так примерно понимает, как всё устроено. Исполнимое описание разложено до уровня, на котором догадываться уже не о чем.

Четыре места, где агент проваливается

За шесть лет я разобрал не одну сотню регламентов. Дыры почти всегда сидят в одних и тех же четырёх местах.

1. Триггеры и условия, выраженные числом

Регламент должен начинаться не с «менеджер обрабатывает заявку», а с ответа на простой вопрос: что именно запускает процесс и в какой момент. Письмо на конкретный ящик? Новая строка в таблице? Сообщение в чате с определённым тегом?

Дальше каждое ветвление надо выразить через проверяемое условие. Не «при крупной сумме», а «если сумма больше 300 000 рублей». Не «срочные заявки в приоритете», а «если в поле „срок" дата ближе трёх рабочих дней». Человек терпит расплывчатость и сам подставляет границу. Агенту границу надо дать, и такую, которую он сможет проверить.

2. Кто передаёт что и в каком формате

Вот здесь больнее всего, и здесь же дороже всего. Процесс почти никогда не живёт внутри одного отдела. Заявка идёт от продаж к закупкам, от закупок к логистике, от логистики к бухгалтерии. На каждой передаче есть стык. И на стыке регламент обычно замолкает.

Я выделяю четыре типа стыков, на которых ломаются и люди, и агенты:

• Информационный: получатель не знает, что для него что-то готово. Заявка лежит в чьей-то почте, следующий по цепочке про неё не в курсе.
• Форматный: данные пришли, но в виде, который нельзя использовать без ручной переделки. Продажи прислали скан, закупкам нужны строки в таблице.
• Процессный: непонятно, кто делает следующий шаг и когда. Двое ждут друг друга, заявка стоит.
• Управленческий: неясно, кто отвечает за результат на этом участке и к кому идти, если застряло. Это и есть вопрос RACI, только заданный честно.

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

3. Границы ответственности и точки эскалации

Агент должен знать не только что делать, но и где остановиться. Что он решает сам, а где обязан передать человеку. Регламент для людей это опускает: сотрудник чувствует границу кожей и сам тормозит там, где «лучше спрошу».

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

4. Критерий «сделано»

Чем заканчивается шаг? Не «заявка обработана», а проверяемый признак: статус в системе сменился на «отгружено», клиенту ушло письмо с номером заказа, в таблице заполнены все обязательные поля. Нет критерия завершения, и агент не понимает, дошёл он до конца или нет. Дальше два сценария, оба плохие: либо зацикливается, либо бросает шаг на полпути.

Кейс: стык, который съедал 1,8 млн ₽ в месяц

Дистрибьютор стройматериалов, 400 человек, четыре склада. Пришли с запросом посадить ИИ на обработку заявок от дилеров. Регламент был. Восемь страниц, написан аккуратно, не придерёшься.

При диагностике вскрылся стык между отделом продаж и складом. Менеджер принимал заявку и ставил в CRM статус «принято». Склад про этот статус не знал: он работал по выгрузке, которую кто-то делал руками раз в день. Между моментом «менеджер принял» и моментом «склад увидел» проходило в среднем девять часов. По срочным позициям этого хватало, чтобы товар ушёл другому клиенту, а дилеру пришлось ждать поставку.

Мы посчитали потери на одном этом стыке. Упущенные срочные заказы плюс компенсации дилерам за просрочку давали медиану 1,8 млн ₽ в месяц. Регламент про разрыв молчал, потому что для людей внутри он был невидим: «ну да, выгрузка раз в день, все привыкли».

Прежде чем заводить разговор про агента, мы переписали этот участок как контракт. Триггер «статус в CRM = принято» мгновенно создаёт задачу складу с полями «позиция, количество, склад, срок». Критерий «сделано»: резерв на складе подтверждён. Вот после этого про ИИ стало о чём говорить. Агент, посаженный на старое описание, просто унаследовал бы тот же девятичасовой провал, только теперь с уверенным машинным лицом.

Это и есть мысль, которую я повторяю каждому собственнику: стыки дороже систем. Купить можно любую CRM и любого агента. Но если описание процесса молчит про передачу между отделами, деньги продолжат утекать ровно в этот зазор.

От текста к процессу, который ИИ потянет

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

Начальное. Процесс живёт в тексте для человека. Много «при необходимости», «в установленном порядке», «по согласованию». Работает, пока на местах сидят конкретные люди, которые держат контекст в голове. Уволится Марина, и половина процесса уйдёт с ней.

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

Развитое. Описание связано с системами. Триггеры привязаны к событиям в CRM или почте, поля на стыках совпадают с полями в базе, точки эскалации заведены на конкретные роли. На этом состоянии AI-агент становится исполнителем, а не генератором новых ошибок.

Главная ошибка тех, кто хочет «по-быстрому внедрить ИИ», в попытке прыгнуть из начального состояния сразу к агенту. Регламент, потом карта процесса, потом AI-сотрудник. Середину пропустить нельзя: карта это и есть тот момент, когда текст превращается в структуру, которую можно исполнить.

Чек-лист: регламент готов к AI или нет

Пройдитесь по своему описанию процесса. Хотя бы один пункт «нет», и сажать агента рано.

Готов, если:

• Указано конкретное событие, которое запускает процесс.
• Каждое ветвление выражено проверяемым условием с числом или фактом, а не словами «при необходимости».
• Для каждой передачи между людьми и отделами названо: кто отдаёт, кто принимает, какие поля, в каком формате.
• Названо, что агент решает сам, а в каких случаях обязан эскалировать и кому.
• У каждого шага есть проверяемый признак завершения.
• Нет фраз «в установленном порядке», «по согласованию», «в обычном режиме» без расшифровки.

Не готов, если:

• Процесс описан связным рассказом, а не набором шагов с условиями.
• Стыки между отделами не описаны или описаны одним словом «передаёт».
• Нет ни одной точки эскалации.
• Завершение шага звучит как «обработано», «выполнено», «отработано» без признака.

FAQ

Можно ли просто загрузить наш регламент в ИИ и дообучить его? Загрузить можно. Результат повторит дыры регламента. Если в тексте «при необходимости согласует», агент либо проигнорирует согласование, либо придумает свой порог. Сначала закрываются пробелы в описании, потом подключается ИИ. Обратный порядок просто разгоняет хаос быстрее, чем было руками.

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

Зачем считать потери на стыках, если мы уже решили внедрять ИИ? Чтобы понять, где агент даст эффект, а где он не нужен вовсе. Бывает, что самый дорогой разрыв закрывается не агентом, а простым контрактом передачи данных между двумя отделами. Деньги возвращаются без всякого ИИ, а агента ставят туда, где он реально снимает рутину.

Наш процесс слишком сложный, его нельзя разложить на условия. Что делать? «Слишком сложный» почти всегда переводится как «никем не описанный целиком». Сложность держится в головах двух-трёх человек, и она же делает компанию заложником этих людей. Карта процесса вытаскивает её наружу. Обычно после этого выясняется, что сложного там два-три ветвления, остальное рутина.

Чем описание для ИИ отличается от обычной формализации процессов? Формализация делает процесс понятным человеку и контролируемым. Описание для ИИ идёт дальше: оно убирает любую опору на догадку и контекст. Формализованный регламент ещё допускает «опытный сотрудник поймёт». Описание для агента не допускает ничего, что нельзя проверить без участия живого человека.

Что дальше

Узнали свои регламенты в этом тексте? Начните не с выбора ИИ, а с честной ревизии описаний процессов.

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