Process Mining: почему необходимо уделять внимание качеству данных?

Данные – это основа технологии Process Mining. От того, какие данные будут загружены в систему процессной аналитики, будет зависеть то, насколько точно и качественно будет восстановлен фактически исполняемый процесс, а также то, насколько глубокий анализ этого процесса можно будет провести. На основе данного анализа принимаются эффективные решения для оптимизации как отдельного процесса, так и всего бизнеса в целом. Именно поэтому при использовании технологии Process Mining следует особое внимание уделить качеству данных, на основе которых будет восстанавливаться фактически исполняемый процесс.

В нашей практике случалось немало ситуаций, когда из-за неполных или некачественных данных возникали трудности при восстановлении и анализе процессов.

Process Mining в действии.

Для простоты понимания того, что такое Process Mining и на основе каких данных системы процессной аналитики восстанавливают фактически исполняемые процессы, рассмотрим пример. Давайте представим, что существует онлайн-магазин, занимающийся поставкой определённой продукции, скажем, спортивной одежды и обуви. Сотрудники этой организации работают в CRM-системе. Все действия сотрудников в этой системе записываются и хранятся в табличном виде в журналах событий (логах).

Допустим, Вы заказали кроссовки в этом магазине. Через некоторое время Вам позвонил сотрудник магазина, уточнил модель кроссовок, получил от Вас информацию о дате, времени и месте доставки. Затем уже внутри магазина начался процесс по комплектованию Вашего заказа, передачи его в службу доставки и так далее. В терминологии Process Mining Ваш заказ – это кейс. А всё, что происходит с Вашим заказом – это события. Событийную цепочку отдельного кейса называют экземпляром процесса. Все действия, совершённые с Вашим заказом, записываются в журнал событий CRM-системы магазина и будут выглядеть примерно следующим образом:

Таблица 1.

Если импортировать эту таблицу в соответствующее программное обеспечение (ПО), основанное на базе технологии Process Mining, то это ПО сможет восстановить фактически исполняемый процесс. Затем с помощью этого же ПО можно будет проанализировать процесс на предмет возможных отклонений (в частности отклонений от эталонной модели), переработок, узких мест (тех мест, на выполнение которых не хватает ресурсов) и т.п.

Экземпляр процесса из Таблицы 1 в Process Mining системе будет выглядеть примерно следующим образом (Рисунок 1):

Рисунок 1. Пример отображения экземпляра процесса из Таблицы 1 в Process Mining системе.

Для того, чтобы Process Mining система смогла восстановить фактически исполняемый процесс, а аналитики смогли провести его углублённый анализ, к данным предъявляются определённые требования. Перечислим некоторые из них:

1. В журналах событий ИТ-систем организации обязательно должны присутствовать следующие данные:
• a. Уникальный идентификатор кейса (ID; первый столбец Таблицы 1). Им может выступать: номер договора, номер заказа, номер счёта, номер договора + номер счёта или какой-либо другой идентификатор, по которому можно отследить прохождение каждого экземпляра процесса от начала и до конца;
• b. Название события или шага процесса (второй столбец Таблицы 1);
• c. Дата и время начала каждого события или шага процесса (третий столбец Таблицы 1).
2. Каждое событие (шаг) каждого экземпляра процесса должно иметь цифровые следы в системе-источнике данных. Проще говоря, в ИТ-системах компании должны вестись журналы событий (логи) по всем событиям процесса, а не по отдельным событиям или частям процесса.
3. Данные по процессу должны быть целостными и однообразными. Необходимо выбрать уникальный идентификатор таким образом, чтобы было возможно проведение анализа массива данных, включающего в себя схожие кейсы (экземпляры процесса), а не проведение анализа множества уникальных и непохожих друг на друга кейсов (см. далее).

На практике немногие соблюдают вышеуказанные требования, в следствии чего при восстановлении фактически исполняемого процесса и его анализа возникают трудности. Рассмотрим ситуации, когда одним или несколькими из вышеупомянутых требований пренебрегают.

Ниже представлена очерёдность выполнения шагов процесса согласования рабочей документации (РД)

1. РД выдана,
2. РД взята в работу,
3. Начало согласования РД сотрудником (возможно повторение шага несколько раз),
4. Добавлено замечание к РД (может отсутствовать в некоторых экземплярах процесса),
5. РД согласована сотрудником или РД отклонена сотрудником (возможно повторение шагов несколько раз по причине согласования РД разными сотрудниками),
6. РД согласована или РД отклонена (итоговое решение),
7. Ведомость материалов (ВМ) выдана,
8. Смета выдана.

Каковы будут результаты восстановления модели этого процесса при использовании некачественных данных?

I. В данных отсутствует время начала событий.

Давайте представим, что в данных присутствует только метка даты выполнения событий, а метка времени отсутствует. Если шаги процесса выполнялись в разные даты, проблем не будет и логика процесса будет восстановлена должным образом, но, если несколько событий выполняются в одну и ту же дату, а метка времени отсутствует, Process Mining системе не удастся восстановить логику процесса. На Рисунке 2 представлена EPC-модель процесса (блок-схема), восстановленная на основе данных без указания метки времени. Логика процесса запутана, так как многие шаги процесса выполняются в одну дату, в связи с этим системе не удаётся распознать порядок шагов процесса:

Рисунок 2. EPC-модель процесса без указания метки времени.

Соответственно, нарушение логики процесса также наблюдается в отдельных экземплярах процесса (Рисунок 3):

Рисунок 3. Событийные цепочки экземпляров процесса без указания метки времени.

Рисунок 4. Поток функций процесса без указания метки времени.

Однако, картина кардинально меняется при добавлении метки времени. На Рисунке 5 представлена EPC-модель процесса с некоторыми изменениями. Были исключены некоторые кейсы и события процесса (скрыто 15% нерелевантных путей процесса), но к оставшимся событиям добавлена метка времени. Как видите, Process Mining система довольно точно восстановила логику процесса:

Рисунок 5. EPC-модель процесса с указанием метки времени.

В экземплярах процесса также теперь отсутствует путаница (Рисунок 6):

Рисунок 6. Событийные цепочки экземпляров процесса с указанием метки времени.

То же самое произошло и с потоком функций. Теперь можно точно отследить, как шаги процесса соотносятся между собой (Рисунок 7):

Рисунок 7. Поток функций процесса с указанием метки времени.

Также стоит отметить, что выполнение некоторых шагов процесса может занимать как минуты, так и секунды, а в некоторых случаях даже доли секунд. При НЕиспользовании метки времени исчезает возможность точного проведения анализа времени выполнения как всего процесса в целом, так и отдельных его шагов, что в последствии может не лучшим образом отразиться на принятии решений при оптимизации процессов и бизнеса в целом.

Вполне очевидный вывод: в данных необходимо использовать не только дату начала выполнения событий, но и время начала их выполнения.

II. В данных отсутствуют некоторые шаги процесса.

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

Рисунок 8. Неполные событийные цепочки экземпляров процесса, в которых отсутствует часть шагов процесса.

Как Вы наверняка заметили, в этих событийных цепочках отсутствуют обязательные шаги процесса: «Начало согласования РД сотрудником», «РД согласована сотрудником» или «РД отклонена сотрудником», «ВМ выдана». Таким образом в данном случае невозможно отследить, кто согласовывал документ, какое количество сотрудников согласовывало документ, сколько времени ушло на согласование документа каждым сотрудником, почему Смета была выдана без Ведомости материалов и в одном из случаев – была ли Смета выдана вообще, и т.д.

Для примера приведены лишь две событийные цепочки процесса, но такая же ситуация наблюдается по всему процессу, и отсутствуют не только вышеперечисленные события, но и другие. На месте отсутствующих событий возникает так называемый «чёрный ящик». Невозможно сказать наверняка, что и когда происходило в процессе на этих отрезках времени. Это приводит к невозможности проанализировать процесс и отдельные его экземпляры должным образом. Вероятно, искомые отклонения, узкие места или переработки кроются как раз в тех частях процесса, на месте которых образовался «чёрный ящик».

Как правило, такая ситуация возникает, либо если часть процесса не ведётся в ИТ-системах организации, либо же если сотрудники организации вносят данные в ИТ-систему вручную и относятся к этому с некоторой халатностью. Таких ситуаций необходимо избегать, если Вы желаете получить пользу от использования технологии Process Mining.

III. Неверно выбран уникальный идентификатор кейсов

И в заключение рассмотрим ситуацию, когда процесс восстановлен не только на основе неконсистентных данных, но и уникальный идентификатор кейсов был выбран таким образом, что процесс был восстановлен не в виде однородного массива данных, где многие экземпляры процесса или похожи друг на друга, или в точности повторяют друг друга (как, в принципе, и должно быть), а как множество уникальных и непохожих друг на друга экземпляров процесса. Как следствие, у процесса нет чёткой последовательности событий, его логика запутана.

Процесс совмещает в себе движение сотрудников внутри компании с выплатами денежных средств этим сотрудникам. Весь процесс невозможно вместить на скриншот даже с учётом сокрытия некоторых событий и путей процесса (Рисунок 9):

Рисунок 9. Часть процесса движения сотрудников и выплаты денежных средств.

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

Рисунок 10. Множество непохожих друг на друга событийных цепочек процесса.

Анализировать такой процесс крайне сложно и делать это возможно лишь в рамках конкретных гипотез или отдельных событийных цепочек процесса. При этом полноценное использование технологии Process Mining невозможно.

С большой долей вероятности можно сказать, что неверно был выбран не уникальный идентификатор кейсов, а сам процесс или связка процессов. При использовании технологии Process Mining старайтесь выбирать процессы организации, тесно связанные с её основной деятельностью, от которых в большинстве своём зависит прибыль организации.

Что Вы получите, используя технологию Process Mining?

Process Mining – уникальная технология, которая позволяет не только разово улучшить как Ваши процессы, так и бизнес в целом, но и поддерживать здоровье Ваших процессов и бизнеса на протяжении долгого времени, а также непрерывно улучшать их. Устранение узких мест, переделок и различных отклонений после проведения процессной аналитики позволяет снизить издержки компании и улучшить качество обслуживания клиентов. При этом нужно помнить о том, что большая часть потенциала улучшений лежит не в области используемого программного обеспечения, основанного на базе этой технологии, а в области данных, которые Вы импортируете в Process Mining систему.

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