Возвращаемся к производительности

Поздравляю, ликбез по ИИ мы с вами закрыли!

Для бизнес-архитектора этого уже обычно достаточно, чтобы не нести чушь на встречах, понимать классы решений и нормально ставить задачу на верхнем уровне и принимать результаты чужой работы.

Но как бы это не звучало странным, а для аналитика бизнес-процессов это только начало. Потому что проектирование процессов для ИИ и проектирование процессов без ИИ – это, как говорят в Одессе, две большие разницы.

Раньше что было, нарисовали километровую портянку в EPC или BPMN, написали регламент на 40 страниц, провели 100500 согласований, и интегратор пошёл героически внедрять это в систему. Со скрипом, матом, но на почасовой ставке ему было терпимо. В принципе, все при деле, все довольны.

Для классической автоматизации это ещё как-то работало. Плохо, тяжело, но работало. Для ИИ – нет, не работает. Почему?

Во-первых, для ИИ процесс должен отражать суждение.
А суждение – это не «мнение начальника» и не «Маша знает, как правильно». В ИИ-контексте это микро-решение внутри операции: понять контекст, вкурить задачу, найти решение, сопоставить его с нормой, оценить риск, выбрать следующий шаг и уметь объяснить почему именно так. Если суждение воспроизводимо, его можно передавать машине. Если нет – оставляем человеку.

Во-вторых, для ИИ нужна декомпозиция процессов.
Не декоративная, а рабочая. Без неё невозможно нормально задать контекст, границы задачи, корректный вход, корректный выход и критерий «готово». А без этого агент просто не понимает, с чем он работает. Про уровень мульти-агентов и выше я вообще молчу!
В результате получается не ИИ-автоматизация, а цифровой спиритизм.

Формула простая: нет декомпозиции – нет ИИ. А если рискнёте, то готовтесь объяснять руководству ошибки и галлюцинации в каждом запросе.

Трудно поднять с нуля? Используйте готовую. Останется только пересобрать операции в новых рамках.
Увы, за всё нужно платить, и за отступления от методологии в том числе. В конце концов, не использовать декомпозицию, а лепить процессы в режиме степного акына – что вижу, то пою, – было вашим решением.

В-третьих, внедрять всё это придётся вам, а не стаду Python-кодеров.
Они могут быть очень умные, бородатые и вдохновлённые. Но если аналитик не определил контекст, не разрезал работу на шаги, не задал вход/выход, не определил критерии качества и цепочку эскалации, то на выходе получится либо демка, либо произведение в стиле авангардизма с пояснениями «я художник, я так вижу» или «это не просто черный квадрат – это шедевр».

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

Отсюда неприятный, но очень практичный вывод.
Если вы аналитик процессов и хотите остаться в профессии, вам уже мало уметь рисовать схемы и писать регламенты.

Нужно учиться другому:
– видеть в процессе не только действия, но и суждения;
– резать работу до уровня, где можно задать контекст, вход, выход и DoD;
– мыслить не «от согласования», а «от эскалации»;
– и проектировать не бумагу, а исполняемый контур.

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

– операционный контекст – что за задача, в контексте какого процесса она выполняется, зачем вообще это нужно делать;
– вход – не 18 триггеров на пуск, а фиксированный выход с четким набором параметров и данных;
– выход – не 40 завершающих событий, а измеримый результат;
– критерий качества;
– объём и ритм;
– понятные исключения и эскалации;
– структурированные данные и системы.

Попробуйте уложиться в ~1000 символов. Ладно, для славянских языков в 1150.

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

как поднять производительность, а не просто увеличить количество стрелочек на диаграмме.

Хорошего вам дня!

#ИИ #ИИавтоматизация #производительностьтруда