Как подготовить данные для SAP Process Mining by Celonis

На примере данных из системы управления ИТ-услугами (ITSM).

В предыдущей статье SAP Process Mining или как разобраться в своих бизнес-процессах мы говорили о Process Mining и о его применении в корпоративной среде. Сегодня мы хотим более подробно рассказать про модель данных и процесс ее подготовки. Мы рассмотрим компоненты, как они связаны между собой, какой формат данных запросить у владельцев данных и каким может быть подход к генерации таблицы событий для SAP Process Mining by Celonis.

Модель данных в SAP PROCESS MINING by CELONIS

Структура данных в инструменте SAP Process Mining by Celonis довольно проста:

• «Таблица cобытий». Это обязательная часть модели данных. Такая таблица может быть только одна в каждой отдельно взятой модели данных. По ней автоматически формируется граф процесса. См. рисунок 1.
• Справочники — это любые другие таблицы, расширяющие «таблицу событий» дополнительной аналитической информацией. В отличии от нее в справочниках информация не меняется со временем. Точнее, она не должна меняться на том интервале времени, который мы анализируем. К примеру, это может быть таблица с описанием свойств договоров, закупочных позиций, заявок на что-либо, сотрудников, регламентов, контрагентов и прочих объектов, которые так или иначе участвуют в процессе. При этом в справочнике будут описаны всевозможные статические свойства этих объектов (суммы, типы, названия, имена, размеры, отделы, адреса и другие всевозможные атрибуты). Справочники не являются обязательными. Можно запустить модель данных и без них. Просто анализировать такой процесс будет менее интересно.

Рисунок 1. Модель данных в Proces Mining: таблица событий и справочник экземпляров процесса

Таблица событий – это стандартная таблица (физическое хранение, как противоположность логическим таблицам) в in-memory платформе SAP HANA. Справочники могут быть представлены как стандартными таблицами (физическое хранение), так и расчетными таблицами (Calculation Views). В редких исключениях может возникнуть необходимость добавить к существующей модели данных какой-то небольшой справочник в виде CSV или XLSX. Такая возможность существует непосредственно в графическом интерфейсе.

Ниже мы подробнее разберем каждую из этих двух составляющих модели данных.

«Таблица событий» (она же «лог событий») содержит как минимум три обязательные колонки:

1. Идентификатор процесса — это уникальный ключ для каждого экземпляра процесса (например, номер обращения, инцидента или задачи). В примере на рисунке 2 это колонка «CASE_ID».
2. Активность. Это название шага в процессе – некое событие, которое нам интересно. Именно из активностей и будет состоять граф процесса (колонка «EVENT»).
3. Временная метка произошедшего события (колонка «TIMESTAMP»).

Рисунок 2. Пример таблицы событий

В текущей версии SAP Process Mining by Celonis поддерживается до 1000 уникальных событий в одной модели данных. То есть число уникальных значений в колонке «EVENT» в примере выше (в вашей таблице событий она может называться иначе) должно быть не более 1000. А самих событий (т.е. строк в этой таблице) может быть довольно много. Нам встречались примеры на сотни миллионов событий в одной модели данных.

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

Рисунок 3. Пример таблицы событий с двумя метками времени

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

Дополнительные колонки – это любая интересная вам информация, которая изменяется с течением процесса или связана с конкретным событием. Например, имя сотрудника, который совершил событие, рабочая группа, текущий приоритет заявки. Акцент на зависимости от времени здесь не случаен. В таблице событий рекомендуется оставить только изменяемые данные. Всю остальную статическую информацию лучше вынести в отдельные справочники. Другими словами, лог событий надо, по возможности, нормализовать. Делается это не столько ради сокращения объема данных, сколько ради облегчения дальнейшей работы с PQL-выражениями на этапе построения аналитических отчетов.

Пусть все будет на своих местах

Что будет, если добавить колонку со справочной информацией в «таблицу событий»? В общем-то, ничего страшного не произойдет, по крайней мере, на первых порах. И для быстрого тестирования какой-то идеи такой вариант вполне подходит. Негативных последствий может быть только два: ненужное размножение копий данных и дополнительные сложности в некоторых аналитических формулах. Этих трудностей можно было бы избежать, если все дополнительные данные были вынесены в справочник. В общем, лучше сразу делать правильно.

Немного о лицензировании

Таблица событий связана с лицензированием SAP Process Mining by Celonis. Одна модель данных = 1 лицензия = 1 лог событий. С определенной оговоркой можно сказать, что 1 лог событий = 1 бизнес процесс. Оговорка будет следующая: могут возникнуть ситуации, когда несколько процессов укладываются в один лог событий, и наоборот – на один процесс намеренно создается несколько логов событий. К тому же, термин «бизнес-процесс» может трактоваться с точки зрения данных довольно широко. Поэтому для целей лицензирования за очевидный критерий выбрано число логов событий. Именно на этот критерий и следует опираться.

Справочники

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

Здесь следует оговорить один частный случай. Когда речь заходит о данных пользователя, исполняющего шаги в бизнес-процессе, возникает вопрос: а является ли такая информация справочной? С одной стороны, да – это статичные данные. Было бы хорошо оставить в таблице событий только некий «USER_ID», по которому с активностью будут связаны ФИО, должность и департамент пользователя, принадлежность к рабочей группе и прочее. Но с другой стороны, давайте представим, что мы анализируем бизнес-процесс на участке времени 2-3 года. За это время пользователь мог сменить несколько должностей и переходил между отделами или рабочими группами. Получается, что это уже изменяемая со временем информация. И в этом случае её следует оставить в таблице событий, что в свою очередь приведет к тому, что кроме «USER_ID» в логе событий появятся такие колонки как «рабочая группа», «должность», «отдел» и даже «ФИО» (фамилия ведь тоже могла поменяться за это время). В целом, вопрос нормализовать ли информацию о пользователе или нет остается на усмотрение заказчика.
Справочники можно добавлять к существующей модели данных в любой момент времени.

Сделать это довольно просто:

1. Создается таблица в SAP HANA.
2. Таблица добавляется к общей модели данных с помощь кнопки «Импорт данных».

   
   Рисунок 4. Импорт таблицы или файла в существующую модель данных

3. В графическом интерфейсе указывается ключ (или ключи), по которому новый справочник связывается с таблицей событий и/или с другими справочниками. Для этого достаточно щелкнуть на значок в одной таблице и затем на соответствующий в другой таблице.

   
   Рисунок 5. Связывание таблиц в модели данных по произвольному полю (в данном случае – CASE_ID)

4. В меню «Статус» надо нажать кнопку «Перезагрузить из источника». Обычно этот процесс занимает несколько секунд.

   Рисунок 6. Перезагрузка модели данных из источника

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

Для условно маленьких справочников есть еще одна возможность: не вполне промышленный вариант, конечно, но тоже бывает полезным. Речь о загрузке файлов CSV, XLSX, DBF через графический интерфейс непосредственно в модель данных. Процедура остается точно такой же, как описано выше, только вместо таблиц базы данных используется подготовленный заранее файл, который загружается кнопкой «Импорт данных».

Таблица ЦС: справочник экземпляров процесса

Предыдущий разговор о справочниках начался с того, что они опциональны. Их можно вообще не добавлять в модель данных и ограничиться только таблицей событий. Это почти верно.
Один обязательный справочник все-таки существует. Это должна быть таблица, помеченная статусом «Таблица ЦС». ЦС – это цепочки событий. И, как вы догадались, ключом в этом справочнике будет «CASE_ID» — уникальный идентификатор экземпляра процесса. Такой справочник описывает статичные свойства отдельно взятых экземпляров процесса. Пример из ITSM: автор обращения, бизнес-услуга, дата закрытия или сотрудник, успешно решивший инцидент, признак массовости и т.д.

Рисунок 7. Пример Таблицы ЦС

И всё же обманул я вас не сильно. Если вы по какой-то причине решили не добавлять обязательный справочник в модель данных, то система сформирует его сама. Результат ее работы можно увидеть во вкладке «Статус»: если ваша таблица событий называется, скажем, «ITSM_EVENTS», то в пару к ней сгенерируется таблица «ITSM_EVENTS_CASES», как на рисунке 8.

Рисунок 8. Автоматически сгенерированная таблица цепочек событий (ЦС)

Автоматически сгенерированная таблица ЦС будет представлять собой очень простое описание экземпляров процесса: ключ, число событий, длительность процесса (как если бы вы сгруппировали таблицу событий по идентификатору процесса, подсчитали число строк и разницу между временем первого и последнего шагов). Поэтому имеет смысл создать свою собственную, более интересную версию таблицы ЦС. Её можно будет добавить в модель данных в любой момент времени. При этом, как только вы добавляете в модель свою Таблицу ЦС, то сгенерированный системой справочник (в нашем случае это «ITSM_EVENTS_CASES») автоматически удалится из модели данных.

Почему «Таблица ЦС» может быть интересна? Именно она отображается в графическом интерфейсе как детализация процесса. Если аналитик во время работы с моделью данных нашел в процессе что-то интересное и захотел спуститься до отдельных конкретных примеров, то он воспользуется отчетом «Просмотр ЦС», то есть детализацией. Открыв такой отчет, вы узнаете в нем справочник процесса (совмещенный с таблицей событий, конечно же). Поэтому добавьте в «Таблицу ЦС» всё, что может пригодиться аналитику для понимания свойств процесса и условий его протекания.

Рисунок 9. Синтетический пример отчет «Просмотр ЦС»

Как добавить свой справочник процесса к модели данных:

1. Создается таблица в SAP HANA.
2. Таблица добавляется к общей модели данных с помощь кнопки «Импорт данных».
3. В графическом интерфейсе, в свойствах таблицы нужно выставить ей роль «Таблица с ЦС».

   
   Рисунок 10. Роль «Таблица с ЦС» для обозначения справочника экземпляров процесса

4. В графическом интерфейсе свяжите таблицу ЦС с таблицей событий по идентификатору процесса. Выполняется этот шаг точно так же, как и в случае обычного справочника – кнопкой с символом ключа () напротив соответствующего поля.
5. В меню «Статус» надо нажать кнопку «Перезагрузить из источника».

Важное замечание: колонка «CASE_ID» (в каждом отдельном случае она может называться как-то иначе) в таблице ЦС, которая содержит идентификатор процесса и используется для связки с таблицей событий, должна содержать только уникальные значения. Это вполне логично. И если по какой-то причине это не так, то при загрузке модели данных на шаге (5) будет выдана соответствующая ошибка (о невозможности выполнить операцию «JOIN» таблицы событий и таблицы ЦС).

Создание модели данных из истории изменений

На практике мы сталкиваемся с очень разными источниками данных для Process Mining. Их состав определяется выбранным бизнес-процессом и принятыми у заказчика стандартами.
Один из часто встречающихся случаев – данные из системы управления ИТ-услугами (ITSM, IT Service Management), поэтому мы решили разобрать этот пример в первую очередь. В действительности, жесткой привязки именно к ITSM в данном подходе нет. Его можно будет применить и в других бизнес-процессах, где источником данных является история изменений или аудит-лог.

Что попросить у IT?

Если вы не являетесь сотрудником ИТ или тем специалистом, который обслуживает базис ITSM, то будьте готовы к тому, что вас попросят сформулировать точный ответ на вопрос «что вам выгрузить?» или «что вам от нас надо?».

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

Есть два варианта ответов на вопрос «что вам выгрузить».

Вариант ошибочный: попросить базис выгрузить все изменения статусов заявки плюс набор очевидных атрибутов (скажем, приоритет, исполнитель, рабочая группа и т.д.). Во-первых, получится ограниченный набор аналитик: вы уже знаете, что вы будете измерять в процессе (отсюда и взялся набор атрибутов), поэтому Process Mining превратится в инструмент расчета КПЭ процесса (очень удобный, надо заметить, инструмент; но все-таки хочется большего).

Во-вторых, каждый отдельно взятый ИТ-отдел по-разному трактует просьбу добавить в выгрузку дополнительные атрибуты заявки. Например, возьмём приоритет: он может изменяться во время работы над обращением. Обращение регистрируется с одним приоритетом, затем специалист рабочей группы его меняет, и оно закрывается уже с другим статусом. А теперь вопрос: в запрошенной вами выгрузке какому моменту соответствует приоритет? Изначально кажется, что значение приоритета должно соответствовать колонке «Дата и время события». А в реальности часто оказывается так, что указанным дате и времени соответствует только сам статус заявки, а все остальные колонки – это значения на момент выгрузки или на момент закрытия обращения. И узнаете вы об этом далеко не сразу.

Как мне кажется, есть вариант получше. Можно запросить данные виде следующей таблицы:

1. Номер обращения, инцидента, задачи (SD*, IM*, RT*, …) – идентификатор объекта в ITSM-системе (NVARCHAR)
2. Метка времени (TIMESTAMP)
3. Название атрибута (NVARCHAR)
4. Старое значение (NVARCHAR)
5. Новое значение (NVARCHAR)
6. Кто изменил (NVARCHAR)

Фактически, это ничто иное как история изменений каких угодно атрибутов. В интерфейсах ITSM-систем вы можете видеть такую таблицу на вкладках с названием «History» или «Журнал».

Плюсы такого подхода очевидны:

1. Простой и понятный формат выгрузки. Он знаком ИТ-специалистам по графическому интерфейсу самой системы. Не должен вызывать вопросов со стороны базиса.
2. Мы получаем список всех возможных атрибутов со всеми возможными значениями. Да, их получится много, скорее всего, несколько сотен. Но отсеять лишнее и неинтересное очень просто, а вот каждый раз запрашивать дополнительные выгрузки не всегда просто и всегда долго (особенно когда не знаешь, какие атрибуты вообще присутствуют в системе).
3. Это надежная модель данных. Её сложно испортить, если только не вносить ложную информацию преднамеренно.
4. Мы точно знаем, какое значение имел каждый атрибут в каждый момент времени. Это важно, потому что мы проверяем себя и убеждаемся в корректности модели. А в ходе анализа мы можем добавить промежуточные шаги в модель («увеличить масштаб») и определяем правильные значения атрибутов во всех дополнительных моментах времени.

Минусы второго варианта тоже понятны. И они, как мне кажется, могут быть решены (в отличие от проблемы неполных данных):

1. SQL-скрипт для подготовки данных становится несколько сложнее – по сравнению с вариантом, когда частичную подготовку данных для вас делает команда ИТ базиса (см. выше первый вариант запроса), сама того не подозревая. Да, он (скрипт) сложнее, но зато он один. Мне кажется, было бы плохой идеей разделять подготовку данных между командой ITSM и командой Process Mining. В идеале всю трансформацию перенести в команду Process Mining, чтобы они понимали, что именно происходит с данными, и чтобы минимизировать вмешательства в данные на стороне источника. Простой формат обмена данными помогает достичь этой цели.
2. Объем выгрузки получается большой. Порядок может быть таким: 10-30 ГБ/год для крупной компании. Но загрузить такой объем в HANA вообще не проблема и даже не рассматривается как задача. Кроме того, о «выгрузке» мы говорим только во время пилотного проекта, в то время как в промышленной эксплуатации будет использоваться ETL/ELT интеграция между источником данных и HANA (например, HANA Smart Data Integration), и этот пункт перестанет иметь значение.

Мне не хотелось бы утверждать, что это единственный правильный вариант получения данных из ITSM-системы для задач Process Mining. Но на текущий момент времени я склонен считать, что это наиболее удобный формат для данной задачи. Наверняка есть еще масса интересных подходов, и я буду очень рад обсудить альтернативные идеи, если вы поделитесь ими со мной.

Генерация Таблицы Событий

Итак, на выходе мы имеем историю изменений атрибутов заявок, инцидентов, обращений, задач и прочих объектов ITSM. Из такой таблицы есть возможность сгенерировать оба ключевых компонента модели данных Process Mining: таблицу событий и таблицу ЦС.

Для генерации событий на основе истории изменений нужно сделать следующее:

1. Из истории изменений соберите все уникальные значения колонки (условно) «название атрибута».
2. Определите изменение каких атрибутов вы хотели бы видеть на графе процесса. Что является для нас «событием»?
3. Создайте соответствующий Calculation View или напишите SQL-скрипт, который отфильтрует выбранные строки из истории изменений и сгенерирует таблицу событий.

Предположим, что таблица изменений представляет собой следующее:

CREATE COLUMN TABLE "SAP_PM"."ITSM_HISTORY" (

	"CASE_ID"	NVARCHAR(256),
	"ATTRIBUTE"	NVARCHAR(256),
	"VALUE_OLD"	NVARCHAR(1024),
	"VALUE_NEW"	NVARCHAR(1024),
	"TS"		TIMESTAMP,
	"USER"		NVARCHAR(256)
);

Сначала посмотрим на список всех присутствующих атрибутов. Это можно сделать в меню “Open Data Preview” или простым SQL запросом вроде этого:

SELECT DISTINCT "ATTRIBUTE" FROM "SAP_PM"."ITSM_HISTORY";

Рисунок 11. Контекстное меню с командой Open Data Preview в SAP HANA Studio

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

• Статус
• Был взят в работу
• Была изменена категория
• Нарушен крайний срок
• Нарушено время реакции
• Запрос был возвращен на доработку
• Ошибка 1-й линии
• Рабочая группа
• Приоритет

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

CREATE COLUMN TABLE 
"SAP_PM"."ITSM_EVENTS" (
 "CASE_ID"	NVARCHAR(256)
,"EVENT"	NVARCHAR(1024)
,"TS"		TIMESTAMP
,"USER"	NVARCHAR(256)
,"VALUE_OLD"	NVARCHAR(1024)
,"VALUE_NEW"	NVARCHAR(1024)
);

INSERT INTO "SAP_PM"."ITSM_EVENTS"
SELECT
	 "CASE_ID"
	,"VALUE_NEW" AS "EVENT"
	,"TS"
	,"USER"
	,"VALUE_OLD"
	,"VALUE_NEW"

FROM "SAP_PM"."ITSM_HISTORY"
WHERE "ATTRIBUTE" = 'Статус'
;

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

INSERT INTO "SAP_PM"."ITSM_EVENTS"
SELECT
	 "CASE_ID"
	,"ATTRIBUTE" AS "EVENT"
	,"TS"
	,"USER"
	,"VALUE_OLD"
	,"VALUE_NEW"

FROM "SAP_PM"."ITSM_HISTORY"
WHERE "VALUE_OLD" IS NOT NULL AND "ATTRIBUTE" IN (
	 'Был взят в работу'
	,'Была изменена категория'
	,'Нарушен крайний срок'
	,'Нарушено время реакции'
	,'Запрос был возвращен на доработку'
	,'Ошибка 1-й линии'
	,'Рабочая группа'
	,'Приоритет')
);

Расширяя список атрибутов в фильтре WHERE «ATTRIBUTE» IN (….) вы увеличиваете разнообразие шагов, которое отображается на графе процесса. Стоит отметить, что большое разнообразие шагов – это не всегда благо. Иногда слишком подробная детализация только мешает понимать процесс. Я думаю, что уже после первой итерации вы определите какие шаги нужны, а какие стоит исключить из модели данных (и свобода принимать такие решения и быстро под них перестраиваться – это еще один аргумент в пользу переноса работы по трансформации данных на сторону команды Process Mining).

Фильтр «VALUE_OLD» IS NOT NULL, скорее всего, вы замените на что-то более подходящее для ваших условий и для выбранных атрибутов. Постараюсь объяснить смысл этого фильтра. В некоторых популярных реализациях ITSM-систем в момент регистрации (открытия) обращения в журнал заносится информация об инициализации всех атрибутов объекта. То есть по всем полям проставляются какие-то значения по умолчанию. В этот момент VALUE_NEW будет содержать то самое инициализирующее значение, а VALUE_OLD ничего не будет содержать – ведь истории до этого момента еще никакой не было. Эти записи нам совершенно не нужны в процессе. Их следует убрать фильтром, соответствующим вашим конкретным условиям. Таким фильтром может быть:

• «VALUE_OLD» IS NOT NULL
• «VALUE_NEW» = 'да'
• Можно ориентироваться на метку времени (брать только те события, которые произошли после регистрации объекта).
• Можно ориентироваться на поле «USER», если инициализацию выполняет системный аккаунт.
• Любые другие придуманные вами условия.

Генерация Таблицы ЦC

Та же история изменений, которая служила нам источником событий, пригодится и для создания справочника экземпляров процесса (Таблицы ЦС). Алгоритм похожий:

1. Определяем список атрибутов, которые:

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

b. Могут изменяться, но нам интересны только значения в определенных точках: в момент регистрации, закрытия, при взятии в работу, передаче со 2-й линии на 1-ю и т.д.

c. Могут изменяться, но нам интересны только агрегированные значения (максимум, минимум, количество и т.д.)

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

3. Сворачиваем диагональную таблицу в финальный справочник с помощью группировки по идентификатору процесса.

Примеры атрибутов, которые имеет смысл вынести в таблицу ЦС (на практике, этот список может быть гораздо длиннее):

• Услуга
• ИТ-система
• Автор
• Организация автора
• Оценка пользователем качества решения
• Число возвратов в работу
• Когда был взят в работу
• Кем создано
• Кто закрыл
• Решено 1-й линией
• Неверная классификация / маршрутизация
• Крайний срок
• Нарушение крайнего срока

Один и тот же атрибут может являться как источником события в процессе, так и свойством экземпляра процесса. Например, атрибут «Приоритет». С одной стороны, нам интересно его значение в момент регистрации обращения, а с другой – все факты изменения этого атрибута могут быть вынесены в граф процесса в качестве самостоятельных шагов.

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

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

• Само значение атрибута (пример: «Оценка пользователя»)
• Пользователь, его изменивший
• Время изменения
• Время, когда атрибут принял определенное значение (пример: атрибут «Нарушен крайний срок» – интересует не само значение атрибута, а время, когда оно изменяется на эквивалент поднятого флага – например, ‘да’ или 1)
• Факт присутствия атрибута в истории (пример: «Массовый инцидент» со значением 'да')

Этот список, безусловно, можно продолжить и другими идеями использования атрибутов и всего того, что с ними связно.

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

CREATE COLUMN TABLE "SAP_PM"."ITSM_CASES" (

	 "CASE_ID"      NVARCHAR(256)	NOT NULL
	,"CATEGORY"		NVARCHAR(256)	DEFAULT NULL
	,"AUTHOR"		NVARCHAR(256)	DEFAULT NULL
	,"RESOLVER"		NVARCHAR(256)	DEFAULT NULL
	,"RAITING"		INTEGER			DEFAULT NULL
	,"OPEN_TIME"	TIMESTAMP		DEFAULT NULL
	,"START_TIME"	TIMESTAMP		DEFAULT NULL
	,"DEADLINE"		TIMESTAMP		DEFAULT NULL
);

Также нам понадобится временная таблица «ITSM_CASES_STAGING», которая позволит разложить плоский список атрибутов по нужным нам колонкам-свойствам в справочнике экземпляров процесса:

CREATE COLUMN TABLE "SAP_PM"."ITSM_CASES_STAGING" LIKE "SAP_PM"."ITSM_CASES" WITH NO DATA;

Это будет диагональная таблица — в каждой строке только два поля имеют значение: «CASE_ID», т.е. идентификатор процесса, и какое-то одно поле со свойством процесса. Остальные поля в строке будут пустыми (NULL). На заключительном этапе мы легко свернем диагонали в строки простой агрегацией и получим таким образом нужную нам таблицу ЦС.

Пример для категории обращения:

INSERT INTO "SAP_PM"."ITSM_CASES_STAGING" ("CASE_ID", "CATEGORY")
SELECT

	"CASE_ID",
	LAST_VALUE("VALUE_NEW" ORDER BY "TS")
	FROM "SAP_PM"."ITSM_HISTORY"
	WHERE "ATTRIBUTE" = 'Услуга'
	GROUP BY "CASE_ID"
;

Допустим, что автор – это первый в истории обращения несистемный пользователь, который регистрирует обращения (в вашем конкретном случае критерий может быть более точным):

INSERT INTO "SAP_PM"."ITSM_CASES_STAGING" ("CASE_ID", "AUTHOR")
SELECT

	"CASE_ID",
	FIRST_VALUE("USER" ORDER BY "TS")
	FROM "SAP_PM"."ITSM_HISTORY"
	WHERE "USER" != 'SYSTEM'
	GROUP BY "CASE_ID"
;

Если мы считаем, что обработчик, который проставил последний статус “Решение предложено” (а решение могло предлагаться неоднократно, но фиксируется только последнее), успешно решил задачу, то такое свойство экземпляра процесса можно сформулировать следующим образом:

INSERT INTO "SAP_PM"."ITSM_CASES_STAGING" ("CASE_ID", "RESOLVER")
SELECT

	"CASE_ID",
	LAST_VALUE("USER" ORDER BY "TS")
	FROM "SAP_PM"."ITSM_HISTORY"
	WHERE "ATTRIBUTE" = 'Статус' AND "VALUE_NEW" = 'Решение предложено'
	GROUP BY "CASE_ID"
;

Оценка пользователя (его удовлетворенность решением):

INSERT INTO "SAP_PM"."ITSM_CASES_STAGING" ("CASE_ID", "RAITING")
SELECT

	"CASE_ID",
	TO_INTEGER(LAST_VALUE("VALUE_NEW" ORDER BY "TS"))
	FROM "SAP_PM"."ITSM_HISTORY"
	WHERE "ATTRIBUTE" = 'Оценка пользователя' AND "VALUE_NEW" IS NOT NULL
	GROUP BY "CASE_ID"
;

Время регистрации (создания) – это просто самая ранняя запись в истории обращения:

INSERT INTO "SAP_PM"."ITSM_CASES_STAGING" ("CASE_ID", "OPEN_TIME")
SELECT

	"CASE_ID",
	MIN("TS")
	FROM "SAP_PM"."ITSM_HISTORY"
	GROUP BY "CASE_ID"
;

Время реакции – важная характеристика качества услуг. Для его расчета нужно знать, когда впервые был поднят флаг “Был взят в работу”:

INSERT INTO "SAP_PM"."ITSM_CASES_STAGING" ("CASE_ID", "START_TIME")
SELECT

	"CASE_ID",
	MIN("TS")
	FROM "SAP_PM"."ITSM_HISTORY"
	WHERE "ATTRIBUTE" = 'Был взят в работу' AND 'VALUE_NEW' = 'да'
	GROUP BY "CASE_ID"
;

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

INSERT INTO "SAP_PM"."ITSM_CASES_STAGING" ("CASE_ID", "DEADLINE")
SELECT

	"CASE_ID",
	MAX(TO_DATE("VALUE_NEW"))
	FROM "SAP_PM"."ITSM_HISTORY"
	WHERE "ATTRIBUTE" = 'Крайний срок' AND 'VALUE_NEW' IS NOT NULL
	GROUP BY "CASE_ID"
;

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

Когда наша временная диагональная таблица будет заполнена свойствам экземпляров процессов, остается только сделать агрегацию и получить финальную таблицу ЦС:

INSERT INTO "SAP_PM"."ITSM_CASES"
SELECT

	"CASE_ID"
	,MAX("CATEGORY")
	,MAX("AUTHOR")
	,MAX("RESOLVER")
	,MAX("RAITING")
	,MAX("OPEN_TIME")
	,MAX("START_TIME")
	,MAX("DEADLINE")
	FROM "SAP_PM"."ITSM_CASES_STAGING"
	GROUP BY "CASE_ID"
;

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

DELETE FROM "SAP_PM"."ITSM_CASES_STAGING";

Советы по подготовке и очистке CSV-файлов для пилотного проекта

Свое знакомство с дисциплиной Process Mining вы наверняка начнете с пилотного проекта. В таком случае прямого доступа к источнику данных получить не удастся, этому будут сопротивляться и сотрудники ИТ, и сотрудники информационной безопасности. А это означает, что в рамках пилотного проекта придется работать с экспортом данных из корпоративных систем в CSV-файлы и дальнейшим их импортом в SAP HANA для построения модели данных.

В промышленной инсталляции никаких экспортов в CSV не будет. Вместо этого будут использоваться интеграционные инструменты SAP HANA, в частности: Smart Data Integration (SDI), Smart Data Access (SDA) или SAP Landscape Transformation Replication Server (SLT). Но для целей тестирования и ознакомления с технологией экспорт в текстовые CSV-файлы организационно более простой метод. Поэтому будет нелишним поделиться с вами некоторыми советами по подготовке данных в CSV для быстрого и успешного импорта их в базу данных.

Рекомендуемые требования к формату самого файла при экспорте:

1. Формат файла: CSV
2. Кодировка: UTF8
3. Разделитель полей: любой удобный для вас символ. Например, “|” или “^” или “~”. Логика выбора проста – надо постараться избежать ситуации, когда «разделить» содержится в самих данных.
4. Надо убрать разделитель из значения полей. Да, возможно, вы скажете, что для этого, вообще-то, существуют кавычки. Но, как показывает опыт, с кавычками тоже немало проблем возникает. В общем, давайте просто уберем (или заменим) знак разделителя из значения полей. От такой неточности ваш пилотный проект не сильно пострадает, зато время на подготовку данных заметно экономится.
5. Кавычки: надо убрать все кавычки из значения полей. Часто кавычки содержатся в названиях компаний – скажем, ООО «Калинка». Но бывают и вот такие варианты: ООО «МПЗ „Калинка“. И вот это уже большая трудность. Кавычки в значениях полей нужно либо сопроводить символом “”, либо убрать, заменить на что-то еще. Надежнее всего просто убрать. Значение поля от этого не сильно пострадает.
6. Переносы каретки: надо убрать все символы CHAR(10) и CHAR(13) из значения полей. Иначе импорт из CSV будет невозможен.

Если учесть пункты (4) + (5) + (6), то имеет смысл в селекте использовать такую конструкцию:

REPLACE(REPLACE(REPLACE(REPLACE("COLUMN", '|', ';'), '"', ''), CHAR(13), ' '), CHAR(10), ' ') as "COLUMN"

Далее, когда CSV файлы уже готовы, их надо будет скопировать на сервер HANA в папку, которая объявлена как безопасная для импорта файлов (например, /usr/sap/HDB/import). Импорт данных в HANA из локального CSV файла – это довольно быстрая процедура при условии, что файл «чистый»:

• каждая строка будущей таблицы находится в одной и только одной строке файла;
• количество колонок во всех строках одинаковое;
• кавычки либо парные, либо отсутствуют вовсе;
• кавычки в значения полей либо сопровождают «escape»-символом “”, либо отсутствуют вовсе;
• кодировка UTF-8 (а не UTF8-BOM, как это бывает при экспорте на Windows-системах).

Чтобы проверить CSV-файлы перед их импортом и найти проблемные места, если они будут (а с вероятностью 99% они будут), можно использовать следующие команды:

1. Проверить BOM-символ в начале файла:

file data.csv

Если результат команды вот такой: „UTF-8 Unicode (with BOM) text“ то это означает, что используется кодировка UTF8-BOM и надо убрать BOM-символ из файла. Убрать его можно следующим образом:

sed -i '1s/^xEFxBBxBF//' data.csv

2. Число колонок должно быть одинаковым для каждой строки файла:

cat data.csv | awk -F»;" '{print NF}' | sort | uniq

или вот так:

for i in $(ls *.csv); do echo $i; cat $i | awk -F';' '{print NF}' | sort | uniq -c; echo; done;

Поменяйте ‘;’ в параметре F на то, что является разделителем полей в вашем случае.
В результате выполнения этих команд вы получите распределение строк по числу колонок в каждой строке. В идеале вы должны получить нечто подобное:

EKKO.csv
79536 200

Здесь файл содержит 79536 строки, и все они содержат 200 колонок. Строк с другим числом колонок нет. Так и должно быть.

А вот пример неправильного результата:

LFA1.csv
73636 180
7 181

Здесь мы видим, что большинство строк содержит 180 колонок (и, наверное, именно это число колонок – правильное), но есть строки со 181-й колонкой. То есть одно из полей содержит в своем значении знак разделителя. Нам повезло и таких строк всего 7 штук – их можно запросто отсмотреть вручную и как-то подправить. Посмотреть строки, в которых число колонок не равно 180, можно вот так:

cat data.csv | awk -F";" '{if (NF!=180) {print $0}}'

Замечание по использованию приведённых выше команд. Эти команды не будут обращать внимание на кавычки. Если знак разделителя содержится в поле, которое заключено в кавычки (и значит с точки зрения импорта в базу данных здесь всё хорошо), то проверка данным методом покажет ложную проблему (лишние колонки) – это тоже надо учитывать при анализе результатов.

3. Если кавычки непарные и никак не удается решить эту проблему, то можно удалить из файла вообще все кавычки:

sed -i 's/"//g' data.csv

Опасность этого подхода заключается в том, что если значения полей будут содержать знак разделителя, то у вас изменится число колонок в строке. Поэтому знаки разделителя надо убрать из значения полей на этапе экспорта (удалить или заменить на какой-то другой символ).

4. Пустые поля

Сталкивался с ситуацией, когда успешному импорту данных мешали пустые значения полей вот в таком виде:

;""

Где “;” – это знак разделителя полей в данном случае. То есть поле представляет собой две двойных кавычки (обычная пустая строка). Если у вас вдруг не получается импортировать данные, и вы подозреваете, что проблемой могут быть пустые поля, то попробуйте заменить “” на NULL

sed -i 's/;””/;NULL/g' data.csv

(подставьте вместо “;” ваш вариант разделителя)

5. Бывает полезно поискать в данных «грязные» форматы чисел:

;«0 » (число содержит пробел)
;«100.10-» (знак “-“ после числа)
Кран Bugatti 3/4" 300 — размерность дюйм обозначается двойной кавычкой – и это автоматически приводит к проблеме непарных кавычек при экспорте.

К сожалению, это далеко не исчерпывающий список возможных проблем с неудобными форматами данных для импорта в базу данных. Было бы здорово узнать ваши варианты из практики: какие любопытные ошибки вам попадались? Как вы их детектировали и устраняли. Делитесь в комментариях.

Заключение

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

1. Запрос истории изменений у владельца данных
2. Проверка и очистка выгрузки (подготовка CSV-файлов)
3. Импорт в SAP HANA
4. Построение таблицы событий
5. Построение таблицы ЦС (справочника процесса)

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

Фёдор Павлов, эксперт по платформенным решениям SAP CIS

Автор: SAP

Источник