На схеме заказ проходит согласование за один день. В системе тот же заказ две недели переходит между статусами, возвращается на исправление и ждет сотрудника, которого нет в формальном маршруте. Оба описания могут быть правдивыми: схема показывает правило, журнал событий — фактическое движение.
Process mining восстанавливает и анализирует процессы по цифровым событиям. IEEE Task Force относит к его задачам обнаружение фактических моделей, проверку соответствия заданному процессу и анализ организационных связей. До автоматизации команда получает фактическую картину и может проверить саму логику изменения.
Но журнал фиксирует только системные события. После изменения процесса часть ожидания способна переместиться за границу измерения. График тогда ускорится без заметной разницы для клиента.
Начните с управленческого вопроса
Фраза «построить карту процесса» слишком общая. Сформулируйте решение: почему заказы опаздывают, где возникает повторная работа, какие варианты создают просрочку, что изменится после нового правила.
Вопрос определяет границы данных. Для срока поставки важен путь заказа до отгрузки. Для дебиторской задолженности — события счета, оплаты, претензии и блокировки.
Что именно движется по процессу
Классический журнал событий связывает действия с одним случаем: заказом, заявкой или счетом. В реальности один заказ содержит позиции, связан с поставками, платежами и клиентом. Выбор одного идентификатора может скрыть часть картины.
OCEL 2.0 закрепил объектно-центрическую модель журнала, где событие связано с несколькими объектами. Редакция OCEL 2.1 сохраняет эту модель и добавляет варианты обмена на основе CSV и Parquet. Такой подход полезен для процессов, в которых заказ, товар, отправка и счет движутся по разным траекториям.
Минимальные поля и качество времени
Для события нужны идентификатор объекта, название действия и временная метка. Дополнительно полезны исполнитель, система, статус, канал, сумма, подразделение и причина отклонения.
Названия должны быть однозначными. «Обновлено» мало что объясняет: это может быть смена адреса, цены или ответственного. Если разные системы называют одно действие по-разному, понадобится словарь соответствий.
Временная метка кажется объективной, но у нее есть контекст. Система может записывать момент создания задачи, а фактическая работа начинается позднее. Часовые пояса различаются, ночная загрузка переносит события, ручная отметка появляется в конце смены.
Проверьте источник каждого времени и порядок событий. Нулевой цикл иногда означает пакетный импорт, а отрицательный — несогласованные часы или неверную связь объектов.
Процесс может «ускориться» только в журнале
После автоматизации система иногда создает заявку только после предварительной проверки. Измеряемый цикл от создания до закрытия сокращается, хотя отсчет для клиента начался еще при обращении. Другой вариант: сотрудники переносят разбор исключения в мессенджер, а в системе остается короткий идеальный маршрут.
Так возникает улучшение за счет смены точки наблюдения. До сравнения версий процесса закрепите внешний старт и внешний финиш, которые не зависят от интерфейса: вход письма, время заказа, факт отгрузки или поступление денег. Добавьте контрольные суммы объектов между системами. Если число заявок в журнале упало при прежнем входящем потоке, часть работы, вероятно, выпала из измерения и осталась в процессе.
Редкие варианты нельзя убирать слишком рано
Команда хочет увидеть основной маршрут и часто отфильтровывает редкие случаи. Но именно они могут создавать основную задержку: возврат на доработку, смена договора, ручная проверка или ожидание исключения.
Сначала покажите распределение вариантов и их вклад во время. Затем отделяйте технический шум. Иначе карта подтвердит заранее выбранную историю.
События фиксируют отдельные точки. Интервал между «согласование начато» и «согласование завершено» может включать работу, очередь или паузу из-за отсутствующих данных. Для ключевых интервалов проверьте природу задержки интервью и наблюдением. Process mining локализует место для проверки; причину устанавливают вместе с участниками процесса.
Фактический и установленный процесс
Conformance checking сопоставляет журнал с заданной моделью. Среди отклонений встречаются нарушения, разумные способы спасти срочный заказ и компенсация ограничений системы.
Классифицируйте отклонения: нарушение, разумное исключение, устаревшее правило и ошибка данных. Автоматизировать все отклонения одинаково опасно.
Журнал также может раскрывать поведение конкретных сотрудников. До анализа определите цель, доступ, срок хранения и уровень детализации. Для поиска системного ограничения часто достаточно роли или подразделения без публичного рейтинга людей. Метрика должна оценивать полный процесс и исключать стимул закрывать статус раньше ради красивого времени.
Короткая проверка до большого проекта
Возьмите один месяц и один тип объекта. Посчитайте долю записей без идентификатора, событий без времени, дубликатов и невозможных последовательностей. Выберите несколько случаев и восстановите их вручную вместе с владельцем процесса.
Если журнал не позволяет объяснить конкретный заказ, масштабирование на год только умножит неопределенность.
Карта может показать очередь перед одним решением, неполные данные или пакетное расписание как источник задержки. Роботизация ручного клика в такой ситуации ускорит секунды и оставит общий срок прежним.
Автоматизируйте участок, где понятна причина, есть стабильный вход и ожидаемый эффект на полный поток. После изменения повторите анализ на сопоставимом периоде.
Базовая линия до изменения
До пилота сохраните длительность полного цикла, долю повторной работы, число вариантов и очередь на ограничивающем этапе. Иначе после внедрения останется сравнение впечатлений: новая система быстрее открывает форму, но общий заказ по-прежнему ждет два дня.
Периоды должны быть сопоставимы по типу заказов, загрузке и сезонности. Если это невозможно, разделите поток на сегменты и прямо укажите ограничения сравнения. Оценка должна показывать влияние изменения на полный бизнес-процесс. Локальная операция в удобной выборке для такого вывода недостаточна.
Что должно остаться после первого этапа
Первый этап должен дать словарь событий, оценку качества данных, карту вариантов, интервалы ожидания и список проверенных причин. Рядом — решения, которые можно протестировать, и метрика полного процесса.
Карту process mining сопоставляют с разговорами и наблюдением за работой. Тогда обсуждение становится проверяемым: вместо «обычно мы делаем так» команда видит конкретные случаи, частоту и время.
Для Tess Technology process mining — не самостоятельная красивая карта, а часть диагностики. Мы проверяем, где процесс теряет время и поток, сопоставляем журнал с реальной работой, отделяем ограничение от симптомов и формируем короткий список изменений для проверки. Такой этап полезен до покупки платформы или разработки автоматизации. Подробнее — об операционной эффективности и системной ИИ-трансформации.
Продолжение темы: TOC-диагностика компании и роботизация склада по полному потоку заказа.
