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

Выбираем необходимые данные

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

  1. Case ID: Уникальный идентификатор, необходимый для отслеживания дела в течении всего процесса (пример: номер обращения)
  2. Activities: Это различные состояния в которых пребывает дело (пример: регистрация обращения)
  3. Event: Отметка дела по времени

Несколько советов после получения начальных данных:

  1. Для проверки “Адекватности” данных можно построить граф процесса, он должен быть несколько похожим на анализируемый процесс (данный граф не является заключительным, и необходим исключительно для проверки данных).
  2. Данные можно обогатить дополнительной информацией такой как: информация о работнике, совершившем дело; информация о клиенте;
  3. Используйте здравый смысл при сборе данных: соответствует ли то, что вы видите, ожиданиям и нужны ли все эти данные?

Начинаем уборку!

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

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

  1. Одним из способов поиска отклонений в данных является работа с метаданными. Как пример, значения, которые находятся на расстоянии более двух стандартных отклонений от среднего значения для данного атрибута, могут быть помечены как потенциальные выбросы. Таким образом мы найдем либо шум, либо необычные значения, требующие дополнительного изучения.
  2. Перегрузка полей является еще одним источником ошибок, которые обычно возникают, когда разработчики сжимают новые определения атрибутов в пригодные для использования (битовые) части уже определенных атрибутов (например, при использовании неиспользуемого бита атрибута, диапазон значений которого использует только, скажем, 31 из 32 битов)
  3. Некоторые несоответствия данных могут быть исправлены вручную с использованием внешних ссылок. Например, ошибки, допущенные при записи данных, могут быть исправлены путем выполнения бумажной трассировки.

Все преобразования условно можно разбить на 2 этапа: работа на уровне данных (1 и 2 пункт), работа на уровне предметной области (3 пункт).

Эти 2 этапа повторяются друг за другом до тех пор, пока нас не будет устраивать результат. Надо понимать, что повтор этих этапов занимает огромное количество времени, поскольку исправление ошибок на одном этапе ведет к получению ошибок на другом. Например, опечатка, такая как 20004 в поле “год”, может появиться только после того, как все значения даты будут преобразованы в один вид.