Я иногда мысленно ставлю простой эксперимент: берём процесс, в котором непонятно, кто отвечает за следующий шаг, данные вводятся как попало, а исключения решаются «по ситуации». Затем добавляем AI и просим его ускорить работу.
С большой вероятностью система не исправит фундаментальную неопределённость. Она просто начнёт быстрее воспроизводить то, что уже есть.
AI хорошо масштабирует повторяемость
Если процесс определён, это преимущество. Модель может классифицировать запрос, собрать контекст, выбрать разрешённое действие и передать его дальше.
Если правила противоречат друг другу, тот же механизм масштабирует ошибки и делает их менее заметными за красивым интерфейсом.
До AI полезно найти владельца и состояние процесса
Что является входом? Какие данные обязательны? Кто принимает решение? Какие статусы допустимы? Что считается завершением? Как обрабатывается исключение?
Это не бюрократия ради схемы. Ответы нужны, чтобы система понимала границы и могла быть протестирована.
Где AI всё же помогает в хаосе
Он может помочь обнаружить повторяющиеся типы исключений, собрать историю из разных источников и подготовить карту процесса. Но это диагностическая роль, а не разрешение автоматически принимать правила за компанию.
Ограничение мысленного эксперимента: каждый бизнес-процесс отличается. Поэтому решение надо проверять на реальных данных и одном ограниченном маршруте.
AI может быть хорошим диагностом до того, как станет исполнителем
В неустойчивом процессе я бы сначала использовал модель для классификации входящих случаев, поиска повторяющихся исключений и сборки истории из систем. Эти действия помогают увидеть структуру хаоса, не меняя внешний мир автоматически.
Только когда повторяемая часть становится понятной, можно переносить её в автоматическое действие. Такой порядок отделяет исследование процесса от выдачи полномочий и снижает вероятность того, что модель начнёт закреплять случайные решения сотрудников как новую норму.
И ещё один сигнал плохого процесса — когда сотрудники одинаковую ситуацию решают принципиально по-разному, но никто не может объяснить критерий. До автоматизации такие расхождения стоит сделать видимыми и превратить хотя бы в явные варианты решения.
Плохой процесс обычно выдаёт себя раньше автоматизации
Один сигнал — у участников нет общего ответа, где находится источник истины. Одни смотрят в CRM, другие в переписку, третьи держат критичную деталь в памяти. Тогда AI тоже получит несколько несовместимых версий состояния и будет вынужден выбирать между ними без бизнес-основания.
Другой сигнал — статус существует, но не определяет следующее действие. Карточка может называться «в работе», хотя один менеджер ждёт клиента, другой готовит расчёт, а третий уже считает задачу завершённой. Автоматизация такого статуса создаёт видимость порядка, но не делает процесс однозначным.
Сначала полезно определить минимальную модель состояния
Не обязательно рисовать идеальную схему всей компании. Для одного маршрута достаточно понять, какой объект движется по процессу, какие состояния действительно различаются по следующему действию, какие данные обязательны и кто отвечает за переход между состояниями.
Отдельно стоит описать исключения. Если нестандартная ситуация встречается, но правило для неё пока не сформулировано, система должна уметь остановиться и передать её человеку. Это честнее, чем заставлять модель каждый раз придумывать решение, а затем незаметно превращать случайные ответы в новую практику.
Источник истины важнее красивого интерфейса
AI может собрать данные из нескольких систем, но ему всё равно нужно понимать, какой источник авторитетен для конкретного факта. Статус сделки может жить в CRM, наличие — в учётной системе, факт публикации — на публичной странице. Если при конфликте не задан приоритет, удобный чат лишь скрывает несогласованность.
Поэтому до автоматического действия полезно решить, откуда берётся каждый критичный факт и как определяется его свежесть. Когда это невозможно, результат лучше помечать как требующий проверки, а не дополнять предположением.
AI-пилот можно использовать как диагностику процесса
Вместо права сразу что-то менять модель может сначала работать наблюдателем: классифицировать входящие случаи, собирать контекст, показывать повторяющиеся исключения и предлагать следующий шаг. Человек подтверждает или исправляет предложение, а команда получает материал для уточнения правил.
Так становится видно, где проблема действительно в обработке языка и большого объёма контекста, а где процесс просто не договорён внутри бизнеса. Во втором случае дополнительная модель не решает корневую задачу — сначала нужен управленческий выбор.
Перед write-автоматизацией нужны наблюдаемость и обратимость
Если система меняет внешний объект, должно быть понятно, какое состояние ожидалось после действия и как его проверить. Успешный вызов инструмента сам по себе недостаточен. Нужен read-back из той системы, которая хранит результат, а при расхождении — остановка или передача человеку.
Для первого автоматического эффекта разумнее выбирать действие с ограниченным радиусом ошибки и понятным способом исправления. По мере того как правила стабилизируются, можно расширять область. Но расширение должно идти вслед за доказанной управляемостью процесса, а не впереди неё.
Когда процесс готов к AI-исполнителю
Я бы считал хорошим признаком ситуацию, когда участники одинаково понимают вход, состояние и критерий завершения; критичные данные имеют источник истины; исключения не маскируются под нормальный маршрут; а результат действия можно проверить. Тогда AI получает ясную задачу вместо просьбы «разобраться по ситуации».
В таком процессе модель полезна там, где остаётся неоднозначный язык, поиск по контексту, классификация или выбор между разрешёнными сценариями. Точные переходы и жёсткие ограничения при этом могут оставаться обычной автоматизацией. Такое сочетание обычно прозрачнее, чем попытка поручить модели весь процесс целиком.
Ещё один практический тест — способен ли новый сотрудник пройти этот маршрут по явным правилам без постоянного устного уточнения. Если даже человеку приходится каждый раз искать «того, кто знает, как здесь принято», AI тем более не получает устойчивого контракта. Такая зависимость от скрытого знания — хороший кандидат сначала для описания и наблюдения, а не для автономного исполнения.
Мы обычно сначала делаем процесс наблюдаемым, а уже затем решаем, где в нём нужна AI-логика: https://imr.top-experts.pro/contacts/
Если нужен не отдельный отчёт, а регулярный контроль по рабочим данным компании, см. AI-ассистента руководителя по продажам и управлению.