Применение Process Mining для анализа и оптимизации инцидент-менеджмента в ИТ-инфраструктуре банка

Современный банк представляет собой сложнейший технологический холдинг, чья стабильная работа напрямую зависит от бесперебойного функционирования сотен информационных систем [1]. Простои критически важных сервисов, таких как онлайн-банкинг, процессинг платежей или системы расчетов, ведут к немедленным финансовым потерям, ущербу деловой репутации и снижению уровня доверия клиентов. Ключевым механизмом обеспечения операционной устойчивости является процесс инцидент-менеджмента, регламентированный в рамках библиотеки ITIL и реализуемый с помощью ITSM-систем (ServiceNow, Jira Service Management, BMC Helix и др.) [2].

Однако на практике регламентированные бизнес-процессы зачастую расходятся с реальной практикой их исполнения. Модели, построенные методом интервьюирования сотрудников (как в нотации IDEF0), отражают скорее субъективное видение и «идеальную» схему, но не учитывают множественные исключения, неформальные согласования и скрытые «бутылочные горлышки» [3]. Это приводит к тому, что оптимизация проводится на основе неполных или неверных данных, а ее эффект оказывается ниже ожидаемого.

В этом контексте технология Process Mining (добыча процессов) представляет собой прорывной подход к анализу и оптимизации бизнес-процессов [4]. Она позволяет реконструировать реальную картину процесса на основе объективных цифровых следов (event logs), которые системы фиксируют при выполнении каждой операции. Актуальность данного исследования обусловлена растущей потребностью банков в инструментах data-driven управления операционной деятельностью, позволяющих не предполагать, а точно знать, как работают их ключевые процессы [5, с. 5-15].

В качестве объекта исследования рассматривается процесс инцидент-менеджмента в крупном российском банке, аналогичном по масштабам и сложности ИТ-инфраструктуры ПАО «Сбербанк». Процесс формально регламентирован в соответствии с лучшими практиками ITIL и осуществляется через корпоративную ITSM-систему на базе Jira Service Management.

Номинальный (регламентированный) процесс включает следующие ключевые этапы:

• Инцидент регистрируется в системе – либо автоматически системой мониторинга (по порогу срабатывания алерта), либо вручную пользователем через портал самообслуживания. На этом этапе инциденту присваиваются начальные атрибуты: категория, критичность, краткое описание [6].
• Служба Service Desk уточняет детали, определяет конечное влияние и срочность инцидента на основе матрицы приоритетов. В соответствии с категорией и приоритетом заявка назначается на соответствующую целевую группу поддержки (L2/L3).
• Инженер целевой группы проводит анализ первопричин (Root Cause Analysis), выполняет необходимые действия по восстановлению сервиса (например, перезапуск службы, откат конфигурации, установка «заплатки») и фиксирует все предпринятые шаги в заявке.
• После разрешения инцидента инициатор уведомляется и подтверждает восстановление сервиса. Только после этого заявка закрывается, а ее данные сохраняются для последующего анализа.

Несмотря на наличие детального регламента, предварительный качественный анализ и интервью с сотрудниками выявили ряд симптомов, указывающих на потенциальную неэффективность процесса: периодическое, но систематическое превышение времени разрешения (MTTR) для инцидентов высоких приоритетов (P1, P2), большое количество ручных пересогласований и повторных назначений заявок между командами, а также частые жалобы бизнес-пользователей на недостаточную информированность о статусе инцидента. Эти симптомы свидетельствовали о том, что реально существующий процесс (AS-IS) существенно отличается от формально утвержденной схемы [7].

Для проведения объективного, основанного на данных анализа был выбран метод Process Mining (добыча процессов) [8]. Его фундаментальное преимущество перед классическими методами моделирования (например, интервью и workshops) заключается в том, что он реконструирует реальную картину процесса на основе объективных цифровых следов – журналов событий (event logs), которые информационные системы фиксируют при выполнении каждой операции.

Для проведения исследования был экспортирован журнал событий из ITSM-системы за последний квартал, содержащий данные по более чем 15 000 инцидентов. Каждая запись в журнале содержала следующую обязательную информацию: уникальный идентификатор инцидента, наименование выполненного действия, дата и время выполнения действия с точностью до секунды, исполнитель действия. Дополнительно использовались такие атрибуты, как «Приоритет», «Категория» и «SLA», для более глубокого анализа.

В качестве основного инструментария использовался открытый фреймворк ProM и коммерческая платформа Celonis. Применялись три ключевые техники Process Mining [9]:

• Discovery (Обнаружение процесса) автоматическое построение модели процесса непосредственно из журналов событий. Алгоритмы (такие, как Inductive Miner) выявляют последовательности, параллельные ветки, циклы и точки принятия решений, визуализируя реальный поток работ.
• Conformance Checking (Проверка соответствия) сравнение реального процесса, обнаруженного на предыдущем шаге, с эталонной регламентной моделью, описанной в нотации BPMN. Данный метод позволяет количественно оценить уровень отклонений и точно идентифицировать, где и как часто процесс нарушает регламент.
• Performance Mining (Анализ производительности) измерение и визуализация временных метрик процесса. Этот анализ позволяет выявить «бутылочные горлышки» – этапы с наибольшей длительностью, определить среднее время выполнения и проанализировать вариативность времени обработки.

Такой комплексный подход позволил перейти от субъективных гипотез о проблемах процесса к их точному, количественно измеренному подтверждению.

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

Рис. 1. Модель процесса инцидент-менеджмента, полученная методом Discovery (AS-IS) 

Рис. 2. Сравнительный анализ «бутылочных горлышек» и соответствия процесса эталону

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

На основе проведенного анализа была разработана оптимизированная модель TO-BE, носящая практический характер и могущая быть положенной в основу проекта по реинжинирингу и автоматизации процесса. Ключевые предлагаемые улучшения, такие как внедрение интеллектуальной маршрутизации на основе машинного обучения и формализация процедур эскалации, направлены на устранение конкретных «бутылочных горлышек» и позволяют прогнозировать значительное сокращение среднего времени устранения инцидентов (MTTR).

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