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

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

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

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

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