При выборе процесса оптимизации мы оцениваем две составляющие: боль бизнеса и возможности автоматизации. Складывается так, что большинство применений 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
Автор: N3VERZzz
