Process Mining: почему пилотный проект хорошо проводить на базе ИТ-подразделения
Уследить за бизнес-процессами бывает непросто, особенно если они состоят из множества этапов и вовлекают большое количество людей и систем. Для этого существуют технологии процессной аналитики (Process Mining), которые в теории должны помочь с оптимизацией. Сегодня Дмитрий Емельянов, руководитель управления сервисами ИТ М.Видео-Эльдорадо, расскажет, как его команда внедрила решение этого класса в своем департаменте и смогла заинтересовать другие подразделения успешными результатами.
Идеи Process Mining витают в воздухе достаточно давно. Примерно 3 года назад эту технологию нам демонстрировал один из потенциальных поставщиков, но тогда мы были не готовы применить ее «для анализа любых процессов». Все-таки информации о внедрении подобных решений было мало. Однако сама концепция заинтересовала руководителей, и мы решились на пилот.
Сначала сделать для себя
Мы выбрали задачи своего собственного подразделения. Таким образом, первая инсталляция Celonis и настройка Process Mining были запущены для процессов ITSM.
Этот вариант устраивал всех — оптимизировать бизнес-процессы обработки инцидентов и запросов на обслуживание было полезно для ИТ-дирекции. К тому же нам было намного проще проверять эффективность решения именно на тех задачах, с которыми мы сталкиваемся каждый день.
Мы работаем с Axios Assyst — мастер-системой управления заявками. В ней регистрируются и классифицируются сами заявки. Но возможности формирования отчетов для оценки эффективности процесса ограничены.
Чтобы измерить эффективность процесса и оценить его «здоровье» до внедрения Celonis менеджерам приходилось обращаться сразу к нескольким отчетам. Их создавали при помощи SAP BI, а также Assyst Report Server (специальная система подготовки отчетности, которая формирует графики, получая данные из БД Assyst). Эти решения сложны для управления изменениями — на разработку и корректировку отчета надо формировать запрос и ждать ответа.
Поэтому подготовкой отчетов занимались внешние специалисты, а значит любые изменения все равно требовали отдельного запроса. К тому же отчеты показывали уже свершившийся факт — сколько было инцидентов, какая часть была просрочена. Все это было лишено динамики, детализации. Чтобы узнать, как проблемный инцидент обрабатывался на самом деле, нужно было вручную пересобрать данные по периодам.
В числе прочих проблем старого решения можно отметить невозможность быстрого масштабирования отчетов и применения дополнительных фильтров, чтобы просмотреть только заявки с необходимыми параметрами. Кроме этого участники процесса не могли уточнить эффективность своей работы по каждой заявке. То есть если, например, пострадал SLA, никто не мог точно сказать: «Это из-за меня или нет?».
Майним ITSM-процессы
Для пилотного внедрения Celonis мы воспользовались экспертизой подрядчика, у которого уже был опыт внедрения и создания моделей данных. Наш случай, впрочем, был достаточно простым с точки зрения технической настройки, так как все данные берутся из одной мастер-системы. Мы хотели знать подробности о скорости отработки заявок, причины нарушения SLA, принципы классификации и факты наличия зависших заявок.
Технически все это работает следующим образом. Для любого анализа по методологии Process Mining необходимы две таблицы: таблица цепочек (cases) и таблица событий (event log). Сквозным идентификатором для всех цепочек является номер заявки (case ID). В нашем случае таблица цепочек содержит в себе основные атрибуты заявки — статус, категория, система по которой зарегистрировано обращение, заявитель и тому подобное, а также рассчитываемые по заранее определенным формулам параметры, например, затраченное время согласно SLA или время заявки в режиме ожидания.
В таблицу событий загружается лог действий, которые совершались с заявкой в системе, а из атрибутов заявки создаются искусственные события (например, время создания заявки определяется по времени ее регистрации). У каждого события кроме обязательных трех полей (case_id, timestamp, action_name) есть ряд дополнительных атрибутов полезных для анализа: например, пользователь, который совершил действие, название его группы, оставленный комментарий и так далее. И когда мы начали обрабатывать всю эту информацию в Celonis, стали понятны возможности, которые дает процессная аналитика.
К слову, все описанные выше ограничения и сложности с использованием старых отчетов и систем в полной мере стали очевидны только на этом этапе. То есть, внедрив Process Mining, команда невольно стала задаваться вопросом: «Как мы жили до этого?».
Чтобы отслеживать интересующие нас параметры, мы уже сами создавали дашборды (сейчас их около 10).
Основное преимущества Celonis — возможность выстроить на прямой времени разные этапы отработки заявок. Раскрывая различные участки процесса можно узнать, сколько людей участвовало в обработке этого инцидента, увидеть длительность каждого этапа, отследить статистику.
Таким образом, мы получили инструмент, который позволяет в реальном времени отслеживать соответствие бизнес-процессов утвержденным стандартам и сразу же регистрировать нарушения и изучать факторы, которые приводят к отклонениям.
Мы начали со сбора 50 атрибутов, чтобы проверить функциональность системы, но уже очень скоро стало понятно, что этого недостаточно. Мы приступили к расширению модели данных, и этот процесс происходит до сих пор. Преимущество процессного анализа через Celonis состоит в том, что анализ, мониторинг, сбор и обработка данных замкнуты в непрерывный цикл, обеспечивая развитие и гибкость. И по мере эволюции модель растет, в нее добавляются новые атрибуты, и в эту работу включены все участники: от дата-инженеров до менеджеров процессов.
Безусловный плюс пилота Process Mining именно в области ITSM заключается в том, что мы сами понимаем, какие цифровые следы хотим отслеживать, и для чего. Мы знаем, какие результаты хотим получить и накапливаем необходимую экспертизу для подключения к системе других департаментов.
Как мы используем Celonis сегодня
Итак, c помощью Celonis мы находим «узкие места» и оптимизируем работу с заявками. Регулярная загрузка данных в дашборд позволяет быстро получить статистику и оперативно отслеживать отклонения от стандартов процесса. Дополнительные фильтры, предусмотренные в системе, повышают прозрачность и гибкость отчетов. А это значит, что мы можем получить детальную картину с прорисовкой какого-то инцидента, о котором мы еще несколько минут назад, быть может, даже не знали.
Дашборды построены для самих участников процесса, для управленческой аналитики, а также создаются для проверки гипотез. Последний вид дашбордов — самый динамичный, он помогает проверить предположения об отклонениях в маршрутах заявок.
Например, мы решили проверить, как влияет переоткрытие заявки на ключевые показатели, а также выяснить, почему они происходят — есть ли в этом какая-либо закономерность. Для этого отслеживание переоткрытых заявок добавляется на дашборд, например, с SLA. Наблюдая за процессом, мы можем понять, для каких услуг это характерно и запустить изменение процесса.
Рассмотрим показательный пример. Одна из типовых заявок в нашей компании — настройка рабочего места для нового сотрудника. По такой заявке предоставляется компьютер, отправляется к ИТ-шникам на настройку и так далее. Что может пойти не так?
В системе мы видим, что за последние полгода у нас было 576 подобных заявок. В заявки включено до 11 последовательных задач, которые выполняются разными группами. Среднее время выполнения каждой — 1 час, но на второй задаче это время вырастает до 21 часа. На графе можно увидеть, что в половине случаев возникает дополнительный шаг — звонок пользователю, из-за чего таймер заявки останавливается на несколько дней.
Мы можем провалиться в детали и узнать, какие были процессы, какое оборудование требовалось, какой информации не хватало для решения заявки. В нашем случае оказалось, что в 184 случаях у заказчика спрашивали что-то дополнительно. На это уходило значительное время. А значит нам стоит зайти вглубь процесса, узнать, какой информации не хватало и добавить в форму заявки новое поле.
Вот другой пример. Для процесса требуется до трех согласований. Согласование D1 занимает 16 часов, а остальные проходят моментально. Становится очевидно, что узкое место процесса — первое согласование. Жизненный цикл заявки сократится именно за счет оптимизации этого шага. Улучшать производительность сервера, увеличивать количество ответственного персонала — бесполезно.
Теперь давайте обратим внимание на отслеживание ключевого показателя — соблюдения SLA. Прямо на дашборде мы можем выбрать только те заявки, где был нарушен SLA. Гибкость и масштабирование отчетов позволяют в короткие сроки провести глубокий анализ и понять основные причины, которые ведут к нарушению SLA.
При этом вкладки с дашбордами можно персонализировать для разных задач и заказчиков. Например, можно настроить регулярный экспорт в PDF и отправку ответственным лицам. Вот так выглядит дашборд для руководителя группы техподдержки.
Перспективы расширения
Как мы уже говорили, в рамках пилота данные забираются из одной системы. Получив первые результаты для ITSM (время обработки заявок по критичным системам снизилось в отдельных случаях на 90%, а показатель «соответствие SLA» вырос с 90 до 97%), мы убедились, что система поможет улучшить и другие бизнес-процессы.
Мы работаем над расширением применения Celonis, в том числе на процессы оформления заказа и установки техники, поэтому скоро цифровые следы будут поступать из 7 разных систем. Например, в рамках анализа исполнения заказа один процесс будет затрагивать доставку, расчетные документы, жалобы, запросы клиента и тп. Впрочем, как только сделаем, обязательно расскажем.
