Коротко
Реконструкция бизнес-процессов с ИИ (по-английски часто говорят AI Process Reverse Engineering, APRE) — это способ сначала понять, как работа на предприятии устроена на деле, описать это моделью, а уже потом ставить локальный ИИ туда, где он реально ускоряет, а не «просто есть».
Не путать с reverse engineering программ: здесь не вскрывают чужой код и защиту. «Обратный ход» — только к процессу: от факта исполнения к модели, а не от красивой презентации к чат-боту.
Зачем это вообще
Большинство неудачных «ИИ-проектов» ломаются не на выборе модели. Они ломаются раньше:
- в чат кладут регламент, которым никто не пользуется;
- обходят Excel, почту и «так исторически сложилось»;
- данные уезжают во внешний сервис, хотя политика это запрещает;
- ждут, что нейросеть «сама поймёт завод».
ИИ хорошо усиливает повторяемую работу с контекстом. Плохо — когда контекст выдуман.
Четыре шага без магии
1. Как есть (as-is)
Смотрим след процесса: системы, документы, логи, интервью, хронометраж, исключения. Цель — не обвинить людей, а зафиксировать факт.
Типичные находки: шаг «официально 4 часа», по факту — неделя; согласование «в СЭД», по факту — в мессенджере; норма «из ERP», по факту — из таблицы у мастера.
2. Модель
Рисуем и описываем процесс так, чтобы на него можно было опереться: роли, входы/выходы, системы, правила, развилки. Форматы разные — BPMN, схемы данных, глоссарий, граф связей. Важно не «красота диаграммы», а полнота для следующих шагов.
3. Как должно стать (to-be)
Решаем, что меняем:
- где хватит обычного скрипта или правила;
- где нужен поиск по базе знаний / документам;
- где уместна языковая модель;
- где решение только за человеком.
ИИ — не награда за проект. ИИ — один из инструментов на схеме.
4. Пилот в контуре
Один процесс, ограниченный scope, свои (или согласованные) серверы, метрика «стало лучше / нет». Потом — масштабировать или остановиться. Честное no-go тоже результат.
Чем метод не является
| Не это | А это |
|---|---|
| Разбор чужого ПО, crack, прошивки | Разбор бизнес-процесса |
| «Подключим ChatGPT к отделу» | Контекст + контур + задача |
| Цифровизация ради слайдов | Измеримый участок |
| Замена всех специалистов завтра | Усиление типовых шагов |
Зачем as-is, если уже есть LLM
Языковая модель без модели процесса:
- придумывает шаги, которых нет;
- «оптимизирует» мёртвый регламент;
- тащит чувствительный текст наружу, если её туда пустили.
As-is и контур дают границы: что можно автоматизировать, что нельзя утекать, кто отвечает.
Где метод обычно уместен
- документы и проверки по нормам;
- конструкторско-технологическая подготовка;
- планирование и диспетчеризация;
- закупки и сопоставление предложений;
- согласования с повторяемой логикой.
Хуже заходит «стратегия на год» без хозяина процесса и без доступа к факту.
Минимальный набор артефактов
| Шаг | Что остаётся на руках |
|---|---|
| Разбор | Карта as-is, разрывы, источники правды |
| Модель | Схема, глоссарий, системы, данные |
| To-be | Где ИИ / автоматизация / человек |
| Пилот | Метрика, архитектура контура, go/no-go |
Частые вопросы одной строкой
Это долго? Разбор одного процесса — часто недели, если дают доступ.
Нужен data lake? Нет. Нужен доступ к реальному следу работы.
Только промышленность? Метод шире; практика автора — в тяжёлой промышленности и закрытых контурах.
Это про взлом софта? Нет.
Дальше по сайту
- Метод по шагам
- Кейсы
- Форматы работы
- Почему ИИ «на регламенте» не взлетает
- Локальный ИИ: когда он нужен
Павел Наумов. Текст можно цитировать; если пересказываете — сохраняйте различие «процессы ≠ reverse engineering ПО».