Время прочтения: 4 мин.

Процесс формирования лога можно представить следующим образом:

  1. Обогащение данных из источников общими данными

На этом этапе нам нужно, чтобы данные из источников содержали в том числе набор общих полей. Этот набор полей должен содержать значения, по которым можно идентифицировать к какому экземпляру процесса данная запись относится. Например, если необходимо исследовать процесс оформления клиентом кредита, то нам понадобятся поля с данными клиента (ФИО, дата рождения). В этом случае мы считаем, что экземпляром (отдельным случаем) процесса будет прохождение пути конкретным клиентом, а значением этого экземпляра – данные о клиенте. И теперь каждая запись из источников принадлежит конкретному случаю. Добавленные поля нам пригодятся для этапа формирования атрибута case_id.

2. Формирование атрибутов Process mining

В источниках, откуда мы брали данные, может не храниться информации о минимальном наборе атрибутов для process mining. Эту проблему можно решить следующим образом.

Начнем с case_id – это идентификатор отдельно пройденного процесса (в случае примера) выдачи кредита конкретному клиенту. Мы генерируем значение для case_id путем соединения данных из полей – в нашем примере это ФИО клиента и его дата рождения, удаляем из этого соединения пробелы и шифруем получившуюся строку с помощью хэш алгоритма md5. В результате, мы получаем последовательность из 32 шестнадцатеричных цифр. Этот способ даёт уникальность, возможность привязывать case_id к данным клиента, при этом защищая эти данные и это достаточно простой способ создания значений для атрибута case_id. При необходимости, можно дополнительно преобразовать получившиеся значения.

Аctivity – это этап прохождения процесса. Поле Activity формируется названием действия которая соответствует характеру операции. Если данные из источника содержит один тип записей, то создается поле с названием этапа. Если же выгрузка содержит несколько типов записей, как в случае с записями о выплате средств клиенту, то мы создаем поле с условиями через выражение case в SQL по содержанию сообщения. Это позволяет нам генерировать несколько типов названий activity. Activity готово

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

Для некоторых инструментов может потребоваться сортировка лога по времени

3. Приведение данных к единой форме

В каждой из источников, мы формируем набор полей, который будет содержать журнал событий. Помимо основных атрибутов (case_id, activity, datetime) мы можем оставить информацию из источников, которая будет представлена в виде свойств. Если в других источников этих полей нет, то они добавляются пустыми. Важно, чтобы в источниках совпадал набор полей, поскольку мы их будем объединять воедино. 


4. Объединение данных

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

5. Проверка лога

Проверяем получившееся значения case_id на уникальность, ведь при формировании при помощи алгоритма md5 мы можем столкнуть с коллизией – получением одинакового значения функции для разных входных значений. Проверить можно при помощи оконной функции DENSE_RANK. Алгоритм проверки такой: мы проверяли, имеется ли в рамках одного «case_id» несколько значений «ФИО клиента». С помощью dense_rank мы ранжируем значения «ФИО клиента» по партиции «case_id» и выводим второй ранг. Если записей со вторым рангом не найдено, то это значит, что мы сохранили уникальность значений преобразованием из второго этапа.

Итог

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