Обнаружение и устранение проблем с качеством данных
Данные для процесс-майнинга (от англ. process mining - интеллектуальный анализ процессов) могут поступать из разных мест. Одним из больших преимуществ процесс-майнинга является то, что он не привязан к какой-либо системе. Любой рабочий процесс или учетная система, ERP, хранилища данных, потоки кликов, устаревшие системы и даже данные, которые были собраны вручную в Excel, можно проанализировать до тех пор, пока ID Кейса, имя Активности и столбец метки времени могут быть определены.
Но большую часть этих данных изначально не собирали для процесс-майнинга. И особенно данные, введенные вручную, которые часто содержат ошибки. Как убедиться, что ошибки в данных не поставят под угрозу результаты анализа?
Качество данных является важной темой для любого метода их анализа: если вы основываете результаты анализа на данных, вы должны убедиться, что данные достоверны и правильны. В противном случае ваши результаты будут неверными! Если вы покажете результаты анализа бизнес-пользователю, и они окажутся неверными из-за каких-то проблем с данными, вы можете навсегда потерять их доверие к процесс-майнингу.
Тем не менее, есть некоторые трудности, связанные с качеством данных, характерные для процесс-майнинга [Suriadi] [Bose]. Многие из этих трудностей вращаются вокруг проблем с временными метками. На самом деле можно сказать, что временные метки — это ахиллесова пята качества данных в процесс-майнинге. Но временные метки — не единственная проблема.
В этой статье мы покажем вам проблемы с качеством данных, с которыми вы чаще всего сталкиваетесь на практике, и способы их решения.
Ошибки форматирования
Первая проверка заключается в том, чтобы обратить внимание на любые ошибки, возникающие на этапе импорта. Во многих ситуациях ошибки возникают из-за неправильного формата CSV-файлов, потому что писать хорошие CSV-файлы сложнее, чем вы думаете [TBurette].
Например, символ-разделитель («», «;» «I» и т. д.) нельзя использовать в содержимом поля без надлежащего экранирования. Если вы посмотрите на приведенный ниже фрагмент кода, то увидите, что разделитель «,» использовался для разделения столбцов. Однако в самой последней строке название активности содержит запятую:
Case ID, Activity case1, Register claim case1, Check case1, File report, notify customer
Правильный CSV требует, чтобы Активность «File report, notify customer» было заключено в кавычки, чтобы указать, что «,» является частью имени Активности:
Case ID, Activity case1, Register claim case1, Check case1, "File report, notify customer"
Другая проблема может заключаться в том, что в вашем файле в некоторых строках может быть меньше столбцов, чем в других (см. пример на рис. 1).
Рис. 1. Уведомления об отсутствующих ячейках появляются тогда, когда в некоторых строках меньше столбцов, чем в других.
Другими типичными проблемами являются недопустимые символы, кавычки, которые открываются, но не закрываются, и многое другое.
Если Disco сталкивается с проблемой форматирования, она выдает следующее сообщение об ошибке с грустным треугольником, а также пытается указать, в какой строке возникает проблема (см. рис. 2).
Рис.2: Disco пытается сообщить вам, в какой строке обнаружена ошибка форматирования.
В большинстве Кейсов Disco все равно импортирует ваши данные, и вы можете сначала взглянуть на них, но нужно обязательно вернутся и изучить проблему, прежде чем продолжить какой-либо серьезный анализ.
Мы рекомендуем открыть файл в текстовом редакторе и просмотреть указанный номер строки (чуть до и после тоже), чтобы увидеть, можете ли вы определить основную причину.
Примечание
Как исправить:
Иногда проблемы с форматированием не влияют на ваши данные (например, лишняя запятая в конце некоторых строк в вашем файле), или количество поврежденных строк настолько мало, что вы предпочитаете игнорировать этот факт. Но в большинстве Кейсов вам нужно исправить проблему.
Иногда достаточно использовать «Найти и заменить» в Excel, чтобы заменить символ-разделитель из содержимого ваших ячеек и экспортировать новый, очищенный CSV, который вы затем импортируете.
Однако в большинстве Кейсов проще всего будет указать на проблему, которую вы обнаружили, человеку, который извлек для вас данные, и попросить его предоставить вам новый файл, который позволяет избежать проблемы.
Отсутствующие события
Даже если ваши данные импортированы без каких-либо ошибок, могут возникнуть проблемы с данными. Например, одной из типичных проблем является отсутствие данных. Один тип отсутствующих данных, с которым вы можете столкнуться, — это отсутствующие события.
Вы можете идентифицировать пропущенные события двумя способами.
Пробелы на временной шкале
Проверьте временную шкалу на диаграмме «События с течением времени», чтобы убедиться в отсутствии необычных разрывов в количестве событий, происходящих за временной период вашего журнала.
Рис. 3. Пробелы на временной шкале обычно указывают на то, что что-то не так.
На рис. 3 показан пример, в котором мы объединили три отдельных файла в один перед его импортом в Disco. Явно что-то пошло не так и видимо все данные из второго файла отсутствуют.
Примечание
Как исправить:
Если вы допустили ошибку на этапе предварительной обработки данных, вы можете вернуться и убедиться, что вы включили туда все данные.
Если вы получили данные от кого-то другого, вам нужно вернуться к этому человеку и попросить его исправить ошибку.
Если у вас нет возможности получить новые данные, лучше всего сосредоточиться на непрерывной части набора данных (в приведенном выше примере это будет только первая или только третья часть данных). Вы можете сделать это, используя Timeframe фильтр в Disco.
Неожиданный объем данных
Вы должны иметь представление (приблизительно), сколько строк или Кейсов вы импортируете. Взгляните на обзорную статистику, чтобы увидеть, совпадают ли они с тем, чего вы ожидаете.
Например, на рисунке 4 показан скриншот экрана с обзорной статистикой из набора данных BPI Challenge 2013 [BPI13]. Можете ли вы увидеть, что не так с ним?
Рис. 4. Проверьте, соответствует ли количество событий и Кейсов вашим ожиданиям в отношении набора данных.
На самом деле общее количество событий подозрительно близко к старому пределу Excel (65 000 строк). И вот что произошло: на одном из шагов подготовки данных данные (которые имели несколько сотен тысяч строк) были открыты в старой версии Excel, а затем их снова сохранили.
Конечно, это немного более тонко, чем очевидный разрыв на временной шкале, но отсутствие данных может быть вызвано самыми разными причинами. Для некоторых систем или баз данных извлечение больших данных прерывается на полпути, и никто этого не замечает. Вот почему очень полезно иметь представление о том, сколько данных вы ожидаете, прежде чем начать импорт (спросите человека, который предоставляет вам данные, как он структурировал свой запрос).
Примечание
Как исправить:
Если вы пропустили данные, то должны выяснить, потеряли ли вы их на этапе предварительной обработки данных или на этапе извлечения.
Если вы получили данные от кого-то другого, вам нужно вернуться к этому человеку и попросить его исправить это.
Если у вас нет возможности получить новые данные, постарайтесь получить хорошее представление о том, какую часть данных вы получили. Это случайность? Были ли данные отсортированы, и вы получили первые X строк? Как это влияет на ваши возможности анализа? Некоторые участники конкурса BPI Challenge [BPI13W] заметили что-то странное, и проанализировали шаблон данных, чтобы лучше понять, чего не хватает.
Отсутствующие значения атрибутов
Точно так же вы должны получить представление о том, какие атрибуты вы ожидаете от своих данных. Вы запрашивали данные по всем запросам на обслуживание в колл-центрах Нидерландов, Германии и Франции за месяц, но объемы показывают, что данные, которые вы получили, в основном из Нидерландов.
А вот еще один пример, на который следует обратить внимание, — пустые значения в ваших атрибутах. Например, статистика атрибутов ресурсов на рис. 5 показывает, что 23% шагов вообще не связаны с ресурсами.
Рис.5: Проверьте, достаточно ли заполнены значения ваших атрибутов данных.
Пустые значения – это тоже нормально. Поговорите со специалистом в области процессов и с кем-нибудь, кто разбирается в информационной системе, чтобы понять значение отсутствующих значений в вашей ситуации.
Примечание
Как исправить:
Если у вас есть неожиданные распределения, это может указывать на то, что вам не хватает данных, и вам следует вернуться к этапам предварительной обработки и извлечения, чтобы выяснить, почему именно.
Если у вас есть пустые значения атрибутов, часто эти значения действительно отсутствуют и никогда не записывались. Убедитесь, что вы понимаете, как эти отсутствующие (или неожиданно распределенные) значения атрибутов влияют на ваши возможности анализа. Вы можете прийти к выводу, что не можете использовать конкретный атрибут для анализа из-за этих проблем с качеством.
Нередко обнаруживаются проблемы с качеством данных в источнике данных во время процесс-майнига, потому что никто, возможно, не рассматривал эти данные так, как это делаете вы. Показывая потенциальные преимущества анализа данных, вы создаете стимул для улучшения качества данных (и, следовательно, расширения возможностей анализа) с течением времени.
Отсутствующие ID Кейсов
Для дальнейшей проверки вам следует обратить внимание на Кейс с очень большим количеством шагов. Например, на рис. 6 данные колл-центра из демо-журналов Disco были импортированы с ID клиента, выставленным в качестве ID Кейса.
Вы обнаружите, что в общей сложности 3231 клиентских Кейсов содержат до 30 шагов, и есть один Кейс (Клиент 3), в котором было 583 шага за два месяца. Это ведь не может быть правильно, не так ли?
Рис. 6: Проверьте, есть ли Кейс с невозможным количеством шагов.
Для дальнейшего изучения этого вопроса вы можете щелкнуть правой кнопкой мыши по ID Кейса в таблице и выбрать параметр «Показать сведения о Кейсе» (см. рис. 7).
Рис. 7. Щелкните правой кнопкой мыши Кейс, которое вы считаете подозрительным, чтобы продолжить свое расследование.
Откроется «Просмотр Кейсов» с показанным конкретным Кейсом (см. рис. 8). Оказывается, через короткие промежутки времени поступало много коротких входящих звонков.
Консультация эксперта в предметной области подтверждает, что это не реальный клиент, а некий стандартный или «фиктивный» ID клиента, который назначается агентом колл-центра, если клиент не создан или связан с Кейсом. Фактически система Siebel CRM требовала, чтобы агент всегда вводил ID клиента. Таким образом, в ситуациях, когда это было невозможно (например, потому что клиент повесил трубку до того, как агент смог получить его контактную информацию), агенты вводили фиктивный ID клиента.
Рис. 8. Затем вы можете посмотреть пример Кейса, чтобы понять, является ли это реальным Кейсом или просто проблемой качества отсутствующего ID Кейса.
Хотя в этом наборе данных есть технически связанный ID Кейса (до анонимизации ID клиентов номер даже имел точно такой же буквенно-цифровой формат и был неотличим от всех обычных ID клиентов), этот фиктивный ID Кейса на самом деле является примером отсутствующих данных. Настоящие Кейсы (фактические клиенты, которые звонили) не фиксируются.
А это влияет на ваш анализ. Например, анализ среднего количества шагов на клиента с этим фиктивным клиентом даст неправильный результат. Вы столкнетесь с аналогичными проблемами, если поле ID Кейса будет пустым для некоторых ваших событий (все они будут сгруппированы в один Кейс с «пустым» ID).
Примечание
Как исправить:
Вы можете просто удалить Кейсы с таким большим количеством шагов в Disco (см. рисунок 9). Убедитесь, что вы отслеживаете, сколько событий вы удаляете из данных и насколько репрезентативным остается ваш оставшийся набор данных после этого.
Чтобы удалить Кейс «Клиент 3» из данных колл-центра выше, вы можете щелкнуть правой кнопкой мыши Кейс в обзорной статистике и выбрать параметр «Фильтровать для Кейса «Клиент 3».
Рис. 9: Щелкните правой кнопкой мыши Кейс, который вы хотите удалить.
В предварительно настроенном Фильтре атрибутов вы можете инвертировать выбор (см. маленькую кнопку Инь-Ян в правом верхнем углу), чтобы исключить Клиента 3. Чтобы создать новую контрольную точку для ваших очищенных данных, вы можете отметить «Применить фильтры». навсегда» после нажатия кнопки «Копировать и фильтровать», как показано на рисунке 10.
Рис. 10. Отмените выбор ID Кейса, который вы хотите удалить из набора данных.
Результатом будет новый журнал с удаленным очень длинным Кейсом и постоянно применяемым фильтром (см. рис. 11).
11. Теперь вы очистили свой набор данных от Кейсов, в котором были сгруппированы отсутствующие ID Кейсов.
Отсутствующие Активности
Некоторые Активности в вашем процессе могут не отражаться в данных. Например, у вас могут быть ручные Активности (например, телефонный звонок), которые люди выполняют за своим рабочим столом. Эти Активности происходят в процессе, но не отображены в данных.
Конечно, карта процессов, которую вы обнаружите с помощью процесс-майнинга, не покажет вам эти Активности, выполняемые вручную. Вы увидите путь от Активности, которое произошло до ручной Активности, к Активности, которое произошло после ручной Активности.
Например, на карте процесса на Рисунке 12 показан путь от Активности «Создание запроса на коммерческое предложение» к «Анализу запроса на коммерческое предложение», который в среднем занимает 21,7 дня. Однако может случиться так, что между этими двумя этапами процесса имело место другая Активность, которую не видно в данных.
Рис. 12. При интерпретации карты процесса необходимо учитывать Активности, выполняемые вручную.
Примечание
Как исправить:
Здесь мало что можно сделать. Важно знать, что эти Активности имеют место, хотя вы не можете видеть их в данных. Процесс-майнинг не может быть выполнен без надлежащего знания предметной области, который вы анализируете. Обязательно поговорите с людьми, задействованными в этом процессе, чтобы понять, что происходит.
Затем вы можете принять это знание предметной области во внимание при интерпретации результатов. Например, в приведенном выше процессе вы бы знали, что не все 21,7 дня это временя простоя в процессе. Вы можете узнать, что между ними происходят и другие Активности, но вы не видите их в своих данных. Это как слепое пятно в вашем процессе. Как правило, при правильной интерпретации у вас все в порядке, и вы можете завершить свой анализ на основе имеющихся у вас данных.
Однако иногда слепое пятно становится проблемой. Например, вы можете обнаружить, что ваши крупнейшие узкие места находятся в этой слепой зоне, и вам действительно нужно лучше понимать, что там происходит. В этой ситуации вы можете вернуться назад и собрать некоторые данные об этой части процесса вручную, либо путем наблюдения, либо попросив сотрудников документировать свою ручные Активностив течение нескольких недель. Обязательно запишите ID Кейса вместе с Активностями и отметками времени в этом процессе. Впоследствии вы можете объединить данные, собранные вручную, с ИТ-данными, чтобы проанализировать весь процесс, но теперь с полной видимостью слепых зон.
Отсутствующие временные метки
В некоторых ситуациях у вас может быть информация о том, произошло ли какая-либо Активность, но у вас просто нет метки времени.
Например, взгляните на фрагмент данных из процесса обработки счета на рисунке 13. Мы видим, что в некоторых Кейсах выполнена Активность «Урегулировать спор с поставщиком». В отличие от всех других Активностей, это Активностьне имеет связанной временной метки. Возможно, оно просто не было зафиксировано системой, либо информация об этой активности поступает из другой системы.
Рис. 13: Активность «Урегулировать спор с поставщиком» не имеет метки времени.
Проблема с набором данных, в котором некоторые события имеют отметку времени, а другие нет, заключается в том, что инструмент процесс-майнинга не может вывести последовательность Активностей, потому что обычно события упорядочиваются на основе отметок времени во время импорта данных. Так что же можно сделать?
По сути есть три варианта.
Примечание
Как исправить:
- Игнорировать события без метки времени. Это позволит вам проанализировать производительность вашего процесса, но пропустить все Активности, которые не связаны с отметкой времени (см. пример ниже).
- Импортировать свои данные без настройки отметки времени. Это позволит импортировать все события в соответствии с порядком Активностейиз исходного файла. Вы увидите все Активностина карте процесса, но не сможете проанализировать время ожидания в процессе (см. пример ниже).
- Вы можете «позаимствовать» временные метки соседней активности и повторно использовать их для событий, у которых нет временных меток (например, временная метка их последующей Активности). Этот этап предварительной обработки данных позволит вам импортировать все события и включить все Активностив карту процесса, сохранив при этом возможность анализа производительности вашего процесса.
Если вы хотите использовать свои данные без дальнейшей предварительной обработки, вот как выглядят варианты №1 и №2 на примере выше.
Игнорировать события, у которых нет метки времени
Во-первых, мы можем импортировать набор данных обычным способом. Когда выбран столбец меток времени, Disco выдает предупреждение о том, что шаблон меток времени не соответствует всем строкам в данных (см. рис. 14). Причиной этого несоответствия являются пустые поля временных меток Активности «Урегулировать спор с поставщиком».
Рис. 14: Disco предупреждает вас о том, что некоторые значения не могут распознаваться как метки времени.
Когда вы будете импортировать данные невзирая на этот факт, Disco будет импортировать только те события, которые имеют отметку времени (и сортировать их на основе отметок времени, чтобы определить последовательность событий для каждого Кейса). Вы увидите сообщение об ошибке, как показано на рис. 15, которое информирует вас о том, что не все события могут быть импортированы, поскольку их временные метки не могут быть распознаны.
Рис. 15: Сообщение об ошибке информирует вас, что некоторые события не могут быть импортированы, так как их отметка времени не может быть распознана.
После импорта данных вы получаете карту процесса без Активности «Урегулировать спор с поставщиком» (см. рис. 16). Теперь вы можете полностью проанализировать свой процесс также с точки зрения производительности, потому что вы включили информацию о метке времени во время импорта, но у вас есть слепое пятно (аналогично сценарию в качестве примера, обсуждаемому в отсутствующие Активности).
Рис. 16. Активности, не имеющие метки времени, не будут отображаться на карте процесса, но вы можете проанализировать свой процесс с точки зрения производительности.
Импортировать данные без настройки метки времени
Теперь предположим, что мы хотим включить Активность «Урегулировать спор с поставщиком» в нашу карту процесса. Например, мы хотели бы визуализировать, сколько Кейсе в имеет спор в первую очередь.
Для этого мы снова импортируем данные, но убедитесь, что ни один столбец не настроен как столбец «Timestamp» на экране импорта. Например, мы можем изменить конфигурацию столбца «Полная метка времени» на атрибут (см. рис. 17) или полностью исключить его.
В правом нижнем углу вы увидите предупреждение о том, что столбец меток времени не определен, но вы все равно можете импортировать данные. Disco теперь будет использовать порядок событий в исходном файле, чтобы определить последовательность Активностей для каждого Кейса. Вы должны использовать этот подход только в том случае, если Активности уже правильно отсортированы в вашем наборе данных.
Рис. 17: Несмотря на то, что Disco показывает вам предупреждение о том, что столбец Timestamp не был настроен, вы можете импортировать свои данные без отметки времени, и последовательность событий в исходном файле будет использоваться для сортировки Активностей в каждом Кейсе.
В результате Активность «Урегулировать спор с поставщиком» теперь отображается на карте процесса (см. рис. 18). Мы видим, что 80 из 412 Кейсов прошли через диспут в процессе.
Рис. 18. Теперь на карте процесса отображается Активность без временных меток.
Мы можем дополнительно проанализировать карту процесса вместе с вариантами, количеством шагов в процессе и т. д. Однако, поскольку мы не импортировали никаких временных меток, мы не сможем проанализировать производительность процесса, например, продолжительность Кейса или время ожидания в карте процесса.
Для анализа производительности процесса и одновременного сохранения Активностей без временных меток в карте процесса вам придется добавить временные метки для событий, которые в настоящее время не имеют меток времени в процессе вашей подготовки данных (см. вариант № 3 выше в раздел «Как исправить»).
История отсутствующих атрибутов
Даже если все значения ваших атрибутов заполнены (см. Отсутствующие значения атрибутов, если это не так), вам может не хватать информации по истории для этих атрибутов. Например, взгляните на набор данных на рис. 19, где столбец «Ресурс» не меняется на протяжении всего Кейса.
Рис. 19. Если значения определенного атрибута никогда не меняются в течение всего Кейса, возможно, в ваших данных отсутствует история этого атрибута.
Вместо лица, выполнившего тот или иной шаг процесса, здесь в поле «Ресурс» скорее всего указан сотрудник, инициировавший кейс, ответственный за него, или лицо, которое последним выполнило шаг в процессе.
То же самое может произойти с полем данных типа «Категория», как показано на рис. 19. Возможно, вы знаете, что поле может меняться со временем, но в вашем наборе данных вы видите только последнее (текущее) его значение.
Примечание
Как исправить:
Если вы не можете получить историческую информацию об этом поле, запросите словарь данных у ИТ-администратора, чтобы понять значение поля и правильно интерпретировать его. Например, является ли ресурс, связанный с Кейсом, лицом, изначально создавшим заказ? Или это последний человек, работавший над этим Кейсом?
Имейте в виду, что вы не можете выполнять анализ потока процессов с помощью этого атрибута (например, анализ социальных сетей будет невозможен на основе поля ресурса в приведенном выше примере). Вы по-прежнему можете использовать эти поля в своем анализе в качестве атрибута уровня Кейса.
Иногда обнаружить отсутствующую информацию об истории атрибутов бывает еще сложнее. Например, взгляните на набор данных на рисунке 20.
Мы видим, что оформление шага «Отправка через экспедиторскую компанию» в Кейсе С360 выполнялось «Сервисным клерком» — см. (1) на рис. 20. Однако для Кейса С1254 тот же шаг выполнял «Менеджер по обслуживанию». должность, которая, если бы мы знали больше о процессе, могла бы показаться нам странной — см. (2) на рисунке 20.
Рис. 20: Похоже, что Эльвира выполнила шаг «Отправка через транспортную компанию» для Кейса C1254 в роли «Сервис-менеджера». На самом деле она была «сервисным клерком» еще в 2011 году, но атрибут роли, который был получен для обогащения набора данных истории заказов, содержит только информацию о ее текущей роли.
Если мы углубимся в проблему, то обнаружим, что информация о «ролях» на самом деле была получена из отдельной базы данных и позже ее связали с нашими данными истории заказов. Однако информация «Роли», которую мы использовали для обогащения набора исторических данных, основана на текущих ролях сотрудников.
В 2011 году, когда Кейс C1254 рассматривался, Эльвира Лорес все еще была «сервисным клерком». Но к 2013 году, когда был выполнен Кейс С360, Эльвира стала «Сервис-менеджером» — см. (3) на рис. 20. Но мы не видим, чтобы Эльвира выполняла шаг «Отправка через экспедиторскую компанию» тогда в роли «Служебного клерка», потому что у нас есть только информация о ее текущей роли!
Примечание
Как исправить:
Как правило, вы мало что можете сделать с этим в краткосрочной перспективе. Вы можете попробовать запросить новый набор данных, содержащий историческую информацию о роли, но, возможно, эти данные недоступны в вашей организации.
Это нормально, что вы сталкиваетесь с ограничениями в своем наборе данных, и на первом этапе вы обычно пытаетесь использовать именно имеющиеся у вас данные. Самая важная часть заключается в том, что вы знаете об ограничениях данных, и сможете правильно интерпретировать результаты своего анализа.
Отсутствуют временные метки для повторяющихся Активностей
Это распространенная проблема с качеством данных, с которой, как мы уверены, большинство из вас столкнется в какой-то момент в будущем.
Взгляните на фрагмент данных на рис. 21. В этом наборе данных вы видите три Кейса (Кейс ID 1, Кейс ID 2 и Кейс ID 3). Если вы сравните этот набор данных с типичным набором данных процесс-майнинга, вы увидите следующие отличия:
- В каждом Кейсе есть только одна строка (см. выделенный Кейс 1). Обычно у вас будет несколько строк — одна строка для каждого события в Кейсе.
- Активности представлены в столбцах (здесь Activity A, B, C, D и E) с датами или отметками времени, записанными в содержимом ячейки.
Рис.21: Если набор данных отформатирован в одну строку для каждого Кейса, вы должны понимать, что вам, вероятно, не хватает информации о повторениях Активностей.
Когда вы столкнетесь с таким набором данных, вам придется переформатировать его в формат процесс-майнинга следующим образом (см. рис. 22):
- Добавьте строки для каждой Активности (опять же, Кейс 1 выделен).
- Создайте столбцы Активностей и меток времени, чтобы зафиксировать имя и время для каждой Активности.
Рис. 22. Вам нужно будет переформатировать этот набор данных, чтобы преобразовать столбцы в строки, но это не единственная проблема.
Однако здесь важно понимать, что это не просто проблема форматирования. Формат на основе столбцов не подходит для сбора данных о событиях вашего процесса, поскольку он по своей сути теряет информацию о повторениях Активностей.
Например, представьте, что после выполнения шага процесса D сотрудник понимает, что не хватает какой-то информации. Ему нужно вернуться к шагу C, чтобы зафиксировать недостающую информацию, и только затем переходить к шагу E. Проблема с форматом на основе столбцов, как показано в первом фрагменте данных, заключается в том, что нет места, где эти две отметки Активности C можно получить. Итак, в большинстве случаев происходит следующее: первая временная метка Активности C просто перезаписывается, и сохраняется только самая последняя временная метка Активности C.
Вы можете задаться вопросом, почему люди вообще хранят данные процесса в таком формате, основанном на столбцах. Как правило, вы найдете такие данные в местах, где были агрегированы данные процесса. Например, в хранилище данных, системе BI или отчете Excel. Это заманчиво, потому что в этом формате легко измерить KPI процесса. Например, вы хотите знать, сколько времени проходит между этапами процесса B и E? Просто добавьте формулу в Excel для расчета разницы между двумя метками времени.
Люди часто неявно предполагают, что процесс проходит через Активности А-Е упорядоченным образом. Но процессы действительно сложны и беспорядочны на самом деле. Пока процесс не полностью автоматизирован, будут некоторые доработки. И, добавляя свои данные в таком столбцовом формате, вы теряете информацию о реальном процессе.
Итак, что вы можете сделать, если столкнетесь со своими данными в таком формате на основе столбцов?
Примечание
Как исправить:
Прежде всего, вы должны использовать имеющиеся у вас данные и преобразовать их в формат на основе строк, как показано выше. Однако при анализе нужно помнить об ограниченности данных и знать, что из-за этого можно столкнуться с некоторыми искажениями в процессе (см. пример ниже).
Если процесс достаточно важен, вы можете вернуться на следующей итерации и выяснить, откуда берутся исходные данные, которые были агрегированы в инструменте BI или в отчете Excel. Например, из базовой системы рабочего процесса. Затем вы можете получить полные данные истории из исходной системы, чтобы полностью проанализировать процесс со всеми его повторениями.
Чтобы понять, с какими искажениями вы можете столкнуться, давайте взглянем на набор данных на рис. 23, на котором показаны шаги, которые на самом деле происходили в реальном процессе до того, как данные были объединены в столбцы. Вы увидите следующее:
- Только кейс 2 следовал ожидаемому пути A-E.
- В кейсе 1 и в кейсе 3 произошла доработка, которая просто была потеряна в наборе данных на основе столбцов, а затем в преобразованном наборе данных (см. синюю разметку).
Рис.23: Более серьезная проблема заключается в том, что вы, скорее всего, потеряли информацию о любых повторениях (или циклах), которые могли произойти для Активностей в процессе.
Теперь, когда вы впервые импортируете набор данных, преобразованный из формата на основе столбцов в формат на основе строк, в Disco, вы получаете упрощенную карту процессов (см. Упрощение сложных карт процессов, чтобы узнать больше о том, как упростить сложные процессы). показано на рисунке 24.
Рис.24: Это приводит к искажению карты процесса. Вот карта процесса из транспонированного набора данных. Создается впечатление, что по крайней мере один раз за Активностью B непосредственно следовала Активность D…
Проблема заключается в том, что если эксперт в предметной области взглянет на эту карту процессов, он сможет увидеть некоторые странные и, возможно, даже невозможные потоки процессов, соответствующие искажениям из-за потерянных временных меток повторения Активностей. Например, на карте процесса выше видно, что прямой путь от Активности B к Активности D был хотя бы раз.
Однако на самом деле этого никогда не происходило. Вы можете увидеть обнаруженную карту процесса из реального набора данных (где фиксируются все повторения Активностей) на рисунке 25. Никогда не было прямой последовательности шагов процесса B и D, потому что в действительности Активность C происходило между ними.
Рис.25: … хотя на самом деле этого никогда не было.
Итак, используйте данные, которые у вас есть, но помните, что такие искажения могут произойти и что их вызывает. Если вы выполните еще одну итерацию для анализа этого процесса, попытайтесь получить базовые данные, включающие историю повторений Активностей, чтобы получить полную картину.
Нулевые метки времени (например, 1900, 1970 и 2999)
Еще одна проблема с данными, с которой вы наверняка столкнетесь в какой-то момент, — это так называемые «нулевые временные метки». Нулевые временные метки — это временные метки по умолчанию, назначенные ИТ-системой по ошибке или по другой причине. Часто нулевые метки времени изначально устанавливались как пустое значение программистом информационной системы. Это может быть также опечатка при введении данных вручную, либо они могут указывать на то, что реальная метка времени еще не была предоставлена (например, потому что ожидаемый шаг процесса еще не произошел).
Эти нулевые временные метки обычно принимают форму 1 января 1900 года, временной метки эпохи Unix 1 января 1970 года или какой-либо будущей временной метки (например, 2100 или 2999). Если вы не позаботитесь о нулевых временных метках, вы можете легко получить продолжительность Кейса в более чем 100 лет!
Чтобы узнать, есть ли в ваших данных нулевые временные метки, лучше всего перейти к обзорной статистике и просмотреть самые ранние и самые поздние временные метки в наборе данных. Например, на снимке экрана на рисунке 26 мы видим, что в импортированных данных есть как минимум одна временная метка 1900.
Рис.26. Проверьте самую раннюю и самую последнюю метку времени в обзорной статистике, чтобы увидеть, нет ли у вас нулевых меток времени.
Ошибочные временные метки влияют не только на продолжительность Кейса. Они также влияют на варианты и сами карты процессов, поскольку порядок Активностей определяется на основе меток времени.
Например, взгляните на следующий набор данных только с одной нулевой меткой времени. Есть один кейс с временной меткой 1970 года (см. рис. 27). В результате Активность «Создать Кейс» располагается перед Активностью «Импорт форм».
Рис. 27. Неверные временные метки влияют на последовательность Кейсов и варианты.
Если мы посмотрим на карту процесса (см. рис. 28), то увидим, что во всех остальных 456 Кейсах процесс протекает в другую сторону. Ясно, что обратная последовательность вызвана отметкой времени 1970.
Рис.28: Этот неправильный порядок будет отображаться в потоках карты процессов…
И если мы посмотрим на среднее время ожидания в карте процесса, то эта одна ошибочная временная метка создает дополнительные проблемы и показывает огромную задержку в 43 года (см. рис. 29).
Рис.29: … и в метриках производительности на карте процессов.
Чтобы защитить себя от нулевых временных меток, вы должны знать, какие временные рамки вы ожидаете для своего набора данных, а затем убедиться, что самая ранняя и самая поздняя временные метки подтверждают ожидаемый период времени. Имейте в виду, что если вы не решите проблему, подобную отметке времени 1900 на рис. 26, то вы можете получить продолжительность Кейса более 100 лет!
Примечание
Как исправить:
Вы можете удалить нулевые временные метки, используя фильтр Timeframe в Disco (см. инструкции ниже).
Вы также можете сообщить о своих выводах системному администратору, чтобы узнать, как можно избежать этих нулевых временных меток в будущем.
Чтобы понять влияние временных нулевых отметок, сначала нужно более подробно изучить, что происходит.
Первое: исследование
Вы хотите выяснить, нулевые временные метки – это всего несколько Кейсов или это широко распространенная проблема. Например, если для всех Активностей, которые еще не произошли, в системе записаны нулевые временные метки, вы увидите их во всех открытых Кейсах.
Чтобы исследовать Кейсы с нулевыми метками времени, добавьте фильтр временных рамок и используйте режим «Пересечение временных рамок», сосредоточившись на проблемном периоде времени. Это сохранит все те Кейсы, которые содержат хотя бы одну нулевую временную метку. Затем используйте кнопку «Копировать и фильтровать», чтобы создать новый набор данных, ориентированный на Кейс с нулевой меткой времени (см. рис. 30).
Рис. 30. Во-первых, выясните, на сколько Кейсов влияют нулевые временные метки (и почему).
В результате вы увидите только Кейсы, в которых нет временных меток. Вы можете видеть, сколько их. Кроме того, вы можете просмотреть несколько Кейсов, чтобы увидеть, всегда ли проблема находится в одном и том же месте или затрагиваются несколько Активностей. В нашем примере только два Кейса с нулевыми метками времени (см. рис. 31).
Рис. 31. В этом наборе данных затронуты только два Кейса.
Теперь давайте перейдем к устранению проблемы с нулевой меткой времени в наборе данных.
Затем: удалите Кейсы или только нулевые временные метки.
В зависимости от того, являются ли нулевые временные метки широко распространенной проблемой, вы можете предпринять два разных действия:
- Если есть только несколько Кейсов, лучше всего полностью удалить их. Таким образом, они не будут мешать вашему анализу. В то же время вы не останетесь с неполными Кейсами, которые пропускают некоторые Активности из-за проблем с качеством данных.
- Если есть много Кейсов, например, в ситуации, когда нулевые временные метки записаны для Активностей, которые еще не произошли, вам лучше удалить только те события, которые имеют нулевые временные метки, и сохранить остальные события из этих Кейсов для вашего анализа.
В нашем примере затронуты только два Кейса, и мы полностью удалим их. Для этого добавьте фильтра метки времени и выберите параметр «Содержится в таймфрейме», сосредоточив свой выбор на ожидаемом таймфрейме. Это удалит все Кейсы, в которых есть какие-либо события вне выбранного периода времени (см. рис. 32).
Рис. 32. Чтобы удалить все затронутые Кейсы, используйте параметр «Содержится во временном интервале» фильтра метки времени.
Если вы просто хотите удалить Активности с нулевыми временными метками, вместо этого выберите параметр «Обрезать по временным рамкам». Это «отрежет» все события за пределами выбранного интервала и сохранит остальные Кейсы в ваших данных (см. рис. 33).
Рис. 33. Чтобы удалить только затронутые события, используйте параметр «Обрезать по таймфрейму» в фильтра метки времени.
Обратите внимание: если нулевые метки времени указывают на то, что определенные Активности еще не выполнялись, было бы лучше оставить ячейки меток времени в исходных данных пустыми, а не заполнять значения меток времени значениями «1900» или «1970» (см. рис. 34).
Рис. 34. Если ваши нулевые метки времени указывают на то, что Активность еще не произошла, было бы лучше оставить ячейку для этих Активностей пустой в будущем.
События с пустыми отметками времени не будут импортированы в Disco, поскольку их нельзя разместить в последовательности Активностей по Кейсу (см. рис. 15). Таким образом, если вы имеете какое-то влияние на то, как создается набор данных, то оставляя пустую ячейку временной метки для Активностей, которые еще не произошли, вы избавите себя от этого дополнительного шага очистки в будущем.
Неправильная конфигурация шаблона метки времени
Когда вы импортируете файл CSV или Excel в Disco, шаблон метки времени обычно определяется автоматически. Вам не нужно ничего делать. Если он не определяется автоматически, Disco позволяет вам указать, как следует интерпретировать шаблон временной метки, а не заставлять вас преобразовывать исходные данные в фиксированный формат временной метки. И вы даже можете работать с различными шаблонами временных меток в наборе данных (см. Различные шаблоны временных меток).
Но, если вы обнаружили, что Активности отображаются в неправильном порядке, или если вы обнаружите, что ваша карта процессов выглядит странно и на самом деле не показывает ожидаемый процесс, то стоит проверить правильность настройки временных меток во время импорта.
Вы можете сделать это, вернувшись к экрану импорта: либо нажав кнопку «Обновить» в представлении проекта, либо снова импортировав свои данные. Затем выберите столбец метки времени и нажмите кнопку «Шаблон…» в правом верхнем углу (см. рис. 35). Вы увидите несколько оригинальных меток времени, как они есть в вашем файле (слева), и предварительный просмотр того, как Disco их интерпретирует (зеленый, справа).
Рис. 35. Чтобы убедиться, что шаблон метки времени распознан правильно, снова импортируйте данные и проверьте диалоговое окно шаблона метки времени на основе нескольких образцов меток времени.
Проверьте, правильно ли интерпретируются метки времени в зеленом столбце. Обратите внимание на строчные и прописные буквы в шаблоне, потому что это имеет значение. Например, строчная буква «м» обозначает минуты, а заглавная «М» — месяцы.
Примечание
Как исправить:
Если вы обнаружите, что в предварительном просмотре временные метки отображаются неправильно, настройте правильный шаблон для столбца временных меток на экране импорта. Вы можете очистить поле «Шаблон» и начать вводить тот шаблон, который соответствует временным меткам в вашем наборе данных (используйте легенду справа, а более сложные шаблоны см. в справочнике по шаблону даты Java, там описаны точные обозначения и дополнительные примеры). Зеленый предварительный просмотр будет обновляться во время ввода, чтобы вы могли проверить, правильно ли теперь интерпретируются временные метки. Затем нажмите кнопку «Использовать шаблон».
Неправильная конфигурация столбца метки времени
Другая проблема с метками времени, которая может возникнуть из-за ошибок на этапе импорта, заключается в том, что вы могли случайно настроить некоторые столбцы в качестве меток времени, которые на самом деле не являются столбцами меток времени в смысле меток времени процесс-майнинга (но, например, указывают день рождения клиента).
В примере возврата средств службы поддержки клиентов на рис. 36 дата покупки в данных имеет форму временной метки. Однако эта дата не меняется со временем, и на самом деле ее следует рассматривать как атрибут. Вы можете видеть, что как столбец «Полная метка времени», так и столбец «Дата покупки» имеют символ часов в заголовке, который указывает, что в настоящее время оба настроены как метка времени.
Рис.36. Убедитесь, что ни один столбец, который должн быть просто обычным атрибутом процесса, не настроен как метка времени процесс-майнинга.
Если столбцы неправильно настроены как метка времени, Disco будет использовать их для расчета продолжительности Активности. Как следствие, Активности могут идти параллельно, хотя на самом деле они не происходят одновременно.
Примечание
Как исправить:
Убедитесь, что только нужные столбцы настроены как отметка времени: для каждого столбца текущая конфигурация отображается в заголовке. Просмотрите все свои столбцы и убедитесь, что только в ваших фактических столбцах временной метки отображается маленький символ часов, который указывает конфигурацию временной метки. Затем снова нажмите кнопку «Начать импорт».
Например, в наборе данных обслуживания клиентов мы просто изменили бы конфигурацию столбца «Дата покупки» на обычный атрибут, как показано на рис. 37.
Рис. 37. Если вы обнаружите столбец, который является, но не должен быть столбцом меток времени, вы можете настроить его как атрибут «Другое» во время импорта.
Как правило, ни один столбец не должен быть настроен как столбец метки времени в смысле процесс-майнинга, если он не меняется в ходе кейса (см. также Историю меток времени).
Активности с той же отметкой времени
Другая причина, по которой временные метки могут вызывать проблемы, заключается в том, что они недостаточно отличаются друг от друга. Например, если у вас есть только дата (и нет времени), то легко может случиться так, что две Активности в одном и том же кейсе происходят в один и тот же день. В результате вы не знаете, в каком порядке они произошли на самом деле!
Взгляните на простой пример набора данных на рис. 38. Мы видим простой процесс подписания документа с четырьмя Активностями и тремя кейсами. Кейс 2 показывает ожидаемую последовательность для этого процесса: сначала «Создано», затем «Отправлено клиенту», затем «Получен ответ» и, наконец, «Документ подписан». Но порядок строк в наборе данных неверен. Например, шаги «Отправлено клиенту» и «Создано» расположены в неправильном порядке для Кейса 1, а шаги «Отправлено клиенту» и «Создано», а также «Документ подписан» и «Документ получен» расположены в неправильном порядке для Кейса 3.
Рис.38: Простой процесс подписания документа из четырех шагов.
Обычно это не проблема, поскольку, при импорте данных в инструмент процесс-майнинга, последовательность событий определяется автоматически на основе меток времени. Например, неправильная последовательность шагов «Создано» и «Отправлено клиенту» для Кейса 1 исправляется автоматически, поскольку даты показывают, что эти два шага произошли в противоположном порядке (см. рис. 39).
Рис.39: Если ваши временные метки отличаются, неупорядоченные события в вашем наборе данных не являются проблемой.
Однако если две Активности происходят одновременно (в этом примере в один и тот же день), то Disco не знает, в каком порядке они произошли на самом деле. Таким образом, он сохраняет порядок, в котором они появляются в исходном файле. Поскольку порядок Активностей в файле примера является случайным, это создает некоторые дополнительные различия в карте процесса (и в вариантах), которых там быть не должно.
Например, три Кейса в примере на рисунке 38 из чисто последовательного процесса. Однако, поскольку неправильно упорядоченные шаги в Кейсе 3 происходят в один и тот же день, вы можете увидеть некоторые дополнительные чередования на карте процесса. Они отражают различный порядок Активностей с одними и теми же отметками времени в файле (см. рис. 40).
Рис.40. Проблема с Активностями с одинаковыми отметками времени заключается в том, что они создают шум на карте процесса, который не отражает реальный процесс, а возникает из-за этой проблемы с качеством данных. Таким образом, вы не можете отличить фактические отклонения процесса от проблем с чистыми данными.
Таким образом, если у вас недостаточно точных временных меток, чтобы определить порядок всех Активностей, или если у вас есть много шагов в процессе, происходящих точно в одно и то же время, это часто создает больше сложности, чем уже есть. Что вы можете сделать, чтобы отличить реальную сложность процесса от той, которая вызвана той же самой проблемой временных меток?
Примечание
Как исправить:
Вы можете либо исключить события с одинаковыми метками времени, выбрав «репрезентативное» событие (см. стратегию 1 ниже), либо попробовать предварительно отсортировать данные (см. стратегии 2–4 ниже), чтобы уменьшить вариацию, вызванную Активностями с одинаковыми метками времени.
Стратегия 1: «Представитель» (исключение событий)
Причина Активности «Одной и той же временной метки» не всегда заключается в недостаточном уровне детализации шаблона временной метки. Иногда это просто тот факт, что многие события регистрируются одновременно.
Представьте, например, систему документооборота в муниципалитете, где сотрудник службы вводит новый адрес гражданина, переехавшего в новую квартиру. После того, как поля улицы, номера дома, почтового индекса, города и т. д. на экране заполнены, они нажимают «Далее», чтобы завершить изменение регистрации и распечатать квитанцию.
В журнале истории системы документооборота вы, скорее всего, увидите отдельные записи изменений каждого из этих полей (например, запись «Старое значение» и «Новое значение» атрибута «Улица»). Однако все они могут иметь одинаковую отметку времени, то есть время, когда сотрудник нажал кнопку «Далее» и все изменения полей данных были завершены (одновременно).
На рис. 41 вы можете увидеть еще один пример высокоавтоматизированного процесса. Много шагов происходят одновременно.
Рис. 41. Если в автоматизированном процессе одновременно происходит много Активностей, хорошей стратегией может быть выбор репрезентативного события, обозначающего все Активности, которые «зарегистрированы одновременно».
Однако вам могут и не понадобиться все эти подробные события, вы можете выбрать одно из них для представления всей подпоследовательности. Например, в процессе, показанном на рис. 41, первое из четырех выделенных событий может обозначать последовательность этих четырех. Вы можете отменить выбор других шагов с помощью параметра «Оставить выбранным» в фильтре атрибутов.
В целом, сосредотачивание внимания только на нескольких — наиболее важных — промежуточных Активностях — это один из самых эффективных методов сократить набор данных до более значимых вариантов, если их слишком много — см. также Стратегию 9: Сосредоточение внимания на промежуточных Активностях.
Стратегия 2: сортировка по порядковому номеру
Иногда у вас есть информация о том, в какой последовательности происходили Активности, в каком-то атрибуте порядкового номера. Это здорово, потому что теперь вы можете сортировать набор данных на основе порядкового номера (см. рис. 42) и полностью избежать проблемы с Активностями с одинаковыми отметками времени.
Рис. 42. Если вы знаете правильный порядок событий в наборе данных, просто используйте этот порядковый номер для сортировки строк перед импортом файла в Disco.
Поскольку для событий с одинаковой меткой времени Disco использует последовательность Активностей в исходном файле, этот шаг предварительной сортировки повлияет на порядок, в котором формируются варианты и потоки процессов, и, следовательно, зафиксирует случайный порядок Активностей с одинаковыми отметками времени.
Стратегия 3: сортировка по имени Активности
Конечно, у вас не всегда есть порядковый номер, на который можно положиться при сортировке данных. Так что же еще вы можете сделать?
Есть быстрый способ, который часто помогает. Он заключается в том, что вы можете предварительно отсортировать данные просто на основе имени Активности. Идея состоит в том, что, по крайней мере, Активности, имеющие одну и ту же временную метку (и иногда в таком, а иногда в другом порядке), теперь всегда находятся в одном и том же порядке, даже если сам порядок не имеет особого смысла.
Это легко сделать: просто отсортируйте данные на основе столбца активности перед их импортом. Однако иногда эта стратегия также может иметь неприятные последствия, потому что вы можете — случайно — ввести неправильные заказы в тех же Активности с отметками времени, которые по совпадению раньше были в порядке.
Например, рассмотрим результат сортировки данных по имени Активности для процесса подписания документа на рис. 43:
Рис.43. Сортировка набора данных на основе названий Активностей может помочь уменьшить шум, но также может привести к появлению новых неверных последовательностей.
Это помогло уменьшить вариацию в начале процесса, но в то же время ввело обратный порядок Активностей «Документ подписан» и «Получен ответ» для Кейса 1 (которые имеют те же метки времени, но в исходном файле были по совпадению в правильном порядке).
Стратегия 4: сортировка на основе идеальной последовательности
Чтобы «правильным» образом повлиять на порядок Активностей с одинаковыми метками времени, лучше всего проанализировать те последовательности процессов в ваших данных, которые формируются фактическими различиями в метках времени. Вы также можете поговорить с экспертом в предметной области, чтобы он помог вам понять, какой будет идеальная последовательность процесса.
Например, если вы посмотрите на Кейс 2 в процессе подписания документа, то увидите, что последовательность полностью определяется разными временными метками (см. рис. 44).
Рис. 44. Просмотрите часто встречающиеся варианты и найдите Кейсы, отражающие реальный процесс, поискав Кейсы, в которых все временные метки отличаются.
Теперь мы собираемся использовать эту идеальную последовательность, чтобы повлиять на сортировку исходных данных. Один из простых способов сделать это в Excel — поставить перед именами Активностей порядковый номер, отражающий их место в идеальной последовательности (например, «1 — создано», «2 — отправлено клиенту», «3 — получен ответ» и «4 — Документ подписан») с помощью функции «Найти и заменить», как показано на рис. 45.
Рис.45. Затем отсортируйте свои Активности на основе этой идеальной последовательности.
После добавления порядковых номеров можно просто отсортировать исходные данные по столбцу активности (см. рис. 45).
Рис. 46. После импорта отсортированного набора данных вы увидите только истинные отклонения от ожидаемого процесса (если они действительно отражены временными метками в данных) на карте процесса.
Это приведет ваши Активности в идеальную последовательность. Теперь, когда вы импортируете данные в Disco, вы увидите отклонения от идеальной последовательности только в том случае, если временные метки действительно отражают это.
Различная степень детализации временных меток
В главе «Активности с одинаковыми временными метками» мы видели, как временные метки, не имеющие достаточной детализации, могут вызывать проблемы. Например, если несколько Активностей выполняются в один и тот же день для одного и того же Кейса, их нельзя привести в правильном порядке, потому что мы не знаем, в каком порядке они выполнялись. Другая проблема, связанная с временными метками, с которой вы можете столкнуться, заключается в том, что ваш набор данных имеет временные метки с разной степенью детализации.
Давайте взглянем на пример на рисунке 47. Фрагмент файла показывает набор данных с шестью различными Активностями. Однако только Активность «Заказ получен» содержит время (часы и минуты). Все остальные Активности просто имеют дату.
Рис.47. Иногда в вашем наборе данных имеется сочетание высокой детализации временных меток (например, с точностью до миллисекунды) и низкой детализации временных меток (например, только даты).
Обратите внимание, что в этом конкретном примере нет проблем с принципиально разными шаблонами меток времени. Однако типичной причиной разной степени детализации меток времени является то, что эти метки времени поступают из разных ИТ-систем. Следовательно, они также часто будут иметь разные шаблоны временных меток. Вы можете обратиться к статье Как работать с наборами данных, которые имеют разные форматы меток времени, чтобы решить эту проблему.
В этой главе мы сосредоточимся на проблемах, которые могут возникнуть из-за разной степени детализации меток времени. Итак, почему это может быть проблемой? В конце концов, хорошо, что у нас есть более подробная информация хотя бы об одном этапе процесса, правда? Давайте посмотрим.
Когда мы импортируем примерный набор данных в Disco, шаблон метки времени автоматически сопоставляется, и мы можем без проблем подобрать подробное время 20:07 для «Заказ получен» в первом Кейсе (см. рис. 48).
Рис.48: Disco пытается сопоставить ваши метки времени с максимально возможной точностью.
Проблема становится очевидной только после импорта данных. На карте процесса мы видим странные и неожиданные потоки (см. рис. 49). Например, как может быть так, что в большинстве Кейсов (1587 раз) шаг «Подтверждение заказа» происходил раньше, чем «Заказ получен»?
Рис. 49. Из-за разной степени детализации меток времени на карте процессов появляются неожиданные потоки процессов.
Кажется что это невозможно. Итак, мы нажимаем на путь и используем ярлык «Фильтровать этот путь…» (см. «Фильтрация путей из карты процесса»), чтобы оставить в процессе только те Кейсы, которые действительно следовали этому конкретному пути, как показано на рисунке 50.
Рис.50: Мы исследуем этот неожиданный путь, чтобы выяснить, что происходит.
Затем мы переходим в «Посмотр Кейсов», чтобы изучить несколько Кейсов (см. рис. 51). Там мы можем сразу увидеть, что произошло: обе Активности «Заказ получен» и «Заказ подтвержден» произошли в один и тот же день. Однако «Заказ получен» имеет отметку времени, которая включает время, а «Заказ подтвержден» включает только дату.
Для Активностей, которые включают только дату (например, «Заказ подтвержден»), время автоматически отображается как «полночь». Конечно, это не означает, что Активностьдействительно произошла в полночь. Мы просто не знаем, когда в течение дня оно произошло.
Рис.51: Все Кейсы с неправильным заказом, по-видимому, имеют получение и подтверждение заказа в один и тот же день.
Таким образом, очевидно, что «Заказ подтвержден» должен был иметь место в тот же день после «Заказ получен» (то есть после 13:10 в выделенном Кейсе). Однако, поскольку мы не знаем время подтверждения заказа (проблема с качеством данных с нашей стороны), обе Активности отображаются в неправильном порядке.
Примечание
Как исправить:
Если вы знаете правильную последовательность Активностей, имеет смысл убедиться, что они отсортированы правильно (Disco будет соблюдать порядок в файле для одновременных Активностей), а затем сначала проанализировать поток процесса на самом крупном уровне. Это поможет меньше отвлекаться от неправильных порядков и получить первое представление о потоках процессов на этом уровне.
Вы можете сделать это, исключив часы, минуты и секунды из конфигурации отметки времени во время импорта в Disco (см. пример ниже).
Позже, когда вы перейдете к подробному анализу частей процесса, вы можете поднять уровень детализации до более мелких временных меток, чтобы увидеть, сколько времени было потрачено между этими различными этапами.
Чтобы убедиться, что Активности «Подтвержденный заказ» не регистрируются несколькими днями ранее (что может указывать на другие проблемы), мы отфильтровываем все другие Активности в процессе и смотрим на Максимальную продолжительность между «Подтвержденный заказ» и «Полученный заказ» в карте процесса (см. рис. 52). Максимальная продолжительность 23,3 часа подтверждает нашу оценку того, что этот неправильный порядок Активностей появляется из-за разной детализации временных меток «Заказ получен» и «Заказ подтвержден».
Рис.52. Чтобы подтвердить, что неправильная последовательность возникает только для Активностей, которые происходят в один и тот же день, мы смотрим на максимальную продолжительность на карте процесса.
Итак, что мы можем с этим поделать? В этом конкретном примере дополнительное время, которое мы получаем для Активности «Заказ получен», не очень помогает и вызывает больше путаницы, чем пользы. Чтобы выровнять детализацию меток времени, мы решили опустить информацию о времени, даже если она у нас есть.
Уменьшить детализацию всех временных меток до даты просто: вы можете просто вернуться к экрану импорта данных, выбрать столбец «Временная метка», нажать кнопку «Шаблон…», чтобы открыть диалоговое окно шаблона временной метки, а затем удалить компоненты часов и минут, просто удалив их из шаблона меток времени (см. рис. 53). Как вы можете видеть в правой части предварительного просмотра, отметка времени со временем 20:07 теперь воспринимается только как дата (16 декабря 2015 г.).
Рис. 53. Чтобы уменьшить детализацию всех временных меток, просто сопоставьте только самый крупный компонент временной метки в диалоговом окне шаблона временной метки.
Когда набор данных импортируется с этой новой конфигурацией шаблона временных меток, выбираются только даты, а порядок событий в файле используется для определения порядка Активностей с одинаковой датой в одном и том же Кейсе (см. главу Активности с той же отметкой времени, чтобы узнать, что делать, если порядок Активностей неправильный).
В результате нежелательные потоки процессов исчезли, и теперь мы видим, что Активность «Заказ получен» последовательно отображается перед Активностью «Заказ подтвержден» (см. рис. 54).
Рис. 54. После уменьшения детализации меток времени все потоки процессов отображаются в правильном порядке.
Уменьшение степени детализации временной метки до самой грубой единицы времени (как описано в приведенном выше примере) обычно является лучшим способом справиться с разной степенью детализации временных меток, если у вас есть всего несколько шагов в процессе, которые являются более подробными, чем другие.
Однако, если ваш набор данных содержит в основном Активности с подробными временными метками, а есть лишь несколько более грубых (по оценке времени) Активностей (например, некоторые важные промежуточные действия могли быть получены из другого источника данных и имеют только дату), тогда может быть лучшим вариантом искусственно предоставить «фальшивое время» для этих грубых Активностей с отметками времени, чтобы они отображались в правильном порядке.
Например, вы можете установить их на 23:59, если хотите, чтобы они были последними среди шагов процесса в тот же день. Или вы можете указать время, отражающее типичное или ожидаемое время, когда эта Активность обычно происходит.
Будьте осторожны, когда вы делаете это, тщательно проверяйте результирующий набор данных на наличие проблем, которые вы могли создать из-за такого изменения. Кроме того, важно помнить, что вы создали это «фальшивое» время при интерпретации продолжительности между Активностями в своем анализе.
Записанные временные метки не отражают фактическое время Активности
Голландская страховая компания провела анализ своих процессов. Для некоторых процессов все шло хорошо, и они могли извлечь из этого ценную информацию. Однако для большей части своих наиболее важных основных процессов они поняли, что система рабочих процессов не использовалась так, как предполагалось.
Случилось так, что сотрудники взяли документы с описанием претензий к себе на просмотр, обработали их и сложили в стопку с другими претензиями. В конце недели они зашли в ИТ-систему и регистрировали информацию — по сути, задокументировав работу, которую проделали ранее.
У такого способа работы есть две проблемы:
- Это показывает, что система не поддерживает делопроизводителя в том, что он должен делать. В противном случае они хотели бы использовать систему, которая направляет. Но документация в системе является дополнительной, утомительной задачей, которая максимально затягивает работу.
- Конечно, это также означает, что временные метки, записанные в системе, не отражают фактическое время, когда Активности действительно происходили. Таким образом, проводить анализ процесс-майнига на основе этих данных почти бесполезно.
В настоящее время компания работает над улучшением системы, чтобы поддерживать своих сотрудников и, в конечном итоге, снова получить возможность перезапустить свою инициативу по добыче полезных данных.
Вы можете столкнуться с такими проблемами в разных областях. Например, врач может целый день ходить, разговаривать с пациентами, выписывать рецепты и т. д. А потом к концу дня она садится за свой компьютер и записывает выполненные задачи для административной системы. Еще одним примером является то, что временные метки определенного шага процесса задаются вручную, и люди допускают опечатки при их вводе.
Итак, что вы можете сделать, если обнаружите, что ваши данные имеют проблему, заключающуюся в том, что записанное время не отражает фактическое время Активности?
Примечание
Как исправить:
Прежде всего, вам нужно осознать, что у ваших данных есть эта проблема. Вот почему шаг проверки данных так важен (не забудьте также прочитать главу о сеансе проверки данных).
Как только вы сможете оценить серьезность разрыва между записанными временными метками в ваших данных и фактическими временными метками записанных Активностей, вам необходимо решить, является ли (а) проблема локализованной или предсказуемой, или (б) всеобъемлющей и слишком большой, чтобы анализировать данные каким-либо полезным способом.
Если проблема затрагивает только определенную Активность или часть вашего процесса (локализованную), вы можете отказаться от конкретных Активностей , поскольку они недостаточно надежны. После этого вы все еще можете проанализировать остальную часть процесса.
Если смещение не такое большое и предсказуемое (например, врач записывает свои Активности в конце дня), вы можете выполнить анализ в более крупном масштабе. Например, вы будете знать, что нет смысла анализировать Активности врача в больнице на уровне часов или минут (даже если технически записанные метки времени содержат минуты). Но вы все равно можете анализировать процесс на уровне дня.
Наконец, если проблема слишком большая и вы не знаете, когда произошла какая-либо Активность (как в примере со страховой компанией), вам, возможно, придется решить, что данные недостаточно хороши, чтобы использовать их для анализа вашего процесса на данный момент.
Разные часы
В предыдущих главах вы уже видели, как неверные временные метки могут испортить анализ процессов: потоки процессов, варианты и измерения времени, такие как длительность Кейса и время ожидания на карте процесса.
Одна изсамых сложных причин, вызывающих ошибки временных меток заключается в том, что временные метки в вашем наборе данных могли быть записаны несколькими компьютерами, работающими с разными часами. Например, в охранной компании [Vanherle] операторы регистрировали свои действия, когда они прибывали на место, определяли проблему и т. д. на своих портативных устройствах. Время на этих мобильных устройствах иногда отличалось от времени сервера, и друг от друга.
Если вы посмотрите на сценарий на рис. 55, то поймете, почему это проблема: допустим, на пульт поступило сообщение о новом инциденте в 13:30. Через пять минут мобильный оператор отвечает на запрос и сообщает, что выедет на место для устранения проблемы. Однако, поскольку часы на их мобильном устройстве отстают на 10 минут, записанная метка времени показывает 13:25.
А когда вы объедините все временные метки в своем наборе данных для выполнения процесс-майнига, вы увидите, что ответ оператора появляется перед первоначальным сигналом об инциденте. Это не только создает неправильные потоки в вашей карте процессов и вариантах, но когда вы пытаетесь измерить время между возникновением инцидента и первым ответом, это на самом деле даст вам отрицательное время.
Рис.55: Если смешать события, записанные в разных местах с разными часами, можно получить странные эффекты в последовательности процессов и неточную картину процесса.
Итак, что вы можете сделать, когда у вас есть данные с такой проблемой?
Во-первых, исследуйте проблему, чтобы увидеть, постоянен ли дрейф часов во времени и какие Активности затронуты им. Тогда у вас есть следующие варианты.
Примечание
Как исправить:
- Если общее исправление невозможно, вы можете попытаться очистить свои данные, удалив Кейсы, которые отображаются в неправильном порядке. Обратите внимание, что фильтр подписчиков в Disco также позволяет удалять Кейсы, когда между двумя Активностями прошло больше или меньше указанного количества времени. Таким образом, вы можете отделить незначительные отклонения часов (обычно разница составляет всего несколько секунд) от Кейсов, когда две Активности действительно были записаны со значительной разницей во времени. Убедитесь, что оставшийся набор данных по-прежнему репрезентативен после такой очистки данных.
- Если ничего не помогает, вам, возможно, придется вернуться к вашей системе сбора данных и настроить механизм синхронизации часов, чтобы постоянно измерять разницу во времени между сетевыми устройствами и получать правильные метки времени при записи данных по пути.
Сеанс проверки данных
Обычный неудачный сценарий процесс-майнига выглядит следующим образом: вы представляете проблему процесса, которую обнаружили в ходе анализа процесс-майнига, группе менеджеров. Они смотрят на карту вашего процесса и указывают, что это не может быть правдой. Вы копаетесь в данных и обнаруживаете, что на самом деле причиной была проблема с качеством данных.
Проблема с этим сценарием заключается в том, что даже если вы затем устраните проблему с качеством данных, доверие, которое вы потеряли со стороны бизнеса, часто невозможно будет вернуть. Они не будут доверять вашим будущим результатам, потому что «все данные неверны». А жаль, ведь могли бы быть большие возможности в анализе и улучшении этого процесса!
Чтобы избежать этого, мы рекомендуем запланировать специальный сеанс проверки данных с экспертом по процессу или предметной области, прежде чем вы начнете фактическую фазу анализа в своем проекте. Чтобы управлять ожиданиями, сообщите, что целью сеанса является не анализ процесса, а обеспечение хорошего качества данных, прежде чем вы приступите к самому анализу.
Вы можете попросить принять участие в сеансе как эксперта в предметной области, так и эксперта по данным, но здесь особенно необходим вклад эксперта в предметной области, потому что вы хотите выявить проблемы в данных с точки зрения владельца процесса, для которого вы выполняете анализ (вы можете назначить отдельную встречу с экспертом по данным, чтобы позже ответить и на ваши вопросы по данным). В идеале ваш эксперт в предметной области имеет доступ к операционной системе во время сеанса, чтобы вы могли вместе просматривать отдельные Кейсы, если это необходимо.
Чтобы организовать сеанс проверки данных с экспертом предметной области, вы можете сделать следующее:
- Начните с краткого объяснения того, что такое процесс-майниг. Покажите максимум 5 слайдов и подумайте о том, чтобы представить короткую демонстрацию с простым и понятным примером. Если только они недавно не участвовали в презентации по анализу процессов, вы должны предположить, что они либо вообще не знают, что такое анализ процессов, либо имеют лишь смутное представление о нем.
- Затем еще раз сформулируйте цель сеанса и объясните, что вы хотите проверить данные с ними и собрать потенциальные проблемы и вопросы по пути.
- Подумайте о том, чтобы попросить их нарисовать простую карту процесса (просто прямоугольники и стрелки) с их точки зрения с максимум 7 шагами на доске. Это будет полезно в качестве отправной точки, когда вы попытаетесь понять значение определенных шагов процесса позже на встрече.
- Покажите им данные в необработанном виде (например, в Excel) и объясните, откуда вы взяли данные и как они были получены. Укажите столбцы ID Кейса, Активность и Временная метка, которые вы используете.
- Затем импортируйте данные у них на глазах и просмотрите сводную информацию (с указанием временных рамок данных, атрибутов и т. д.). После этого посмотрите на карту процессов и просмотрите с ними лучшие варианты. Посмотрите на несколько Кейсов и спросите их: «Имеет ли это для вас смысл?». Запишите любые вопросы, которые они задают.
- Если вы обнаружите странные закономерности в поведении процесса, отфильтруйте данные, чтобы перейти к некоторым Кейсам для дальнейшего контекста. При необходимости упростите карту процессов (см. раздел «Упрощение сложных карт процессов») и совместно изучите проблемы, которые вы обнаружите, в интерактивном режиме. Постарайтесь найти ответы на вопросы прямо во время сеанса, если это возможно, а в противном случае запишите их в качестве задачи на будущее.
- Если можете, вместе найдите несколько кейсов в операционной системе (многие системы позволяют выполнять поиск по ID кейса или ID клиента, а также просматривать историю отдельного кейса) и сравните их с последовательностями кейсов, которые вы найдете в Disco, чтобы увидеть, совпадают ли они.
- Возможно, вы уже и сами сталкивались с вопросами, просматривая контрольный список качества данных [DQC] перед этим сеансом проверки данных. Вы можете просмотреть их вместе с экспертом в предметной области, чтобы узнать, есть ли у них какие-либо объяснения наблюдаемых вами проблем.
Вы можете обнаружить, что эксперт в предметной области поднимает вопросы о процессе, которые имеют отношение к самому анализу. Это здорово, и вы должны записать их, но не отвлекайтесь на анализ и верните сеанс обратно к своим вопросам о качестве данных, чтобы убедиться, что вы достигли цели этой встречи: проверить качество данных и выявить любые проблемы с данными, которые, возможно, необходимо очистить.
После сеанса проверки отслеживайте все обнаруженные проблемы с данными и исследуйте их. Кроме того, отслеживайте, на какие из ваших первоначальных вопросов о процессе могут повлиять обнаруженные вами проблемы с качеством данных. Задокументируйте действия, которые вы предприняли или собираетесь предпринять, чтобы их исправить.