Как система запоминает процесс: что такое и зачем нужен журнал событий
Компания видит, что часть заказов доставляют с опозданием. В отчёте есть средний срок и доля нарушений, но нет ответа на главный вопрос: что происходило с каждым заказом между оформлением и получением.
Следы работы уже хранятся в корпоративных системах. Заказ создали, оплату подтвердили, товар зарезервировали, передали на склад и отгрузили. Пока записи находятся в разных таблицах, они остаются отдельными фактами. Чтобы восстановить ход работы, их нужно связать по заказу и расположить по времени.
Из записей — в историю
Так появляется журнал событий (event log) — набор данных о действиях в рамках процесса. В классическом варианте каждая запись содержит три обязательных элемента: идентификатор экземпляра, название действия и время его выполнения. Например: заказ № 1452 — «передан на склад» — 10:42.
Microsoft приводит похожие примеры: идентификатором может быть номер заказа, обращения или пациента, а действиями — создание заявки, согласование, отклонение и доработка. К базовым полям добавляют исполнителя, подразделение, сумму, канал и другие характеристики. Они позволяют сравнивать маршруты по нужному признаку.
Если собрать историю заказов, станет видно, что быстрые отправления после оплаты сразу переходят на склад, а задержанные несколько раз возвращаются на проверку наличия. Теперь проблема выглядит иначе. Дело может быть не в доставке, а в том, как система резервирует товар.
Одна строка способна изменить вывод
Качество модели зависит от подготовки журнала. Если одному заказу присвоили разные идентификаторы, его история распадётся на несколько маршрутов. Если под одним номером объединили разные заказы, появится путь, которого не существовало. Неточное время может поменять действия местами, а пропущенная запись — скрыть возврат или ожидание.
Событием считается не любое изменение в базе. Для анализа нужны действия, имеющие смысл в процессе — «счёт получен», «проверка начата», «платёж согласован». Техническое обновление строки создаст шум, если принять его за этап работы.
Сложнее определить, что считать одним экземпляром процесса. В закупке связаны заявка, заказ, позиции, поставка и счёт. Если выбрать только номер заказа, часть отношений потеряется. Поэтому развиваются объектно-ориентированные модели, где событие может относиться к нескольким объектам.
Данных в системе может не хватить
Журнал отражает только зафиксированные действия. Если сотрудник уточнил информацию по телефону, переслал документ вне корпоративной системы или договорился с коллегой устно, этот фрагмент останется невидимым. Не поможет и система, которая хранит лишь текущее состояние заявки, перезаписывая предыдущие статусы.
Поэтому подготовка журнала — не механическая выгрузка. Нужно определить границы процесса, выбрать объект анализа, сопоставить названия действий в разных системах и проверить полноту истории. Для обмена данными между инструментами существует стандарт IEEE XES, но единый формат не исправляет ошибки в исходных записях.
Журнал событий превращает системные отметки в проверяемую историю работы. Её точность зависит от того, правильно ли компания связала события с реальными объектами и действиями.
Для анализа бизнес-процессов (Process Mining) журнал становится исходным материалом: по последовательности событий технология восстанавливает реальные маршруты, возвраты и ожидания. Ошибка в данных попадёт и в модель.
