Привет, Хабр! Я, Мадаров Артур, руководитель дирекции процессов эксплуатации и ИТ-услуг Страхового Дома ВСК.
В своей прошлой статье, «Реинжиниринг процессов контроля качества технической поддержки», я рассказывал, с чего началась наша трансформация: как мы перешли от разрозненной отчётности в Excel к системной BI-аналитике, как формировали культуру data-driven внутри ИТ-блока ВСК и зачем всё это нужно.
На пятой встрече ProcessTech и Страхового Дома ВСК я рассказал, что было дальше: как мы из BI-дашбордов перешли к процессной аналитике, внедрили инструменты Process Mining, Task Mining и построили центр компетенций по процессной аналитике в ИТ.
Эта статья — почти практический гайд по внедрению процессной аналитики в крупной компании. Без обобщений. Только конкретика, цифры, архитектура решений и кейсы. Рассчитываю, что статья будет полезна как для ИТ-специалистов, так и для руководителей, которые хотят перестать управлять на основе ощущения, а не данных.
Почему мы продолжили путь: от BI к Process Mining
Всего за 5 месяцев после закупки лицензий в ИТ-блоке уже 9 внутри командных review и рабочих групп с бизнесом проводятся с демонстрацией BI-аналитики Proceset (без Power Point и Excel). На первом этапе трансформации мы выстроили мощный слой BI. Благодаря интерактивным дашбордам:
Команды получили доступ к ключевым метрикам процессов;
Руководители — к автоматическим отчётам и отклонениям;
А планёрки — к аналитике в реальном времени.
Но со временем стало понятно: BI даёт нам ответы на вопрос «что произошло?», но не всегда позволяет понять «почему?».
Тогда мы поставили цель: внедрить инструменты процессной аналитики, которые помогают визуализировать реальный маршрут процессов, находить отклонения, «петли», задержки и узкие места. Это и стало вторым этапом развития культуры данных в нашем ИТ-блоке.
Технический стек
Если говорить про инструменты, мы используем:
Process Mining, как модуль Proceset — для процессной аналитики, построения карт процессов, чек-листов, калькуляторов;
BI, как модуль Proceset — основная BI-платформа для планёрок и аналитики;
Jira Service Desk — ключевой источник событий процессов;
PostgreSQL + REST API — для ETL, агрегатов и историчности.
Важно: мы не брали дорогостоящие консалтинг-решения. Все пилоты, обучение и внедрение — силами своей команды. Это критично для масштабируемости.
BI как точка входа в процессную аналитику
Мы начали не с Process Mining, а с BI — и это стратегически верное решение. Перед тем как анализировать поведение процессов, важно договориться о терминах, метриках, логике оценки.
Преследовали такую цель: приобщить потенциальных заказчиков, топ-менеджеров ИТ-блока к инструменту, познакомить с возможностями, выработать доверие к инструменту
Сформулировали задачу — автоматизировать KPI по ключевым процессам подразделений центра эксплуатации ИТ для формирования поручений по отклонениям на ответственных
Что сделали на этом этапе:
Построили 20+ дашбордов по ключевым направлениям: поддержка, инфраструктура, инциденты, проблемы, запросы;
Разработали единый стиль визуализации: карточки, динамика, детализация;
Интегрировали источники: Jira, CMDB, внешние API, БД, Excel;
Внедрили практику BI-планёрок: еженедельные сессии анализа с руководителями направлений.
Конкретные эффекты:
Автоматизировано 100+ метрик процессов;
Сокращено 2 200+ часов ручного труда ежегодно;
Получение информации — ежедневно/ежечасно вместо 1 раза в неделю;
Доверие к данным — выросло кратно, за счёт прозрачности расчётов.
Особенность: мы включили в дашборды не только агрегаты, но и распределения, доверительные интервалы, временные лаги между этапами, отклонения по медианам. Это позволило перейти от классического отчётного BI к аналитическому BI — когда дашборд не просто отображает цифры, но и провоцирует вопросы и гипотезы.
Автоматизированные KPI: центр управления в реальном времени
BI-дашборды были логичным переходом к следующему проекту — автоматизации KPI. До этого многие KPI собирались вручную, по e-mail, в Excel, с недельными лагами.
Технически:
Настроили ETL через SQL и API к Jira, внутренним CRM и IDM-системам;
Использовали градацию KPI: зелёный / жёлтый / красный с автоматическим вычислением порогов;
Визуализировали дашборды в BI Proceset.
Это позволило перейти к модели «KPI-driven Management»: решения о корректирующих действиях стали приниматься не по интуиции, а по фактам — на BI-сессиях, с фиксированными поручениями.
Process Mining: как мы начали видеть реальный процесс
Когда сформировался слой BI и привычка к регулярному анализу, мы перешли к следующему этапу — Process Mining. Использовали платформу Proceset.
Стартовали с процесса управления инцидентами в Jira Service Desk:
Оцифровали 1 400+ процессов каталога услуг в процессе управление инцидентами;
Построили карты маршрутов, отклонений, медианных времен;
Визуализировали распределения по SLA и точкам задержки.
Видим ключевые показатели процесса, карта процесса и метрики, описывающие процесс и помогающие в поиске отклонений. В кейсе выбран процесс управления инцидентами по услуге обращения по ДМС.
Как работаем с инструментом?
Видим красный индикатор, указывает на превышенное медианное время решения от норматива. Далее анализируем карту процесса и топ маршруты, в каждом из которых отклонение по медианному времени, для формирования гипотез по повышению эффективности процесса.
Какие результаты показал пилот Process Mining?
Гипотеза на пилот следующая
С помощью Process Mining возможно оцифровать услуги по управлению инцидентами с избыточными нормативами SLA для бизнес-заказчиков, и определить количество часов для сокращения по каждой услуге.
Как результат
Разработан инструмент прогнозируемых значений SLA при снижении нормативного времени выполнения для услуги. Решение позволяет проверять гипотезы по оптимизации нормативов SLA и управлять ожиданиями бизнес-заказчиков.
SLA-калькулятор: управление ожиданиями через симуляции
BI и Process Mining дали нам идеи для построения следующего инструмента: SLA-калькулятора.
Он позволяет:
Вводить текущий норматив SLA (например, 12 часов);
Смотреть процент заявок, укладывающихся в этот норматив;
Моделировать снижение норматива: на 10%, 20%, 30% и получать прогнозное выполнение SLA.
Почему это важно?
Для 300+ услуг оптимизировали нормативы SLA без отклонения целевых значений по уровню сервиса;
Снизили нормативы без падения фактического выполнения уровня сервиса;
Подписали 8 соглашений SLA с блоками бизнес-заказчиков.
В некоторых случаях норматив снизился с 12 до 2 часов без изменения % выполнения. Это стало мощным аргументом в переговорах с бизнесом.
Заключение: главное — не бояться!
Процессная аналитика — это не про инструменты. Это про образ мышления. Когда вы не спрашиваете «кто виноват?», а ищете «почему это произошло» и «как сделать лучше».
Мы часто цитируем внутри команды фразу: «Действуй сегодня, чтобы завтра не жалеть о несделанном». Если вы задумываетесь о внедрении BI, KPI, Process Mining —начните с малого. Постройте один полезный дашборд. Приведите на планёрку одну карту процесса. И вы удивитесь, как быстро команда начнёт задавать правильные вопросы.
Подписывайтесь на наш блог на Хабре, подкаст «Дневник ИТ-шника» и сообщество ВК.
Будем рады диалогу и обмену опытом: пишите комментарии!