Данных обычно нет.
В 7 из 10 первых проектов внедрения Process Mining в компании, которая инвестировала в создание КХД, дата-платформы или иного хранилища данных профильное подразделение ИТ активно подключается к проекту. Звучит утверждение - данные уже есть или могут быть легко получены. Уже в середине проекта выясняется грустный факт - всех данных нет и догрузить их сложно, а обработать не успевают.
Начнем с преобразования данных. Брать данные напрямую из источников нельзя - они сильно нагружены. Дополнительные запросы информации создают проблемы с производительностью для конечных пользователей. Это верно и для западных решений от Oracle и SAP и для отечественных на базе 1С. Данные необходимо преобразовать журнала событий и это с первого раза никогда не получится. Это означает потребность в хранении исходной информации за значительный период времени в формате удобном для обработки.
Чтобы КХД или дата-платформа подошли как инструмент для работы с данными надо проверить что:
➤ Есть ресурсы для хранения исходной информации. Для process mining нужно хранить данные на горизонте до 16 месяцев. Иначе не получится нормально собрать, например, сквозной процесс закупки от заявки до поставки инициатору
➤ Есть функции для инкрементальной загрузки данных без увеличения нагрузки на системы-источники
➤ Есть встроенные средства проверки качества данных - так как мы детально исследуем "судьбу" каждой заявки, то ошибки из-за неверной информации не будут скрыты агрегацией в высокоуровневые метрики
➤ Есть механизмы позволяющие работать с ситуацией, когда формат исходных данных сменился внутри анализируемого периода
Если такого функционала в существующих КХД и озерах данных нет, то единственная рабочая схема это создать специализированный контур для работы с данными process mining.
Утверждение о том, что информация уже присутствует в КХД следует проверять:
➤ Чаще всего не хранится полная история изменения статусов
➤ Не хранится информация о редактировании атрибутов объекта анализа
➤ Горизонт хранения не агрегированной информации сильно ограничен, 1-2 месяца вместо нужных 16 и более месяцев
Могут быть проблемы с привлечением ресурсов DWH/BI подразделений:
➤ Сотрудники ожидают получения спецификации от системного аналитика. Они оперируют полями таблиц, а не бизнес-терминами - трудозатраты на разработку ТЗ для них могут оказаться больше, чем включение инженера данных в команду проекта и работа по схеме Agile
➤ Модель данных, удобная для использования в process mining, не похожа на модели для BI, адаптированные к агрегации информации. У архитектора данных может не быть нужных навыков
Самым практичным будет выполнение первого проекта внешней специализированной командой с последующей передачей результата работ в профильное подразделение для дальнейшего сопровождения и развития.
#dreamteam@hammered_screw #useful@hammered_screw
