Стоимость и надёжность автоматизации определяются не качеством модели. Они определяются тем, какие шаги модели отдали.
Правило, с которого я начинаю любой проект: модель должна делать только то, что умеет одна она — понимать неструктурированный вход. Всё остальное делает обычный код.
Звучит буднично, а именно нарушение этого правила закрывает большинство проектов на подступах к эксплуатации. Модели поручают считать суммы, выполнять однозначные правила, искать по справочникам — то есть работу, где нужна воспроизводимость, а получают вероятностную систему, которая ошибается редко и молча. В типовом рабочем конвейере модель занята на трёх-четырёх шагах из десяти, и это признак того, что решение сделано правильно, а не упрощённо.
Если вы пока не уверены, что задача вообще требует ИИ, начинать логичнее с разбора процессов: часть обращений заканчивается выводом, что достаточно обычного скрипта, и это дешевле.
Когда автоматизация нужна, а когда нет
Честный разбор до начала работ экономит бюджет, поэтому начинаю с него.
Автоматизация оправдана, если:
- операций много и они повторяются — от нескольких сотен в месяц;
- на входе текст, написанный человеком: письма, документы, обращения, отзывы;
- шаги процесса известны заранее и не меняются от случая к случаю;
- ошибку можно обнаружить и исправить;
- у нужных систем есть программный доступ.
Автоматизация не нужна, если:
- вход уже структурирован — данные приходят из формы или выгрузки, и разбирать нечего;
- правила формулируются однозначно — скрипт справится лучше и не ошибётся;
- каждый случай индивидуален, шагов заранее не назвать;
- объём мал, и экономия не покроет разработку и сопровождение.
Первые два пункта закрывают заметную часть обращений. Я говорю об этом на первой встрече примерно в каждом третьем случае — не из скромности, а потому что автоматизация, сделанная не тем инструментом, дороже и в разработке, и в эксплуатации.
Отдельный случай — когда порядок действий заранее неизвестен и зависит от промежуточных результатов. Это уже другой класс решений: разработка ИИ-агентов, с правами, подтверждениями и другой ценой.
Практическое правило: если процесс можно нарисовать блок-схемой, агент вам не нужен — нужна автоматизация с моделью на отдельных шагах.
Что я автоматизирую
Разбор входящей почты. Отсев рассылок и автоответов, очистка от цитирования, определение типа и срочности, извлечение данных, поиск клиента, маршрутизация, черновик ответа.
Документооборот. Регистрация входящих, определение типа документа, извлечение реквизитов, сверка с учётной системой, контроль комплектности и сроков, маршруты согласования.
Извлечение данных из документов. Счета, накладные, анкеты, договоры — поля с проверкой контрольными величинами и сверкой итогов. Работает на формах, которые система видит впервые, в отличие от шаблонных парсеров.
Классификация обращений. Разбор потока по темам, срочности и признаку претензии, с приоритетной очередью.
Рутина в CRM. Заполнение карточек из переписки, сводки звонков, определение следующего шага, поиск дублей, выявление застоявшихся сделок.
Отчётность. Сборка данных из источников, расчёт, сверка расхождений, разбор отклонений и сведение качественных данных — комментариев, причин отказов, содержания обращений.
Обработка отзывов. Разбор по конкретным претензиям с разрезом по товарам и подразделениям, приоритизация срочного, черновики ответов.
Разбор пятнадцати типовых сценариев с оценкой сложности — в материалах, ссылки на которые ниже.
Что входит в разработку
Разбор процесса и проверка применимости
Смотрю не на пожелания к системе, а на фактический поток: что приходит, в каких формах, какая доля повторяется, что из этого уже структурировано. Здесь же выясняются негласные правила — те самые «обычно так, но если клиент из другого региона, то иначе», которые не записаны нигде.
На этом же этапе честно определяется, какая часть задачи решается без модели. Часто оказывается, что заметная доля потока уже разобрана — пришла из формы или от известного отправителя, — и её нужно обрабатывать правилами. Это прямо снижает и стоимость разработки, и расходы на эксплуатацию.
Проверка достижимости на ваших данных
На архиве реальных случаев за месяц-два, а не на подготовленных примерах. Включая мусорные и нестандартные — именно они определяют, какая доля потока пройдёт без человека.
Заканчивается числом, а не впечатлением: какую долю система закроет сама и с какой точностью.
Проектирование конвейера
Раскладка процесса по шагам с явным ответом, кто что делает: где модель, где код, где человек. Это и есть основная инженерная работа.
Каждый шаг, имеющий формальную структуру, отдаётся коду: контрольные суммы ИНН и счетов, форматы дат, арифметика, поиск по справочникам, проверка дублей. Арифметику модель не выполняет никогда.
Строгий формат обмена
Ответ модели — не текст для человека, а данные для следующего шага. Формат задаётся схемой, а не просьбой в промпте, и проверяется кодом на выходе.
Отдельно закладываются три вещи: явное значение «нет в документе», признак неуверенности и фрагмент-подтверждение из источника. Последнее ловит выдуманные значения: если подтверждающего фрагмента в исходнике нет, значение почти наверняка придумано.
Проверка человеком там, где нужно
Ставится перед необратимыми действиями, а не после каждого шага. На запуске — сплошная, дальше по порогу уверенности: система обрабатывает сама то, в чём уверена, спорное отдаёт человеку.
Проверяющему показывается не вся карточка, а подсвеченное поле и причина сомнения. Это важнее, чем кажется: при сплошной проверке однотипных результатов внимание уходит, и контроль превращается в нажатие кнопки.
Обработка сбоев
Идемпотентность — повтор не создаёт дубли. Повторы с нарастающей паузой. Очередь необработанного с указанием причины. Лимит расходов с остановкой. И сверка на уровне итога: сколько операций вошло и сколько завершилось — она обнаруживает потери независимо от причины, включая непредусмотренные.
Запуск и сопровождение
Запуск под наблюдением с разбором первых недель. Контрольный набор случаев, который остаётся у вас и прогоняется после каждого изменения — он отличает «изменился поток» от «сломалась система».
От чего зависит стоимость
| Фактор | Влияние |
|---|---|
| Доля потока, требующая модели | главный множитель: часть обычно закрывается правилами |
| Качество и однородность входа | сканы и разнородные формы дороже чистых текстов |
| Число внешних систем | и состояние их программных интерфейсов |
| Число исключений в процессе | каждое негласное правило нужно выяснить и заложить |
| Требования к проверке | необратимые действия добавляют интерфейс подтверждения |
| Требования к обработке данных | локальное развёртывание вместо облачной модели |
Оценку называю после разбора процесса и проверки на вашем архиве. До того как я посмотрел реальный поток, любая сумма будет выдуманной: разброс по статье «какая часть решается без модели» слишком велик.
Чего я не делаю
- Не отдаю модели арифметику и однозначные правила. Она ошибается в них редко и молча, а такая ошибка попадает в учёт и обнаруживается при сверке через месяц.
- Не называю долю автоматизации до проверки на ваших данных. Достижимый результат — свойство вашего потока, а не мастерства исполнителя.
- Не запускаю без сценария неуверенности. Система, которая всегда выдаёт результат, будет выдавать неверный там, где следовало спросить.
- Не строю автоответы клиентам без проверки. Особенно на претензии: неуместный автоматический ответ усиливает недовольство сильнее, чем молчание.
- Не делаю автоматизацию там, где хватает скрипта. Если вход структурирован, а правила однозначны, скажу об этом и предложу решение дешевле.
- Не берусь, если расчёт не сходится. При малом объёме операций экономия не покроет разработку и сопровождение.
Форматы работы
Разбор процесса и оценка применимости. Раскладка процесса по шагам, проверка достижимости на вашем архиве, расчёт окупаемости. На выходе — обоснованный ответ: что автоматизировать, чем именно и во что обойдётся. Заканчивается решением, а не обязательством продолжать.
Пилот на одном процессе. Берётся направление с наибольшим объёмом, собирается конвейер, месяц наблюдения. Фактическая доля автоматической обработки становится измеренной, а не предполагаемой.
Разработка под ключ. Полный цикл от разбора до промышленной эксплуатации, с этапной оплатой и точкой выхода после проверки достижимости.
Доработка существующего решения. Если конвейер уже есть, но теряет операции, ошибается или разросся до неподдерживаемого состояния — разбор причин и исправление. Частый случай — сценарий в визуальном конструкторе, переросший инструмент.
Сопровождение. Разбор сбоев, обновление правил, контроль качества, оптимизация расходов.
