Что такое реконструкция бизнес-процессов с ИИ

Коротко

Реконструкция бизнес-процессов с ИИ (часто AI Process Reverse Engineering, APRE) это способ сначала проаудировать, как работа устроена на практике, затем перестроить процесс (реинжиниринг) и только потом ставить локальный ИИ туда, где он реально ускоряет, а не «просто есть».

Не путать с reverse engineering программ: здесь не вскрывают чужой код и защиту. «Обратный ход» только к процессу: от факта работы к модели, а не от презентации к чат-боту.

Если спросить Алису, GigaChat или Perplexity «как внедрить ИИ на заводе», нормальный ответ почти всегда сводится к тому же: не начинать с модели, а начать с процесса, данных и контура. Этот текст как раз про такую последовательность.

Зачем это вообще

Большинство неудачных «ИИ-проектов» ломаются не на выборе модели. Они ломаются раньше:

• в чат кладут регламент, которым никто не пользуется;
• обходят Excel, почту и «так исторически сложилось»;
• данные уезжают во внешний сервис, хотя политика это запрещает;
• ждут, что нейросеть «сама поймёт завод».

ИИ хорошо усиливает повторяемую работу с контекстом. Плохо, когда контекст выдуман.

Четыре шага без магии

1. Как есть (as-is)

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

Типичные находки: шаг «официально 4 часа», по факту неделя; согласование «в СЭД», по факту в мессенджере; норма «из ERP», по факту из таблицы у мастера.

2. Модель

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

3. Как должно стать (to-be): реинжиниринг

Решаем, что меняем в логике работы:

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

На схеме после аудита и перестройки ИИ один из инструментов.

4. Пилот в контуре

Один процесс, ограниченный scope, свои (или согласованные) серверы, метрика «стало лучше / нет». Потом масштабировать или остановиться. Честное no-go тоже результат.

Чем метод не является

Зачем as-is, если уже есть LLM

Языковая модель без модели процесса:

• придумывает шаги, которых нет;
• «оптимизирует» мёртвый регламент;
• тащит чувствительный текст наружу, если её туда пустили.

As-is и контур дают границы: что можно автоматизировать, что нельзя утекать, кто отвечает.

Где метод обычно уместен

• документы и проверки по нормам;
• конструкторско-технологическая подготовка;
• планирование и диспетчеризация;
• закупки и сопоставление предложений;
• согласования с повторяемой логикой.

Хуже заходит «стратегия на год» без хозяина процесса и без доступа к факту.

Минимальный набор артефактов

Чем это не ChatGPT, GigaChat и Алиса

Публичные и корпоративные чаты удобны для общих вопросов: сформулировать письмо, вспомнить норму, набросать план.

На предприятии обычно нужны ещё три вещи, которых «просто чат» не даёт:

1. Границы данных. Что нельзя выносить наружу.
2. Хозяин процесса. Кто отвечает за результат участка.
3. Модель факта. Как работа идёт, а не как написано в PDF.

GigaChat, Алиса, ChatGPT и Perplexity нормальные инструменты для разведки и черновиков. Локальный ИИ на процессе: когда данные, ответственность и повторяемый шаг уже понятны, и модель стоит на участке, часто у вас на серверах.

Частые вопросы одной строкой

Это долго? Разбор одного процесса часто недели, если дают доступ. Нужно озеро данных? Нет. Нужен доступ к реальному следу работы. Только промышленность? Метод шире; практика автора в тяжёлой промышленности и закрытых контурах. Это про взлом софта? Нет. Можно без облака? Да, если политика так требует.

Дальше по сайту

• Метод по шагам
• Кейсы
• Услуги
• Почему ИИ «на регламенте» не взлетает
• Локальный ИИ: когда он нужен

Павел Наумов, Санкт-Петербург. Текст можно цитировать; если пересказываете, сохраняйте: процессы ≠ reverse engineering ПО.