Процесс для делегирования LLM выбирают по двум измеримым величинам: боль бизнеса и возможности автоматизации. Боль считают в трудозатратах, формула простая: количество операций умножить на среднее время одной операции, а часы перевести в деньги по ставкам ролей. Возможности автоматизации проверяют по опыту команды и физическим ограничениям процесса.
Порядок шагов похож на бухгалтерию, и это нормально. Сначала отсекаем процессы, которые команда не доведёт до продакшена, затем ранжируем остаток по часам. Процесс с огромной болью, но без логов и с десятком интеграций проигрывает скромной задаче, которую реально закрыть за месяц.
Разбор опирается на кейс оптимизации валютного контроля и открывает серию материалов. В этой части: две оси выбора, расчёт трудозатрат по ролям, проверка реализуемости и принцип узкой нарезки. Дальше в серии пойдут детали по работе с процессами, где нет логов.
Почему выбор процесса для LLM сложнее, чем кажется
Большинство применений LLM - это оптимизация уже существующей работы: компания снижает косты, а не наращивает прибыль. Отсюда практическое требование: считать эффект в часах и деньгах, а не в ощущении «ИИ сделает красиво». Подробный разбор методологии выбора процесса с примерами расчётов опубликован в исходном материале на Хабре.
Две оси выбора: боль бизнеса и возможности автоматизации
Оценка идёт по двум составляющим одновременно: сколько процесс съедает времени у людей и насколько реально закрыть его моделью силами конкретной команды. Оценивать только одну ось опасно. Процесс с гигантской болью, размазанными данными и десятком внешних систем может стоить дороже, чем весь эффект от автоматизации. Процесс с modest-болью, но собранными логами и одной интеграцией часто приносит первую победу за квартал.
Рабочая схема выглядит так:
| Квадрант | Реализуемо силами команды | Пока не реализуемо |
|---|---|---|
| Большая боль | Приоритет 1: пилот в первую очередь | Отложить, сначала снять технические блокеры |
| Малая боль | Быстрый выигрыш, если почти бесплатно по срокам | Не брать |
Правило после заполнения квадрантов: сначала вычёркиваем нереализуемое, потом ранжируем остаток по часам. Если кандидатов больше пяти, сведите их в сравнительную таблицу по критериям, методика такой оценки альтернатив разобрана в статье про NotebookLM для принятия решений.
Главный подводный камень: разрыв между бизнесом и разработкой
LLM-проекты отличаются от обычных IT-проектов очень глубоким погружением в бизнес. Разработчику мало знать стек, ему нужно понимать логику операций, нормативку, исключения и то, как сотрудники обходят инструкции. Чтобы увидеть потенциальную возможность оптимизации, технической команде приходится закапываться в процессы на месяц, а то и на два.
Со стороны бизнеса картина обратная. Заказчики зачастую далеки от передовых технологий, не представляют, что LLM умеет и чего не умеет, и потому считают, что она умеет всё. Итог: сроки оценивают по ощущению, а на входе получают «сделайте нам ИИ для отдела».
Цена непонимания измерима. В кейсе валютного контроля мало кто за пределами профильного отдела знал само словосочетание, а стандартный онбординг нового сотрудника в этот процесс занимает 2 месяца. Два месяца только на то, чтобы новичок начал что-то делать осмысленно. Если команда не готова вложить сопоставимое время в изучение процесса, она будет автоматизировать свои фантазии о нём.
Уменьшить разрыв помогает глубокая аналитика до выбора процесса и фокус на отдельных кусках работы. Разговор с исполнителями, просмотр логов и ручной замер операций дают больше, чем ещё один цикл согласований.
Шаг 1. Считаем боль бизнеса в трудозатратах
Формула: трудозатраты = количество операций × среднее время на одну операцию. Считаем за месяц, потому что месячный горизонт сглаживает пики и совпадает с отчётностью.
Два примера из разбора показывают, почему интуиция врёт. 100 операций в месяц по 1 часу дают 100 часов. 1 000 операций по 7 минут дают 116 часов 40 минут. Второй процесс отнимает больше времени, хотя каждая отдельная операция кажется короткой и «незначительной». Такие процессы обычно и не замечают при опросах сотрудников: никто не жалуется на семь минут, а суммарно они съедают больше, чем часовые задачи. Расчёты и логика разбора приведены в материале про выбор процесса для делегирования ИИ.
Дальше часы переводят в деньги по стоимости времени каждой роли. Автор разбора прямо называет расчёт стоимости времени по ролям очень сложным, и это честное предупреждение: именно здесь появляются круглые числа «на глаз» и завышенные ожидания.
Как учитывать несколько ролей в одном процессе
Если в процессе участвуют несколько ролей, затраты считают по каждой из них и складывают. Операция может проходить через аналитика, юриста и комплаенс-офицера, и у каждой роли своя ставка и своё время.
Стоимость часа меняет приоритет даже при равных трудозатратах. 40 часов дорогой роли способны стоить больше, чем 120 часов дешёвой, и тогда процесс с меньшим числом часов выходит вперёд. Обратная ситуация тоже частая: дешёвая роль съедает столько часов, что эффект от автоматизации перекрывает любые накладные расходы.
Практика: соберите таблицу «роль, операций в месяц, минут на операцию, ставка» и заполняйте её вместе с руководителями ролей. Одна и та же операция с точки зрения аналитика и юриста может занимать разное время, и это нормально.
Почему процессная аналитика лучше кастдева
Кастдев даёт рассказ о процессе, процессная аналитика даёт цифры. Логи систем и трекеров показывают реальное количество операций, реальное время между шагами и реальные узкие места, без «у нас примерно сотня в месяц» и «минут по десять, наверное».
Ограничение у метода одно и жёсткое: он работает там, где есть логи и где шаги фиксируются в системах. Если процесс живёт в почте, мессенджерах и головах, аналитике не из чего считаться. Это отдельный сценарий, он разобран ниже.
Шаг 2. Проверяем возможности автоматизации
Переход от боли к реализуемости. Возможность эффективно применить ИИ зависит от опыта и насмотренности команды разработки, а не от красоты презентации. Второй фильтр: физические ограничения процесса, которые видны до старта проекта.
В доступном фрагменте разбора критерии проверки возможностей автоматизации раскрыты не полностью. Ниже рамка, которую стоит дополнить собственным опытом: она задаёт вопросы и порядок проверки, а не исчерпывающий список.
Опыт команды: где проходит граница компетенций
Насмотренность складывается из конкретных вещей: делала ли команда похожие LLM-проекты, работала ли с RAG, с агентами, с извлечением данных из документов, понимает ли, как оценивать качество ответа модели. Если команда ни разу не решала похожую задачу, сроки и риски растут независимо от бюджета.
Правило: не берите процесс, которому нужна технология, отсутствующая в команде. Сначала закрывайте пробел на маленьком пилоте с измеримым результатом, потом идите в основной процесс. Разбор типичных границ применимости на примере разработки собран в материале про ИИ в разработке и границы применимости.
Физические ограничения процесса: контекст, время, интеграции
Три ограничения проверяют до пилота, каждое способно обнулить эффект.
Контекст. Если для решения задачи модель должна держать в голове больше примерно 50 страниц А4, задачу лучше отложить: правило опирается на практику команды, а не на измеренный порог. Причина в экономике и точности: длинный контекст дороже, детали из середины документа удерживаются хуже, а проверка ответа человеком удлиняется.
Выигрыш во времени. Считайте чистый выигрыш, а не время работы модели. Пример арифметики: 100 операций в месяц, модель экономит по 5 минут на каждой, это 8 часов 20 минут. Если человек тратит по 3 минуты на проверку каждого ответа, из выигрыша уходит 5 часов, остаётся 3 часа 20 минут в месяц. На таких цифрах проект не окупается.
Интеграции. Каждое подключение к системе (учётная система, почта, хранилище документов, справочник контрагентов) означает работу, согласования и риск. Число интеграций посчитайте до старта. Процесс, которому сразу нужно шесть внешних систем, скорее инфраструктурный проект, чем оптимизация работы.
| Проверка | Вопрос к процессу | Красный флаг |
|---|---|---|
| Опыт команды | Делали ли мы похожее? | Технология новая для всех, некому проверить качество |
| Контекст | Сколько материала нужно удержать? | Свыше ~50 страниц А4 на одну операцию |
| Выигрыш во времени | Сколько остаётся после проверки? | Модель экономит минуты, проверка занимает часы |
| Интеграции | К скольким системам подключаемся? | Десяток разноплановых подключений на первом этапе |
| Логи | Есть ли объективные данные о процессе? | Данных нет, только рассказы сотрудников |
Что делать, если логов и процессной аналитики нет
Отсутствие логов - признак недостаточной дата-зрелости бизнеса, а не приговор процессу. Плохая новость: без цифр нельзя посчитать боль и нельзя доказать эффект. Хорошая: тупиков всего три выхода, и каждый выбирается осознанно.
- Оцифровать процесс и отложить LLM. Сначала фиксировать шаги в системе, собрать историю операций и сроков, через несколько месяцев вернуться к автоматизации с нормальными данными. Долго, зато дальше считает аналитика, а не интуиция.
- Начать с узкого участка, где данные есть. Часть процесса почти всегда проходит через систему, которая пишет логи. Берём этот участок, показываем эффект, на его результатах договариваемся о цифровизации остального.
- Провести ручной замер как временную замену. Две-четыре недели исполнители фиксируют количество операций и время по каждой. Трудозатратно, зато даёт основу для расчёта и заодно проверяет гипотезу о боли.
В доступном фрагменте разбора эти три пути не раскрыты, поэтому воспринимайте список как рамку для решения, а не как готовые рецепты с гарантированным результатом.
Принцип узкой нарезки: не автоматизируем всего сотрудника
Автор разбора формулирует прямой запрет: никогда не пытайтесь покрыть своим решением полностью всю работу какого-либо сотрудника. Сосредотачивайтесь на отдельных кусках работы, которые можно оптимизировать.
Причины практические. Узкий участок быстрее описать и проверить, у него понятные входы и выходы, его качество проще измерить. Пилот на одном куске работы даёт результат за недели, а не за кварталы, и не ломает процесс целиком при ошибке. Полное покрытие роли требует описать все исключения, а исключения в реальных процессах съедают больше времени, чем основной сценарий.
С валютным контролем это видно по масштабу: онбординг занимает 2 месяца, значит, процесс большой и многослойный. Брать его целиком бессмысленно. Задача первого этапа: найти конкретный участок с высокой болью и низкими требованиями к интеграциям, например проверку однотипного пакета документов.
Кейс валютного контроля: как методология работает на практике
Команда начала оптимизацию с валютного контроля, хотя мало кто за пределами профильных специалистов знал такое словосочетание. Стандартный онбординг нового сотрудника в этот процесс занимает 2 месяца. Факты кейса собраны в публикации о выборе процесса для делегирования ИИ.
Как на таком процессе применяются шаги методологии (дальше логика применения, а не цифры кейса):
- Боль. Считаем операции по типам проверок и время специалиста на каждую, отдельно складываем часы комплаенс-офицера и юриста. Двухмесячный онбординг подсказывает, что операций много и они разнородные.
- Реализуемость. Проверяем, есть ли у команды опыт извлечения данных из документов и работы с длинным контекстом. Участки, где нужно удерживать десятки страниц регуляторных требований и историю сделок, по правилу про 50 страниц уходят в конец очереди.
- Интеграции. Считаем системы, из которых нужны данные. Участок, требующий подключения к пяти источникам, откладываем.
- Нарезка. Выбираем один тип операции, где вход и выход понятны, а проверка ответа занимает минуты, а не часы.
Логика кейса переносится на любой процесс с документами и регламентом: сначала измеряем, потом отсекаем нереализуемое, потом режем на куски.
Чек-лист выбора процесса и что дальше в серии
Сводка в порядке применения:
- Посчитать трудозатраты по каждой роли: операции × время, затем часы × стоимость часа, сложить по ролям.
- Проверить наличие логов и процессной аналитики. Логов нет, выберите один из трёх путей: оцифровка, узкий участок с данными, ручной замер.
- Оценить опыт команды. Нужной технологии нет, сначала пилот на смежной задаче.
- Проверить контекст: если нужно удерживать больше ~50 страниц А4, отложить.
- Посчитать чистый выигрыш во времени с учётом проверки ответов человеком.
- Посчитать интеграции и отсечь всё, что требует десятка подключений на старте.
- Нарезать процесс на узкий участок с измеримым результатом и не пытаться закрыть всю работу роли.
Одна оговорка про распределение ответственности: ИИ готовит вариант, решение остаётся за человеком. Как это устроено на уровне управления, разобрано в материале про «Мозг фирмы: 2026».
Это первая часть серии. В следующих материалах: детали проверки возможностей автоматизации и работа с процессами, где нет логов. Выбирайте процесс, у которого боль измерима в часах, а реализуемость подтверждена командой и проверками из чек-листа, а не обещаниями.