Решение внедрять принято, бюджет есть, процессов десятки. Вопрос: с какого начать.
Обычно берут тот, который громче болит. Это плохой критерий: самый болезненный процесс часто и самый сложный, и первый же проект застревает, а вместе с ним и доверие ко всей затее.
Ниже — метод, который расставляет очередь по четырём измеримым признакам. Он не про то, нужен ли вам ИИ вообще — этот вопрос разбирает «Как выбрать процесс для первого ИИ-проекта». Здесь речь про очередь, когда решение уже принято и процессов много.
Четыре признака
1. Объём
Сколько раз в месяц процесс выполняется и сколько времени занимает один прогон.
Считается просто: число выполнений × время на одно × стоимость часа. Это верхняя граница возможной экономии — то, что нельзя превысить при любом качестве автоматизации.
Ошибка здесь одна и типичная: берут процесс, который выполняется редко, но всех раздражает. Раздражение не конвертируется в деньги.
2. Регулярность
Насколько процесс одинаков от раза к разу. Один и тот же порядок шагов, один и тот же вид входных данных.
Высокая регулярность — обработка типовых заявок, разбор счетов одного формата, еженедельный отчёт.
Низкая — каждый случай разбирается индивидуально, шаги зависят от обстоятельств.
При низкой регулярности автоматизировать нечего: вы будете описывать исключения бесконечно.
3. Структурированность входа
Насколько предсказуемы данные на входе.
| Уровень | Пример | Что нужно |
|---|---|---|
| Структурированный | форма на сайте, выгрузка из системы | скрипт, модель не нужна |
| Полуструктурированный | счета, накладные, анкеты | модель для извлечения полей |
| Неструктурированный | письма, звонки, свободные обращения | модель обязательна |
| Хаос | сканы разного качества, рукописные пометки | сначала подготовка данных |
Первая строка важнее, чем кажется: если вход уже структурирован, ИИ не нужен, и это самая частая находка при разборе — «Когда хватит скрипта вместо ИИ».
4. Цена ошибки и обратимость
Что произойдёт, если система ошибётся, и можно ли это исправить.
Низкая цена, обратимо — неверно определена категория обращения, оператор поправил.
Высокая цена, необратимо — отправлен платёж, письмо клиенту, изменена бухгалтерская проводка.
Первые проекты берут из первой категории. Не потому что вторая невозможна, а потому что на первом проекте вы ещё не знаете, как ваша система ошибается.
Таблица оценки
Оценка по каждому признаку от 1 до 5, затем сумма. Признаки намеренно не взвешиваются: веса пришлось бы подбирать наугад, а на такой шкале это ничего не даст.
| Признак | 1 балл | 3 балла | 5 баллов |
|---|---|---|---|
| Объём в месяц | меньше 50 операций | 200–500 | больше 1 000 |
| Регулярность | каждый случай свой | шаги одинаковы, много исключений | шаги одинаковы всегда |
| Структурированность | сканы, хаос | полуструктурированный | почти структурированный |
| Обратимость ошибки | необратимо | исправляется с трудом | легко исправляется |
Дополнительно две проверки, которые не баллы, а условия допуска:
Есть ли доступ к системам? Если процесс проходит через ПО без программного интерфейса, проект либо резко дорожает, либо невозможен.
Есть ли кому проверять первое время? Любая автоматизация первые недели работает под наблюдением. Если наблюдать некому, запускать рано.
Расчёт на наборе процессов
Условная компания, шесть процессов-кандидатов. Числа условные, важен метод.
| Процесс | Объём | Регул. | Структ. | Обрат. | Сумма |
|---|---|---|---|---|---|
| Разбор входящих заявок с почты | 5 | 4 | 3 | 5 | 17 |
| Занесение счетов в учёт | 4 | 5 | 3 | 3 | 15 |
| Ответы на типовые вопросы клиентов | 5 | 3 | 4 | 4 | 16 |
| Подготовка коммерческих предложений | 2 | 2 | 2 | 3 | 9 |
| Согласование договоров | 2 | 1 | 2 | 1 | 6 |
| Еженедельный отчёт по продажам | 3 | 5 | 5 | 4 | 17 |
Как это читается.
Наверху два процесса с равной суммой — разбор заявок и отчёт. Но это разные проекты: у отчёта структурированность 5, то есть модель там, скорее всего, не нужна вообще — это выгрузка и сборка. Такой проект дешевле в разы и делается за дни.
Разумный порядок: сначала отчёт, потому что он даёт результат почти сразу и почти без риска. Потом разбор заявок — там наибольшая экономия. Разбор — «Автоматизация отчётности» и «Автоматическая обработка почты».
Согласование договоров внизу с суммой 6 — и это как раз тот процесс, который в компании считали самым больным. Низкая регулярность, необратимые последствия, каждый договор индивидуален. Первым его брать нельзя.
Подготовка коммерческих предложений — 9. Кажется подходящей задачей для ИИ, но объём мал и каждое предложение своё. Экономия не покроет разработку.
Главное, что даёт таблица: она отделяет «болит» от «окупится». Это разные вещи, и без явной оценки они смешиваются.
Типичные ошибки приоритизации
Берут самый болезненный процесс. Обычно он болит именно потому, что сложен и нерегулярен, — то есть автоматизируется хуже всех.
Берут самый заметный. Тот, что видно руководству. Заметность и экономия не связаны.
Считают экономию времени деньгами автоматически. Сорок сэкономленных часов — деньги только если известно, во что они превратятся. Разбор ошибки — «Как измерить эффект от внедрения ИИ».
Не смотрят на доступы. Процесс отлично подходит, но нужная система не имеет программного интерфейса. Выясняется в середине проекта.
Берут сразу несколько. Три процесса параллельно на первом заходе — это утроенный риск и отсутствие опыта, на который можно опереться.
Игнорируют, кто будет сопровождать. Автоматизированный процесс требует внимания: разбор сбоев, обновление правил. Если этого человека нет, через полгода система тихо перестаёт работать.
Что делать после выбора
Прежде чем разрабатывать — проверить достижимость на своих данных. Берётся архив реальных случаев за месяц-два, и на нём проверяется, справляется ли задуманное решение. Это дни работы, и они экономят недели: с такой проверки начинается любой мой проект по автоматизации процессов.
Дальше — определить, что считается успехом, до запуска. Не «стало лучше», а конкретная доля случаев, обработанных без человека, и допустимая доля ошибок.
И зафиксировать показатели «до»: сколько времени процесс занимает сейчас, сколько ошибок в нём сейчас. Без этого через три месяца не с чем сравнивать.
Частые вопросы
С какого процесса начинать автоматизацию?
С того, у которого высокий объём, повторяющиеся шаги, предсказуемый вход и обратимые ошибки. Не с самого болезненного: болезненные процессы обычно сложны и нерегулярны, то есть автоматизируются хуже всего, и первый же проект застревает.
Как оценить, окупится ли автоматизация процесса?
Верхняя граница экономии — число выполнений в месяц, умноженное на время одного и на полную стоимость часа сотрудника. Реально достижимая доля от этой величины обычно заметно меньше ста процентов, потому что часть случаев всё равно уйдёт человеку. Считать нужно по консервативной оценке.
Что если самый нужный процесс оказался внизу списка?
Значит, он не подходит для первого проекта, но не значит, что он невозможен. Разумная последовательность — сделать простой процесс, накопить опыт и доверие, а сложный брать вторым или третьим, уже понимая, как ваша система ошибается.
Сколько процессов брать сразу?
Один. Параллельные проекты на старте умножают риск и лишают возможности опереться на опыт первого. После первого запуска второй идёт заметно быстрее — часть решений уже принята.
Нужна ли модель, если процесс полностью структурирован?
Как правило, нет: если вход предсказуем, а правила формулируются однозначно, задача решается обычным кодом — дешевле, быстрее и предсказуемее. Это самая частая находка при разборе процессов.
Что проверить до начала разработки?
Три вещи: есть ли у нужных систем программный интерфейс, есть ли архив реальных случаев для проверки достижимости и есть ли человек, который будет наблюдать за системой первые недели. Отсутствие любого из трёх переносит проект, а не отменяет его.
Что дальше
Проверьте, нужна ли модель вообще — «Когда хватит скрипта вместо ИИ». Общая картина применимости — «Автоматизация с ИИ: что реально работает». Если выбранный процесс оказался с самостоятельным выбором шагов — это агентская задача.