Доброе утро, коллеги.

Здесь я бы разделил две вещи: развитие инструментов Process Mining и вывод о том, что аналитик им больше не нужен. Первое действительно происходит. Второе из описанных возможностей не следует.

Давайте возьмем простой пример из поста: 188 кейсов повторяют согласование службы безопасности. Process Mining действительно способен обнаружить такой паттерн автоматически. Но из факта повторения следует только то, что определенная последовательность действий встретилась повторно. А вывод "значит, не с первого раза" уже требует интерпретации.

Повторное согласование может быть следствием ошибки, изменения существенных данных заявки, требования регламента, появления нового объекта проверки или даже вполне нормальной логики конкретной ветки процесса. Чтобы определить, какой вариант перед нами, недостаточно знать последовательность событий.

Та же проблема есть и с утверждением, что 64% кейсов с повторными шагами означают неоптимальность процесса с точки зрения логики. Из данных следует, что 64% кейсов содержат повторные шаги. Чтобы назвать их неоптимальными, необходимо дополнительно установить, что эти повторения не выполняют необходимую функцию.

Именно здесь проходит важная граница между обнаружением паттерна и обнаружением проблемы.

Process Mining прекрасно работает с первым. Он может реконструировать фактический поток, находить варианты выполнения, измерять длительность переходов, обнаруживать возвраты, отклонения и потенциальные узкие места. Современный инструмент может самостоятельно выполнить значительную часть этой работы, а LLM - дополнительно интерпретировать результаты и формировать гипотезы.

Но бизнес-процесс не сводится к своему цифровому следу.

Event Log не содержит автоматически всего контекста, в котором выполняется процесс: правил принятия решений, организационных ограничений, распределения ответственности, мотивации участников, требований регламентов и действий, происходящих вне информационных систем. Поэтому наблюдаемое отклонение еще не является установленной проблемой.

Еще осторожнее, на мой взгляд, стоит обращаться с причинностью. Если определенный маршрут коррелирует с увеличенным временем ожидания, система может обнаружить эту связь. Но переход от "при таком маршруте ожидание больше" к "причина задержки заключается в перегрузке отдела" требует дополнительных данных и проверки. Корреляция между признаками процесса сама по себе не устанавливает причинно-следственную связь.

Получается довольно простая цепочка:

Наблюдаемый паттерн → гипотеза о проблеме → проверка в контексте процесса → установленная проблема → анализ причины → вариант изменения → оценка последствий → решение

Автоматизация постепенно движется по этой цепочке вправо. Это полезное и закономерное развитие Process Mining. Но возможность автоматически обнаружить паттерн, сформировать гипотезу и даже получить от LLM предложение по изменению процесса еще не превращает всю цепочку в автоматически выполненный анализ.

И особенно здесь показательна необходимость указать системе, какие завершения процесса правильные, а какие нет. Это уже привнесенное извне знание о процессе. Система видит, чем заканчиваются кейсы, но сама семантика "правильно" появляется не из Event Log.

Поэтому формула "загрузил логи - получил инсайты и предложения - осталось только принять решение" описывает скорее повышение доступности и автоматизацию инструментария Process Mining. Само "принять решение" здесь скрывает значительную часть аналитической работы: проверить интерпретацию, установить причины, учесть контекст, ограничения и последствия изменения.

Я подробнее разбирал эту границу весной в статье о Process Mining у себя на сайте. Process Mining может быть эффективным инструментом диагностики, источником гипотез и средством мониторинга. Но анализ цифрового следа процесса и анализ самого бизнес-процесса - это не одно и то же.