Первый проект Process Mining: как выбрать процесс для оптимизации, собрать команду и не застрять на этапе пилота

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

Эта статья — для тех, кто впервые запускает процессную аналитику: будущих руководителей центров компетенций, операционных директоров и процессных аналитиков. Разберем шесть шагов от постановки исследовательских вопросов и выбора процесса до оценки результатов пилота и перехода к постоянному мониторингу. Покажем, как собрать команду, определить KPI и принять решение о масштабировании. Возможности инструментов рассмотрим на примере VK Business Analytics — платформы VK Tech для анализа и оптимизации процессов.

Что должен показать первый проект

В опросе Deloitte 2025 года среди главных препятствий участники назвали качество данных, взаимодействие между функциями и перевод находок в измеримый результат. Отсутствие поддержки руководства назвали барьером 41% участников, в 2021 году таких было 26%. Сильный центр компетенций Deloitte относит к ключевым рычагам, которые позволяют получить ценность от технологии

С этими барьерами компания сталкивается уже в первом проекте, и по его итогам нужно ответить на два вопроса. 

• Есть ли в выбранном процессе эффект, который можно измерить в рублях или днях? 

• Кто отвечает за проект, прозрачность данных и развитие — чтобы работа не закончилась вместе с пилотом? 

Модель ниже мы построили под оба вопроса.

Модель опирается на методологию PM² (Process Mining Project Methodology), которую в 2015 году предложили исследователи Технического университета Эйндховена. 

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

Шаг 0. Сформулировать вопрос

Первый проект часто начинают с загрузки данных в надежде, что анализ сам покажет проблемы. Такой подход называют data-driven, и манифест IEEE по Process Mining допускает такой тип проекта. Однако для первого запуска он рискован: без конкретного вопроса аналитику будет трудно разобраться в вариантах процесса, а владельцу — понять, что делать с цифровым двойником из 400 веток.

В PM² исследовательские вопросы формулируют уже при планировании: они определяют, что именно нужно выяснить при анализе, чтобы достичь цели проекта. В жизненном цикле L* из манифеста IEEE этому соответствует нулевой этап — планирование и обоснование проекта.

Для каждого вопроса полезно сразу сформулировать гипотезу эффекта: сколько денег или времени можно сэкономить, если проблема подтвердится. Предварительная оценка поможет обсудить ожидаемый результат со спонсором проекта. Через восемь недель вы сравните ее с результатами анализа.

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

В VK Business Analytics, например, можно спросить, на каких шагах заявка на закупку ждет дольше всего, и получить ответ в виде текста, графика, карты процесса или дашборда. ИИ-помощник использует данные Process Mining и Task Mining, поэтому учитывает и обходные шаги, которых нет в регламенте. Аналитик проверяет, не вызваны ли обнаруженные отклонения ошибками или особенностями данных.

Приходите на демо VK Business Analytics — там мы покажем, как это работает на ваших процессах и какие рутинные задачи можно поручить ИИ-помощнику, чтобы у аналитика оставалось больше времени на выводы.

Шаг 1. Выбрать первый процесс по трем фильтрам

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

Фильтр 1. Экономический потенциал

Потенциал экономии можно приблизительно оценить по формуле:

потенциал ≈ число кейсов в год × доля проблемных кейсов × стоимость одной проблемы

Допустим, в компании обрабатывают 40 000 заявок на закупку в год, из которых 12% возвращаются на доработку. Каждый возврат требует в среднем 1,5 часа работы сотрудников по ставке 1 200 ₽ в час. Потенциальная экономия на возвратах составит: 40 000 × 0,12 × 1,5 × 1 200 = 8,64 млн ₽ в год. К этому добавляются потери из-за задержек: просроченные поставки, штрафы и упущенные скидки за раннюю оплату.

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

Фильтр 2. Доступность данных

Process Mining работает с журналом событий, который в минимальном варианте состоит из трех полей: идентификатора кейса (case ID), действия (activity) и времени события (timestamp). Ресурс, сумма, подразделение и другие атрибуты необязательны, но позволяют подробнее анализировать процесс.

Так выглядит фрагмент журнала событий по процессу закупок:

case_id,activity,timestamp,resourceZK-10482,Создана заявка на закупку,2026-03-02 09:14,ИнициаторZK-10482,Согласована руководителем,2026-03-02 15:40,Руководитель отделаZK-10482,Создан заказ поставщику,2026-03-05 11:02,ЗакупщикZK-10482,Изменена цена в заказе,2026-03-06 10:20,ЗакупщикZK-10482,Получено поступление,2026-03-17 08:55,СкладZK-10482,Оплачен счет,2026-03-24 16:30,Казначейство

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

— История статусов заявок: каждое изменение статуса становится событием

SELECT    r.request_number  AS case_id,    s.status_name     AS activity,    h.changed_at      AS event_time,    h.changed_by_role AS resourceFROM request_status_history hJOIN purchase_requests r ON r.id = h.request_idJOIN statuses s ON s.id = h.status_idWHERE h.changed_at >= '2025-10-01'UNION ALL-- События из связанного документа: заказ поставщикуSELECT    r.request_number,    'Создан заказ поставщику',    o.created_at,    o.created_by_roleFROM purchase_orders oJOIN purchase_requests r ON r.id = o.request_idWHERE o.created_at >= '2025-10-01';

Основная сложность обычно в том, чтобы определить связи между документами: по какому ключу заказ поставщику связан с заявкой, а счет — с заказом. Платформа процессной аналитики берет на себя часть работы по сбору данных. Например, VK Business Analytics получает события из 1С, SAP, Directum, Jira и других систем с логированием и объединяет их в журнал. Однако ключи для связи документов должна определить команда. Если ключа нет или его заполняют вручную и нерегулярно, такой процесс пока не подходит для первого проекта.

Манифест IEEE предлагает шкалу зрелости журналов событий от одной до пяти звезд. На уровне одной звезды события записывают вручную, и записи могут не соответствовать реальности. На уровне пяти звезд события фиксируются автоматически, журналы полны и надежны, а смысл каждого события понятен. Шкала описывает качество данных, а не зрелость организации. Для первого проекта стоит ориентироваться на уровень трех звезд и выше: система записывает события автоматически, и этим записям можно доверять.

До выбора процесса стоит задать ИТ пять вопросов:

1. В какой системе или системах проходит процесс от начала до конца?

2. Хранит ли система историю изменений статусов с датой и временем или только текущий статус?

3. Есть ли сквозной идентификатор, который связывает документы процесса?

4. За какой период доступна история? Для анализа нужно хотя бы несколько полных циклов процесса, а для сезонных процессов — полный год.

5. Кто предоставит доступ к данным и сколько времени займет согласование с информационной безопасностью?

Если процесс проходит через несколько систем и включает множество связанных объектов — например, заказ, несколько поставок и счетов, — стоит заранее рассмотреть объектно-ориентированный журнал событий. Классический формат XES закреплен стандартом IEEE 1849, первая редакция которого вышла в 2016 году, а действующая — в 2023 году. Он предполагает один идентификатор кейса на событие. Формат OCEL 2.0, выпущенный в 2023 году, позволяет связать событие сразу с несколькими объектами. Для первого проекта проще выбрать процесс, которому достаточно классического представления через кейсы.

Фильтр 3. Заинтересованный владелец

Владелец процесса превращает находки в изменения. Заинтересованность проверяется тремя признаками:

• у владельца есть свой KPI, который зависит от процесса: сроки, затраты, качество;

• он готов выделить время на интерпретацию цифрового двойника и разбор находок;

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

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

Матрица выбора

Чтобы сравнить процессы, удобно свести их в таблицу и оценить по каждому фильтру от 1 до 3 баллов. Ниже — рабочая модель для первого проекта. Ее можно адаптировать под компанию, изменив веса критериев.

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

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

Для первого запуска плохо подходят:

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

• Процессы без единого владельца, где каждый отвечает только за свой участок.

• Процессы с циклом в несколько месяцев и небольшим числом кейсов: за время пилота не удастся собрать достаточно статистики.

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

• процесс проходит в информационных системах;

• системы подробно и без искажений фиксируют его ход;

• данные хранятся достаточно долго для анализа;

• процесс массовый или ошибки в нем дорого обходятся.

В Ростелекоме такой подход позволил освободить 12% рабочего времени диспетчеров техподдержки и снизить на 31% трудозатраты второй линии по обращениям о домашнем интернете. Договоры стали согласовывать на 8% быстрее, а число маршрутов согласования сократилось на 13%. Об этом на конференции VK Business Analytics рассказала директор программ офиса трансформации Ростелекома Арина Смотрова.

Шаг 2. Собрать команду

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

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

В Аэрофлоте роли распределены похожим образом. Проектом руководит внутренний аудит: анализирует процессы, оценивает риски и готовит рекомендации. Бизнес определяет требования и метрики, затем внедряет изменения. ИТ-блок отвечает за архитектуру, сбор данных и безопасность. Об этом на конференции VK Business Analytics рассказала заместитель директора департамента внутреннего аудита Аэрофлота Татьяна Кутакова. Главное из ее доклада опубликовано в канале VK Tech.

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

Шаг 3. Спланировать пилот и заложить KPI

Deloitte оценивает длительность proof of concept в 6–10 недель в зависимости от сложности процесса и доступности данных. Это оценка консультанта, а не рыночная статистика, но такой срок согласуется с последовательностью этапов PM². Затягивать пилот рискованно: спонсор теряет интерес к проекту, а данные успевают устареть.

Два уровня KPI

Для пилота определяют KPI двух уровней. Показатели процесса описывают, что команда измеряет и хочет улучшить. Показатели самого пилота помогают оценить, выполнил ли проект свою задачу.

KPI процесса. До начала анализа нужно зафиксировать базовые значения, чтобы через полгода можно было сравнить с ними результат.

Для первого проекта достаточно двух-трех показателей, напрямую связанных с исследовательскими вопросами из шага 0.

KPI пилота. Здесь оценивают выполнение основных задач проекта:

• собран ли журнал событий и признана ли доля событий, связанных с кейсом, достаточной по согласованию с ИТ;

• получил ли владелец цифровой двойник AS-IS не позже середины пилота;

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

• оценен ли эффект подтвержденных находок в рублях или днях;

• принято ли хотя бы по одной находке решение об изменении процесса.

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

В Аэрофлоте первый этап сознательно не называют пилотом. На конференции VK Business Analytics Татьяна Кутакова объяснила, что с самого начала от него ждали реальных изменений. Команда выбрала два процесса — электронный документооборот и реализацию ИТ-проектов. Для каждого построили цифровой двойник, определили возможные улучшения и подготовили дорожную карту. Далее команда настроит постоянный мониторинг и оценит эффект после внедрения изменений.

Шаг 4. Решить, масштабироваться ли

Решение о масштабировании принимают на встрече со спонсором в конце пилота. Критерии стоит согласовать заранее, чтобы оценивать результаты проекта, не полагаясь на впечатления от цифрового двойника.

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

Масштабировать проект лучше постепенно: сначала перевести пилотный процесс на регулярный мониторинг, затем подключить 2–3 соседних процесса, которые используют те же системы и тот же журнал событий, и после этого переходить к другим функциям.

По мере подключения процессов становится важнее отслеживать связи между ними. Например, сроки выполнения заказов могут срываться из-за задержек при согласовании документов в соседнем процессе. В VK Business Analytics такие связи показывает мультипроцессный граф. Он помогает аналитику найти источник проблемы, даже если ее последствия обнаружили в другом процессе.

Шаг 5. Перейти от исследования к постоянному мониторингу

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

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

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

Дашборды для владельцев процессов. Для текущей работы владельцу достаточно видеть динамику двух-трех KPI из пилота, список отклонений от регламента и сигнал о выходе показателя за установленный порог. Дашборд должен помогать ему принимать решения без участия аналитика. Собирать его с нуля необязательно: например, в базовую поставку VK Business Analytics входят готовые шаблоны для проверки соответствия регламенту (conformance checking) и анализа корневых причин отклонений.

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

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

Типичные ошибки первого проекта

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

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

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

• Не зафиксировать базовые значения KPI. Через полгода будет невозможно показать, что изменилось.

• Считать построенный цифровой двойник достаточным результатом. Успех пилота оценивают по принятым изменениям в процессе и рассчитанному эффекту.

• Оставить знания у подрядчика. Если команда компании не участвовала в ведении проекта, после ухода подрядчика работа с процессной аналитикой остановится.

Заключение

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

Минимальная команда включает владельца процесса, процессного аналитика и ИТ. Будущего руководителя центра компетенций стоит привлечь сразу, чтобы он прошел все этапы и мог использовать этот опыт в следующих проектах. На пилот отводят 6–10 недель, заранее определяют KPI процесса и самого проекта, а до начала анализа фиксируют базовые значения.

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