Обучение

Как увидеть бизнес-процесс таким, какой он есть на самом деле

Process Mining, выбор нотации и честная модель AS-IS

Сотрудники обычно описывают процесс так, как он должен работать. Журнал событий показывает, как он работает на самом деле — и вместо одного понятного маршрута там нередко обнаруживаются десятки вариантов. В этом материале разберём, из чего состоит журнал событий, чем исследование процесса отличается от проверки соответствия, на какие шесть вопросов должна отвечать хорошая схема и почему слишком аккуратная модель часто означает, что часть реальности в неё просто не попала.

Цифровой след вместо мнений

Рассказ сотрудника показывает, как процесс должен работать. Цифровой след — как он действительно работает в реальности

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

Для классического process mining достаточно трёх полей. Case ID определяет конкретный экземпляр процесса — например, заявку или заказ. Activity показывает, какое действие произошло. Timestamp фиксирует время. Полезно добавить и четвёртое поле — исполнителя: человека или систему.

Одна строка журнала событий

🆔 Case ID Заявка № 4712 — про какой кейс речь

⚡ Activity «Счёт выставлен» — что произошло

🕒 Timestamp 14 марта, 10:42 — когда это было

👤 Resource Менеджер или робот — кто сделал

Первые три поля обязательны, четвёртое желательно — без него не видно, где работа передаётся из рук в руки

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

Два источника, две разные силы

🗣️ Интервью и наблюдение · почему

Объясняют причины, показывают неформальные договорённости и обходные пути, дают контекст решения.

Зависят от памяти собеседника и от того, как он хочет выглядеть.

🧾 Журнал событий · как было

Даёт факт, время и порядок. Не забывает, не приукрашивает и не устаёт.

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

Слабость каждого закрывается сильной стороной другого — поэтому берут оба, а не выбирают

Два режима Process Mining

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

Первый режим — исследование. На вход подают event log, а сам процесс восстанавливается непосредственно из данных: системе заранее не задают, как он должен выглядеть, а смотрят, какие маршруты реально существуют. Второй режим — проверка соответствия. Здесь нормативная модель уже есть, и её сравнивают с фактической, чтобы увидеть, где регламент расходится с реальной работой.

Что кладут на вход и что получают

🔎 Исследование Вход: только журнал, модели нет · Выход: фактическая карта маршрутов со всеми вариантами · Берут, когда процесс никто целиком не описывал

📐 Проверка соответствия Вход: журнал и нормативная модель · Выход: список расхождений — где и как часто регламент нарушается · Берут перед автоматизацией

Режимы идут в этом порядке: сначала узнаём, что есть, потом сверяем с тем, что должно быть

Точность результата напрямую зависит от качества журнала. Событие без времени выпадает из маршрута. Одно и то же действие, записанное тремя разными формулировками, превращается в три разные ветки. А кейс без идентификатора вообще невозможно собрать в последовательность. Поэтому работу с логом начинают не с анализа, а со сверки словаря событий.

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

Один процесс — или десятки маршрутов

Как думали

📥 Принята ⚙️ Обработана ✅ Закрыта

Один маршрут — ровно тот, что нарисован в регламенте

Что в журнале

➡️ Часть напрямую ↩️ Часть с возвратами 🔀 Часть по кругу отделов

Это разные маршруты, а не отклонения от одного

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

В результате становится видно главное расхождение: между тем, как компания представляет свой процесс, и тем, как он устроен в реальности.

Как моделировать процесс

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

Три способа описать одно и то же

📘 стандарт BPMN События, задачи, шлюзы решений и потоки данных — подробно Первый вариант

люди + агенты 👥 субъекты S-BPM Кто участвует, как они общаются и что передают друг другу Второй вариант

💻 код Mermaid Быстрая текстовая визуализация: схема, документация, репозиторий Способ визуализации

BPMN подробен, но тяжёл для быстрого обсуждения; S-BPM показывает связи между субъектами и артефакты, а Mermaid позволяет все это визуализировать

В S-BPM акцент сделан на участниках процесса: как они действуют, кто с кем взаимодействует и какие сообщения или данные передаёт. Это особенно удобно там, где в одном процессе одновременно работают люди, системы и ИИ-агенты. Поэтому спорить о значках ради самих значков бессмысленно. Хорошая схема должна отвечать на шесть вопросов. Если хотя бы на один из них ответа нет, проблема не в нотации — просто в модели отсутствует часть картины.

Шесть вопросов к любой схеме

👥 Кто участвует Иначе неясно, с кем согласовывать правку

⚙️ Что делает Иначе схема — список названий шагов

🔗 Какие данные Иначе не видно повторного ввода

🧭 Где решения Иначе не видно, куда ставить агента

🔥 Где проблемы Иначе улучшать нечего, кроме вида схемы

📊 Как измеряется Иначе эффект правки нечем подтвердить

Спор о значках ничего не решает. Ценна схема, по которой в компании реально принимают решения о правках

AS-IS показывает процесс без прикрас

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

AS-IS показывает текущую работу такой, какая она есть, — без идеализации и попытки подогнать её под регламент. Если реальный процесс сложный и хаотичный, хорошая диаграмма совсем не обязана выглядеть красиво. Слишком аккуратная схема чаще говорит о том, что часть настоящей сложности в неё просто не попала.

Семь элементов хорошего AS-IS

ЭлементЗачем он в модели

⚙️ Фактические операции То, что делают, а не то, что предписано

👥 Роли участников Кто выполняет шаг — с ним и обсуждать изменение

📥 Входы и выходы Что приходит на шаг и что он отдаёт дальше

📄 Артефакты Документы и записи, которые остаются после шага

🧭 Точки принятия решений Места, где процесс выбирает маршрут

📊 Текущие метрики Числа до изменения, с которыми потом сравнивают

🚨 Исключения и эскалации Что происходит, когда стандартный сценарий не сработал

Это рабочий инструмент, с которым разбирают устройство бизнеса

Разница с регламентом принципиальная. Регламент описывает, как должно быть. AS-IS фиксирует, как всё устроено сейчас, и используется как рабочая модель: именно на неё опираются, когда решают, что менять. Поэтому такую схему обязательно нужно сверять с журналом событий.

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

Три следа, которые ищут в журнале

⏳

Задержка

большой разрыв между соседними событиями

↩️

Возврат

одно действие встречается у кейса дважды

🔀

Обходной путь

в маршруте шаг, которого нет в модели

Все три ищутся в журнале механически, без единого интервью — а объяснять их приходится уже людям

Из чего складывается разрыв

📐 Схема считает

Сумму длительностей операций: столько занимает сама работа, если делать её подряд и без перерывов.

Получается двадцать минут — и это честное число.

🧾 Журнал считает

Время от первого события кейса до последнего. Сюда попадают очереди перед шагами, ожидание ответа от смежников, повторные проверки и ручные операции.

Получается два дня — и это тоже честное число.

Оба числа верны, но управлять можно только вторым — именно его видит клиент

Где процесс ломается на самом деле

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

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

Четыре отклонения и что за каждым стоит

Что происходитКак выглядит в кейсеЧто за этим стоит

🚧 Исключение Стандартный сценарий перестал работать: не хватает данных Источник данных, на который процесс не рассчитывал

🙋 Эскалация Кейс уходит наверх и ждёт человека, а не системы Правило, которое не выписано

↩️ Возврат Кейс проходит один и тот же участок дважды Проверка, которая стоит слишком поздно

✍️ Ручная операция След остаётся только в почте или в таблице Разрыв между двумя системами

Правая колонка — это и есть список задач: каждое отклонение указывает на конкретную причину, а не на нерадивого сотрудника

Две модели одного и того же процесса

🖼️ Красивая Только основной сценарий · помещается на слайд · её приятно показывать · исключения обнаружатся, когда агент уже работает

🩻 Честная Основной сценарий вместе с возвратами, эскалациями и обходными путями · выглядит сложно · зато видно, где задержки и сколько кейсов идёт мимо основного маршрута

Схема сложная не потому, что аналитик плохой,
а потому что таким оказался процесс

Единственный способ упростить правую схему — сначала упростить сам процесс

Что важно запомнить

🧾

Для журнала событий достаточно трёх полей
Case ID, activity и timestamp. Четвёртое поле — исполнитель — показывает, где работа переходит от одного участника к другому.

🗣️

Данные не отменяют интервью
Журнал показывает, что произошло на самом деле, а человек объясняет почему. Нужны оба источника.

🔎

Сначала исследуем, потом сверяем
Первый режим восстанавливает реальные маршруты по данным, второй показывает, где регламент разошёлся с практикой.

📘

Нотация — не главное
Схема должна отвечать на шесть ключевых вопросов. Если ответа на один из них нет, проблема не в значках, а в неполной картине процесса.

🩻

Слишком красивый AS-IS должен насторожить
Скорее всего, часть реальной сложности в такую модель просто не попала.

💰

Основные потери скрываются в исключениях
Возвраты, эскалации, ожидания и ручные операции создают основную часть задержек и затрат.

🩻

AS-IS создают не для красивой презентации,
а чтобы понимать, что именно менять.

Дальше — к практике

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

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

От диагностики бизнеса
— к работающему агенту.

Пройти курс