При выборе процесса оптимизации мы оцениваем две составляющие: боль бизнеса и возможности автоматизации. Складывается так, что большинство применений LLM — это оптимизация какой‑то работы (снижение костов, а не увеличение прибыли). Найти пересечение боли бизнеса и возможности автоматизации — это выглядит легко! Но, к сожалению, существует множество подводных камней.

Первый, самый жирный камень, об который вас ударит реальность, — это разделённость экспертизы бизнеса и команды разработки. Бизнес хорошо знает свой бизнес! Команда разработки хорошо знает, как делать ИИ‑продукты (надеюсь). Это практически непересекающиеся массивы. Когда наша команда начала оптимизировать валютный контроль, мало кто знал вообще такое словосочетание, не говоря о каких‑либо процессах, которые там происходят. А ведь, между прочим, стандартный онбординг нового сотрудника на валютный контроль занимает 2 месяца.

LLM‑проекты отличаются от обычных айтишных проектов очень глубоким погружением в бизнес. Это не просто доп. фича, а оптимизация работы сотрудника. Но чтобы нам сделать эту оптимизацию, нам надо как бы воссоздать работу сотрудника, а чтобы её воссоздать, надо понимать, как работает сотрудник. (Чтобы не воссоздавать шаг за шагом весь процесс, а сделать что‑то более элегантное, нужно разбираться в процессе ещё лучше. Ты не можешь пройти по сокращённому пути, если не знаешь дефолтный путь.)

Видите проблему? Чтобы технической команде увидеть потенциальную возможность оптимизации бизнеса, нужно закапываться в его процессы на месяц, а то и два. Альтернатива — попросить бизнес определить, что нужно оптимизировать, — может быть, выглядит ещё хуже: зачастую это люди, далёкие от передовых технологий, они в душе не предполагают, что умеет делать LLM, и поэтому считают, что она умеет делать всё.

Нам надо действовать на пересечении, отлично знать бизнес и при этом разбираться в технической стороне вопроса.

Чтобы хоть как‑то уменьшить этот разрыв, я предлагаю делать глубокую аналитику перед выбором процесса. Сосредотачиваться на отдельных кусках работы, которые можно оптимизировать (никогда не пытайтесь покрыть своим решением полностью всю работу какого‑либо сотрудника).

Дальше очевидность

1. Оцениваем больЗдесь БОЛЬ = ВРЕМЯ, нам особо не нужны кастдевы. Можно обойтись только инструментом процессной аналитики.

Для начала считаем, сколько рабочего времени уходит на процесс. Здесь два множителя: количество операций и среднее время сотрудника на одну операцию.

Трудозатраты = количество операций × время на одну операцию.

Например:

  • 100 операций в месяц по 1 часу — 100 часов.

  • 1 000 операций в месяц по 7 минут — 116 часов 40 минут.

Второй процесс отнимает больше времени, хотя каждая отдельная операция кажется короткой.

Затем учитываем стоимость этого времени. Если в процессе участвуют несколько ролей, считаем затраты по каждой из них и складываем. (Конечно, это очень сложно сделать.)

2. Проверяем возможности автоматизации

Дальше последовательно разбираем процессы по двум критериям.

Можно ли эффективно применить ИИ?

Здесь многое зависит от опыта и насмотренности команды разработки. Со временем появляется понимание, какие задачи удаётся решать стабильно, какие нет.

Допустим, наша команда предпочитает не брать задачи с большим контекстом — документы объёмом более 50 страниц А4. Мы маркируем все непотребные нам задачки.

Какие физические ограничения есть у процесса?

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

И даже если получится, важно помнить: мы боремся за разницу во времени выполнения задачи человеком и ИИ. Если человек справляется за 1 минуту 30 секунд, а ИИ — за 1 минуту 20 секунд, мы экономим всего 10 секунд на событии.

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

А что, если у нас нет логов для процессной аналитики? Значит, ваш бизнес имеет недостаточную зрелость в работе с данными, чтобы внедрять в него ИИ. В таком случае может:

1) Заняться его дата‑зрелостью.
2) Сразу пилить AI‑native‑площадку.
3) Дать сотрудникам инструменты и сказать: «Веселиться, как хотите».

Я собираю знания в методологию, это первая статья из серии, чтобы не потеряться — подпишитесь здесь или на тг https://t.me/s/Gpt_budni