Руководители крупных компаний и госкорпораций часто относятся к внедрению Process Mining с осторожностью. И их можно понять: если инструмент аналитики потребует изменений в работающих ERP, промышленных системах или государственных платформах, проект может обернуться остановкой критических процессов. Риск потери бюджета и срыва сроков слишком высок, чтобы проводить эксперименты в этой области.
Но на практике технология процессного анализа устроена иначе. Ей не нужен прямой доступ к системам и не требуется переписывать код или менять архитектуру. Аналитика строится на данных, которые уже существуют в виде цифровых следов. Правильно организованная API-интеграция или выгрузка через промежуточный слой позволяет получить полную картину процессов, не затрагивая сами источники. В статье рассказываем, как это можно сделать и что для этого потребуется.
Почему Process Mining не требует вмешательства в источники данных
Process Mining (процессная аналитика или аналитика процессов) — технология анализа данных из информационных систем, которая помогает восстановить реальный ход бизнес-процессов и найти задержки, ошибки и лишние действия.
Главное опасение перед внедрением Process Mining связан с убеждением, что придется сильно, сложно и дорого встраиваться в логику ERP или менять настройки учетных систем. На самом деле архитектура этого подхода работает с данными, а не с конкретными системами, то есть не нужно писать в базу, менять справочники или останавливать бизнес-процессы для проведения выгрузки.
На практике это означает read-only доступ при анализе — это доступ только для чтения, когда система может только смотреть на данные внутри компании, но не изменять их. Аналитическая платформа подключается к копии данных или к промежуточному хранилищу и забирает информацию для построения лога событий (он же — event log или лог событий). Исходная система при этом продолжает работать в обычном режиме. Также не возникает никаких дополнительных запросов, которые могли бы замедлить работу пользователей, если выгрузка настроена через репликацию данных или ночные срезы.
Репликация данных — создание копии данных из исходной системы для работы с ними без постоянного обращения к основной базе. Условно, система делает себе копию данных и обращается к ним, а не в корпоративную СУБД.
Именно поэтому процессная аналитика не требует перестройки ИТ-ландшафта. Она встраивается поверх существующей инфраструктуры и использует то, что уже накоплено в журналах, таблицах и базах данных. Для крупной организации это принципиальный момент: проект становится инструментом наблюдения за тем, как на самом деле выполняются процессы в компании на разных уровнях.
Из каких систем можно получить данные и как
Источники данных для процессного анализа почти всегда уже есть в контуре компании. Весь вопрос всегда в том, как ее корректно извлечь, не создавая нагрузки на работающие системы (и не останавливая их).
Крупные ERP (та же 1С или аналоги), содержат десятки тысяч таблиц, и найти в них нужные следы процесса — отдельная задача, иногда со звёздочкой. В процессном анализе данные извлекаются через ETL/ELT так: сначала определяется набор таблиц и полей, затем настраивается маппинг данных под структуру записи событий — это могут быть case ID, активность, временная метка и другие идентификаторы. Для этого как раз и используется репликация данных в отдельное хранилище, чтобы не трогать продуктивный контур.
Маппинг данных — сопоставление полей и статусов из разных систем, чтобы привести их к единому формату для анализа.
BPM-системы и платформы с workflow-движком обычно хранят историю статусов в явном виде, что упрощает выгрузку. Для государственных информационных систем и СМЭВ доступ строится через регламентированные API-интеграции или через шину данных (ESB), которая уже может быть развернута в организации. В госконтуре критично соблюдение требований по защите информации, поэтому нужно заранее согласовывать с ИБ- и ИТ-подразделениями извлечение данных.
Что нужно подготовить до начала интеграции: чек-лист
Вот базовые направления, которые стоит проверить до старта:
Типичные проблемы при интеграции и как их решать
Даже при аккуратном подходе интеграция сталкивается с препятствиями. На практике можно выделить три ситуации встречаются чаще всего.
Неполный или «грязный» event log
Первая проблема в том, что в журналах могут отсутствовать временные метки, встречаться дубли или несогласованные справочники. Чтобы такого не было, до построения карты процесса нужно проверить три обязательных поля: идентификатор случая, активность и время, плюс настроить автоматическую валидацию перед загрузкой. Если данные в источнике фиксировались некорректно, лучше это выявить на начальном этапе.
Сложность извлечения из кастомизированной ERP
Модульная структура ERP-системы (особенно с большим количеством кастомных доработок) затрудняет сборку сквозного процесса. Мы рекомендуем использовать промежуточный слой или готовые коннекторы, которые приведут данные к стандартному формату.
Саботаж (или неявное сопротивление) со стороны команды
Сотрудники могут начать воспринимать процессный анализ как инструмент контроля. Лучше начинать с пилотного процесса, где выигрыш от оптимизации очевиден даже сотрудникам, и показывать результаты руководств на языке бизнеса (например, сокращение времени цикла, снижение числа возвратов, высвобождение ресурсов и пр.). А потом, когда пилотное внедрение покажет свою эффективность и сотрудники к нему привыкнут и сами начнут использовать — раскатывать на остальные отделы.
FAQ
-
1За какой период нужны данные перед первым анализом?Всё зависит от процесса. Для пилота достаточно одного-двух месяцев исторических данных, чтобы увидеть основные отклонения, а для сквозного анализа закупки или договорного процесса может потребоваться до 18 месяцев, чтобы захватить полный цикл от заявки до поставки (или даже больше, если средний срок полного цикла сделки превышает полтора года).
-
2Нужно ли останавливать системы на время выгрузки?Нет, read-only доступ и выгрузка через копии или промежуточные слои не останавливают работу источников. Если используется инкрементальная загрузка новых данных, нагрузка на продуктивный контур остается минимальной и можно обойтись без остановки
-
3Что делать, если в существующем хранилище данных нет нужной истории о событиях?В первую очередь — проверить, какие атрибуты и статусы вообще сохраняются в системе. Часто в инфоконтуре хранится только общая информация (файл создан, запись звонка удалена и т.д.), а полная и детальная история изменений отсутствует. В этом случае нужно создать специализированный контур для процессного анализа, который забирает исходные данные из источников и хранит их в формате, пригодном для построения лога событий.
Заключение
Рынок процессной аналитики в России растет быстро: по итогам 2025 года он вырос на 53% и достиг 1,4 млрд рублей, а каждая третья крупная компания уже использует или пилотирует технологию. Если вы хотите понять, как встроить Process Mining в ваш ландшафт без риска для работающих систем, проведите выборочный аудит источников данных. Это поможет вам понять, какой объем подготовки потребуется.
Мы занимаемся, разработкой, автоматизацией и внедрением технологий процессного анализа в компаниях разного уровня — от частного бизнеса до высоконагруженных проектов государственного уровня со строгими требованиями к защите информации (включая работу с гостайной), устойчивости и надежности таких систем. Свяжитесь с нами, чтобы получить план работ по внедрению процессного анализа в вашей компании.
