Описательный анализ и где он обитает

Просто стало интересно - что такое описательный анализ. Математический анализ, функциональный анализ знаю. А описательный?

Наверно такое определение подойдет: Описательный анализ - это последовательность шагов, которая превращает сырые данные в понимание процесса. Маркетологи наверно будут говорить, что это не анализ, а аналитика, ну это их проблемы.

Как теоретическую основу я использовал идеи из следующих источников:

Process Mining - Ван дер Аалст, «Process Mining: Data Science in Action (2016). Методология извлечения знаний о процессе из логов событий.

EDA (Exploratory Data Analysis) - Тьюки, 1977. Принцип: сначала смотреть на данные, потом строить модели.

Lean Six Sigma - DMAIC (Define, Measure, Analyze, Improve, Control). Стандартная методология улучшения процессов.

Я не применяю всех методов, описываемых в Process Mining: Data Science in Action. Для данного анализа достаточно понимать, что наука о данных - это, в частности,  превращение данных в реальную ценность.

В этой статье ценность - понимание процесса. Мы не строим прогнозы, не используем машинное обучение. Мы делаем описательный анализ: превращаем сырые логи в картину того, как процесс работает на самом деле.

В статье неявно используется дискретная математика, теория графов, а математическая статистика не потребовалась. Еще: для меня реальные значения более информативны, чем картинки, но для любителей несколько диаграмм я все ж добавил. В тексте много цифр, я старался показать весь процесс, но для понимания результатов можно смотреть только выводы в конце каждого шага

В качестве данных для  анализа я решил взять службу управления инцидентами. В российских компаниях такие данные в открытом доступе найти невозможно, поэтому посмотрел, что есть у западных компаний. Нашел Volvo IT BPI Challenge 2013, incidents вот отсюда: https://data.4tu.nl/datasets/0fc5c579-e544-4fab-9143-fab1f5192432/1 

Порядок действий, составленный на основе Process Mining:

1. Event log - журнал событий, сырые данные.

2. Descriptive statistics - смотрим, что в этих данных есть: длительность событий, какие события происходят чаще, аномалии, распределение по продуктам, кто что делает и т.п.

3. Process discovery -  строит модель. Отвечает на вопрос: как процесс выглядит в типичном случае?

4. Conformance checking - проверяет насколько логи соответствуют построенной модели.

5. Performance analysis - анализ производительности.

6. Enhancement - улучшение процесса на основе полученных знаний.

На основании предмета анализа сформировались приблизительные шаги:

1. Описание процесса

Фиксируем, что есть. Какие события происходят, кто их совершает, в каком порядке. Не как должно быть по регламенту, а как есть на самом деле.

2. Моделирование процесса

Переводим описание в формальный граф, где видно все пути. Из сырых данных строим карту: откуда заявка приходит, куда идёт, где разветвляется. На этом шаге становятся видны все реальные маршруты, а не только типовой.

3. Анализ процесса

Считаем метрики: сколько времени идёт процесс, где задержки, сколько возвратов, какие шаги дублируются. Сравниваем как должно быть и как есть. Ищем узкие места.

4. Оптимизация процесса

Улучшаем то, что есть. Убираем лишние шаги, автоматизируем рутину, сокращаем согласования. Процесс не ломаем - подтягиваем.

5. Реинжиниринг процесса

Меняем логику. Задаём вопрос: а почему этот процесс вообще так устроен? Если процесс неэффективен по своей сути - оптимизация не поможет. Нужно менять процесс.

6. Цикл замыкается: после реинжиниринга снова описываем процесс - уже новый.

В соответствии с предметом анализа определим следующие понятия:

Заявка - первичное обращение с проблемой, а также:

Заявка или Процесс - последовательность событий, возникающих по одной заявке.

Событие - одно действие в логе. Запись о том, что что-то произошло: заявку приняли, перевели в работу, отправили в ожидание, закрыли. У события есть время, автор, тип.

Метрики, которые будем смотреть:

• Case duration (время одного процесса)

• Activity frequency (частота событий каждого типа)

• Variants (количество вариантов процесса, также смотрим на правило Парето (80/20) - оценка, насколько процесс сходится к типовым сценариям).

• Waiting time( процесс не двигается)

• Rework / ping-pong (неоднократный возврат заявки в очередь)

• Anomalies( процессы с очень длинным временем)

• Распределение по продуктам(число заявок по продуктам)

Сами расчеты я разбил на три шага:

ШАГ 1. ОПИСАНИЕ ПРОЦЕССА (step1.py)

Смотрим, что есть в логах - сколько заявок, сколько событий, за какой период, какие типы событий, продукты.

Получили:

Что здесь видно:

1. Процесс - плоский по событиям, но глубокий по состояниям.

У нас всего 4 события, но 13 состояний. Это значит, что реальный процесс это комбинация concept: name (тип события) + lifecycle: transition (состояние в  котором оказывается заявка). Например:

- Accepted + Assigned - заявка принята и назначена.

- Queued + Awaiting Assignment - в очереди, ждёт назначения.

- Accepted + Wait - Customer - ждём ответа клиента.

- Accepted + Wait - Vendor - ждём вендора.

Именно состояния будем моделировать на Шаге 2, иначе модель будет бессмысленной - из 4 событий ничего не построишь.

2. 704 продукта при 7 554 заявках.

В среднем ~10 заявок на продукт. Это очень мелкое дробление. Значит: либо продуктов реально много и они все редкие, либо классификация перегружена лишними категориями продуктов - OTHERS...

3. Медиана по числу событий - 6 событий, максимум 123.

Половина заявок обрабатывается за 6 событий или меньше - это нормальное количество действий. Но есть процессы - аномалии с 123 событиями - в 20 раз больше медианы. Скорее всего, это сложные инциденты с многократными эскалациями,  пинг-понг между исполнителями, заявки, которые долго висели в Wait - User или Wait - Vendor.

На основании этих данных процесс выглядит так:

• Заявка поступает - > Accepted + Assigned

• Если не могут сразу - > Queued + Awaiting Assignment (в очередь)

• Назначена исполнителю - > Accepted + In Progress

• Может уйти в ожидание: Wait - User / Wait - Vendor / Wait - Customer / Wait - Implementation

• Решена - > Completed + Resolved

• Закрыта - > Completed + Closed

• Либо Unmatched - если не смогли сопоставить с известной проблемой.

Выводы по Шагу 1:

• Ожидания (Wait - *) - это «мёртвое время, когда заявка висит, и никто с ней ничего не делает;

• Очередь (Queued + Awaiting Assignment) - это тоже ожидание;

• Дробление (1 440 ресурсов, 704 продукта) - возможна потеря ответственности;

• Аномалии (123 события) - где-то процесс ломается и заявка зависает.

ШАГ 2. МОДЕЛИРОВАНИЕ (step2.py)

Строим карту реального потока заявок. Для этого выявляем комбинацию типа событии и состояний. Затем считаем, сколько таких комбинаций, как часто они встречаются, сколько уникальных последовательностей событий в заявках и сколько вариантов нужно, чтобы покрыть 80% и 95% заявок.

Всего заявок: 7 554
Уникальных вариантов процесса: 2 278

Из 4 типов событий и 13 состояний получилось 13 реальных комбинаций.

Что это значит:

• Accepted + In Progress - это почти половина всех событий. Заявка «в работе - доминирующее состояние.

• Queued + Awaiting Assignment - 17.6%. Это ожидание. Заявка просто лежит в очереди и ждёт, пока её кто-то возьмёт.

• Wait - * (все виды) - 4 217 + 1 533 + 493 + 313 + 101 = 6 657 событий, или 10.2%. Это чистое ожидание - заявка ждёт пользователя, вендора, реализации и т.д.

Итого ожидания: Queued + Wait - * = 18 201 событий = 27.8% всех событий.

Вариативность: 2 278 уникальных вариантов процесса

Что это значит:

• Процесс не стандартизирован. На 7 554 заявок - 2 278 вариантов процесса. Это спагетти-процесс: каждый случай уникален, предсказать нельзя.

• Для 80% заявок нужно 768 разных вариантов процесса. Нельзя написать один регламент, который покроет большинство случаев.

• Остальные 2 268 вариантов покрывают 51.9% заявок. Из них 1 901 вариант встречается 1–5 раз. Это уникальные случаи, которые почти не повторяются.

Рассмотрим 10 наиболее часто встречающихся вариантов процесса: 

Сначала простые процессы. Потом очереди. Потом ожидание пользователя. Потом комбинации. И чем дальше, тем меньше заявок.

Выводы по Шагу 2:

Проблема 1. Ожидание:

27.8% событий - это Queued и Wait - *. Заявка не обрабатывается, а просто ждёт. Это «мёртвое время процесса.

Проблема 2. Катастрофическая вариативность:

2 278 уникальных путей при 7 554 заявках. Каждая третья заявка идёт по уникальному пути. Это означает, что:

• Процесс не предсказуем.

• Нельзя обучить сотрудника «как правильно - правильных путей 768(в 80%).

• Нельзя автоматизировать, нельзя измерить эффективность - нет стандартного сценария.

Проблема 3. «Пинг-понг между исполнителями:

Варианты 3, 5, 6, 8, 9 показывают: заявка возвращается в очередь после начала работы. Исполнитель взял заявку - > понял, что не может решить - > вернул в общую очередь. Другой взял - > та же история. И так до тех пор, пока кто-то не решит.

ШАГ 3. АНАЛИЗ (step3.py)

Считаем метрики процесса - время процесса, ожидания, возвраты в очередь, аномалии, распределение по продуктам. Чтобы понять, где процесс плохо работает.

Результаты:

Время процесса:

Ожидания:

Аномалии:

Распределение по продуктам:

Топ-5 по числу заявок:

Топ-5 по средней длине цепочки событий:

Выводы по Шагу 3:

3.1. Время процесса - катастрофа

Половина процессов длится больше недели.

5% - больше месяца.

Одна из заявок 771 день. Это брошенная заявка, которую кто-то «забыл закрыть. Она не попала в топ 5 по числу событий.

Среднее арифметическое время процесса (12 дней) больше медианы (7.5 дней) - значит, есть длинный хвост: несколько очень долгих заявок тянут среднее вверх.

3.2. Ожидания: 27.8% событий

3.3 Пинг-понг

3.4. Аномалии

139 дней это самая длинная из топ-5. Это управленческий провал: заявка не решается и не закрывается.

3.5. Продукты

Доминирующий продукт PROD424. Надо разбираться - какой-то элемент постоянно ломается. PROD788, PROD510, PROD303 - сложные продукты, очень много событий.

ВЫЯВЛЕННЫЕ ПРОБЛЕМЫ

• 52.5% заявок возвращаются в очередь - > Каждый возврат = время на «взять-понять-вернуть

• 67.5% заявок имеют ожидания - > Ожидания = 27.8% событий = «мёртвое время

• Медиана 7.5 дней, хвост 771 день

• Разные исполнители, разные команды, разные пути обработки - > 2 278 уникальных вариантов процесса

Это все говорит о том, что процесс невозможно предсказать, обучить, автоматизировать.

ОПТИМИЗАЦИЯ

1. Снизить пинг-понг

Проблема: 52.5% заявок возвращаются в Queued + Awaiting Assignment - либо до начала работы, либо после.
Гипотеза: заявки берут исполнители, которые не могут их решить (не тот навык, не тот продукт, не та зона ответственности).
Решение:

• Внедрить маршрутизацию по продукту: заявка сразу идёт к тому, кто знает этот продукт.

• Ввести «правило одного касания: если взял заявку - либо реши, либо эскалируй с обоснованием, но не возвращай в общий пул.

• Построить матрицу компетенций: кто какие продукты знает, и маршрутизировать по ней.

Ожидаемый эффект: снижение возвратов с 52.5% до 25-30%.

2. Сократить ожидание Wait - User

Проблема: 4 217 событий Wait - User (6.4% всех событий). Это заявки, которые ждут ответа от пользователя.
Решение:

• Автоматические напоминания пользователю через 24/48 часов

• Автозакрытие, если пользователь не отвечает 7 дней (с уведомлением)

• Ожидаемый эффект: снижение Wait - User на 30-40%.

3. Разобраться с аномалиями

Проблема: 29 заявок с 50+ событиями.

Решение:

• Ввести правило эскалации по времени: если заявка открыта > 30 дней - автоматически эскалируется руководителю. Это не изменит медиану, но уберёт аномалии.

• Ввести отчёт по заявкам без событий > 14 дней.

Ожидаемый эффект: ликвидация аномалий, снижение максимума до ~ 60 дней.

4. Фокус на топ-продукты

Проблема: 704 продукта. Но PROD424 - 882 заявки, PROD660 - 484. Топ-5 продуктов покрывают ~26% заявок.

Решение: создать выделенные команды для топ-5 продуктов. Для остальных - команды по категориям продуктов, чтобы не создавать одну большую очередь.

Ожидаемый эффект: снижение времени процесса для топ-продуктов на 30–40%.

РЕИНЖИНИРИНГ

Текущая логика процесса:

• Заявка попадает в общий пул (Queued + Awaiting Assignment)

• Кто-то её берёт (Accepted + Assigned)

• Начинает работу (Accepted + In Progress)

• Если не может - возвращает в общий пул (пинг-понг)

• Ждёт пользователя / вендора / «реализации (Wait - *)

• В итоге кто-то решает и закрывает

Проблема логики:

Заявка не имеет владельца с самого начала. Она ничья, пока кто-то её не возьмёт. Исполнитель не обязан её решить. Он может вернуть. Нет ответственности за конечный результат.

Что может предложить реинжиниринг:

1. От общего пула к владельцу с момента поступления заявки

Вместо очереди - автоматическая маршрутизация по продукту и компетенции. Заявка сразу попадает к тому, кто знает продукт. Владелец - конкретный человек, а не очередь.

2. От многоуровневой поддержки к продуктовым командам

Сейчас заявка идёт по цепочке: первая линия - > вторая линия - > третья линия. Каждая передача - потеря времени и контекста.

Альтернатива: сквозные команды по продуктам. Один человек (или команда) владеет продуктом от начала до конца.

3. Автоматизация ожиданий

• Wait - User - > чат-бот собирает информацию у пользователя до создания заявки

• Wait - Vendor - > автоматический запрос в систему вендора

• Wait - Implementation - > интеграция с системой изменений

4. Самообслуживание для типовых случаев

PROD424 - 882 заявки. Если это типовой продукт, многие проблемы могут решаться:

• Через базу знаний (пользователь сам находит решение)

• Через автоматическую диагностику (система сама определяет причину)

• Через скрипты самовосстановления

Ожидаемый эффект реинжиниринга

Что можно сделать еще?

У нас есть полный набор данных:

• Описание - 7 554 заявки, 4 типа событий, 13 состояний (Шаг 1)

• Моделирование - 13 комбинаций, 2 278 вариантов (Шаг 2)

• Анализ - медиана 7.5 дней, пинг-понг 52.5%, ожидания 27.8% (Шаг 3)

• Оптимизация - 4 конкретных улучшения

• Реинжиниринг - смена логики: от очереди к владельцу, от линий к продуктам

Дальше можно:

- Применить оптимизацию и реинжиниринг, через некоторое время проанализировать новые данные и посмотреть эффект.

- Продолжить анализ - разобрать аномалии (что в 123 событиях?), связь продукт - время.

- Построить новую модель TO-BE.

ЗАКЛЮЧЕНИЕ

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

P.S. Это, конечно, Вольво 2012 года, у них вероятно не было онлайн контроля клиентских устройств. Я думаю, что сейчас можно стремиться к тому, чтобы выявлять проблему раньше клиента, чтобы инженеры сразу начинали с ней работать, особенно если это внутренние проблемы системы. И когда позвонит клиент ему уже можно будет сказать что случилось и сколько потребуется времени на устранение неисправности. Именно это клиент и хочет услышать, а не "выясняем".

Ссылки на скрипты

step1.py - https://github.com/yar2-7/volvo-process-mining/blob/main/step1.py

step2.py - https://github.com/yar2-7/volvo-process-mining/blob/main/step2.py

step3.py - https://github.com/yar2-7/volvo-process-mining/blob/main/step3.py

diag1.py - https://github.com/yar2-7/volvo-process-mining/blob/main/diag1.py

diag2.py - https://github.com/yar2-7/volvo-process-mining/blob/main/diag2.py

diag3.py - https://github.com/yar2-7/volvo-process-mining/blob/main/diag3.py