Когда схема не сходится с реальностью: как процесс строится по данным
Начнем с гипотетического кейса: в некой компании разбираются, почему согласование счетов занимает все больше времени. На встрече процесс рисуют на доске: документ получают, проверяют, согласовывают и передают в оплату. Все просто и понятно.
Тут бухгалтер вспоминает о возвратах из-за реквизитов, руководитель — об обязательном согласовании сумм более 500 тыс., специалист по закупкам — о повторных счетах. Через полчаса доска уже в стрелках. Как оказалось, все не так гладко и просто. Нюанс в том, что ответа так и нет — как работа чаще всего идёт в действительности.
Когда процесс именно восстанавливают
Для этого используют процессную аналитику (Process Mining) — технологию исследования бизнес-процессов по данным информационных систем. Один из её базовых методов — выявление процессов (Process Discovery), то есть автоматическое построение фактической модели по журналу событий. Такую классификацию приводит и профессиональное сообщество специалистов по процессной аналитике.
В журнале событие связано как минимум с экземпляром процесса, действием и временем. Для счёта это могут быть его номер, операция «проверка завершена» и отметка 14:36. Такие требования к данным приводит и Microsoft.
Алгоритм собирает события одного счёта в цепочку, затем сопоставляет тысячи цепочек между собой. Если после получения документа обычно начинается проверка, между действиями появляется связь. Если часть счетов возвращается автору, модель показывает петлю. Если маршруты расходятся, возникает развилка. Компания получает картину наблюдаемого поведения: частые пути, варианты и возвраты.
Почему карта внезапно становится огромной
Первая модель нередко пугает. Вместо четырёх этапов на доске компания видит десятки действий и сотни сочетаний. Это ещё не означает, что процесс устроен плохо. На карте могли смешаться редкие исключения, технические статусы и разные типы счетов.
Поэтому модель приходится читать слоями. Сначала можно оставить наиболее частые действия и связи, затем отдельно посмотреть крупные суммы, конкретное подразделение или счета с нарушенным сроком. Так «паутинка» превращается в проверяемые вопросы.
Допустим, долгие случаи заметно чаще проходят повторную проверку реквизитов. Это не доказывает причину задержки, но задаёт направление: выяснить, где возникают ошибки и можно ли проверить документ раньше. Карта помогает перейти от жалобы «всё долго» к конкретной гипотезе.
Карта ограничена исходными данными
Автоматически построенная модель не равна полной правде о работе. Она отражает события за выбранный период и только из подключённых систем. Если согласование прошло по телефону, сотрудник исправил файл вне системы или статус записали с опозданием, алгоритм этого не узнает.
Результат зависит и от выбранного уровня детализации. Слишком крупные действия скрывают возвраты и ожидание. Слишком мелкие превращают процесс в технический шум. Два аналитика могут построить по одному журналу разные по виду, но корректные модели, если отвечают на разные вопросы.
Process discovery не отменяет разговоров с сотрудниками и не выдаёт готовое решение. Его задача — дать разговорам фактическую основу. После этого модель можно использовать для анализа сроков, поиска отклонений и сравнения реального процесса с установленным порядком.
Нарисованная схема показывает, как люди представляют работу. Автоматически построенная — как она была зафиксирована в системах. Расхождение между ними обычно и становится началом анализа.