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

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

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

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

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)

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

Получили:

Метрика	Значение	Комментарий
Заявок	7 554
Событий	65 533	~8.68 событий на заявку
Период	март 2010 - > май 2012	2 года данных
Тип события	4	Accepted, Completed, Queued, Unmatched
Состояние	13	Assigned, In Progress, Wait - User, Wait - Vendor, ...
Продуктов	704	PROD1 … OTHERS
Ресурсов	1 440	Число исполнителей
Событий на заявку	медиана 6, максимум 123	Разброс 20x

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

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 реальных комбинаций.

Частота	События	Доля от 65 533(общее число событий)
30 239	Accepted + In Progress	46.1%
11 544	Queued + Awaiting Assignment	17.6%
6 115	Completed + Resolved	9.3%
5 716	Completed + Closed	8.7%
4 217	Accepted + Wait - User	6.4%
3 221	Accepted + Assigned	4.9%
2 035	Completed + In Call	3.1%
1 533	Accepted + Wait	2.3%
493	Accepted + Wait - Implementation	0.8%
313	Accepted + Wait - Vendor	0.5%
101	Accepted + Wait - Customer	0.15%
5	Unmatched + Unmatched	0.01%
1	Completed + Cancelled	0.002%

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

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 уникальных вариантов процесса

Уникальных вариантов процесса	2 278
Топ-1 вариант покрывает	23.2% (1 749 заявок)
Топ-10 вариантов покрывают	48.1%
Вариантов для 80% заявок	768
Вариантов для 95% заявок	1 901
Остальные 2 268 вариантов покрывают	51.9% (3 918 заявок)

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

Процесс не стандартизирован. На 7 554 заявок - 2 278 вариантов процесса. Это спагетти-процесс: каждый случай уникален, предсказать нельзя.
Для 80% заявок нужно 768 разных вариантов процесса. Нельзя написать один регламент, который покроет большинство случаев.
Остальные 2 268 вариантов покрывают 51.9% заявок. Из них 1 901 вариант встречается 1–5 раз. Это уникальные случаи, которые почти не повторяются.

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

№	%	Особенность
1	23.2%	Без ожиданий, закрытие по звонку
2	6.9%	Без ожиданий, закрытие через «Решена
3	4.7%	Очередь после начала работы
4	4.0%	Очередь до начала работы
5	2.7%	Очередь + ожидание пользователя
6	2.1%	Две очереди после начала работы, пинг-понг
7	1.6%	Ожидание пользователя без очереди
8	1.3%	Два процесса «очередь - > работа
9	0.9%	Очередь + назначен исполнитель
10	0.7%	Очередь + назначен исполнитель + ожидание пользователя

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

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

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

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

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

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

Процесс не предсказуем.
Нельзя обучить сотрудника «как правильно - правильных путей 768(в 80%).
Нельзя автоматизировать, нельзя измерить эффективность - нет стандартного сценария.

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

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

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

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

Результаты:

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

Метрика	Значение
Медиана по времени процесса	7.55 дней
Среднее арифметическое	12.08 дней
75-й перцентиль	12.41 дня
95-й перцентиль	35.69 дней
Максимальная длительность процесса	771.35 дней

Ожидания:

Тип ожидания	События	Доля
Queued + Awaiting Assignment	11 544	17.62%
Accepted + Wait - User	4 217	6.43%
Accepted + Wait	1 533	2.34%
Accepted + Wait - Implementation	493	0.75%
Accepted + Wait - Vendor	313	0.48%
Accepted + Wait - Customer	101	0.15%
Итого	18 201	27.8%
Метрика
Заявок с хотя бы одним ожиданием	5 096	67.5%
Заявок без ожиданий	2 458	32.5%

Аномалии:

Порог	Заявок
> 50 событий	29
> 30 событий	165
> 20 событий	494

Заявка	События	Длительность
1-687082195	123	82.3 дня
1-660915327	116	92.9 дня
1-627973205	90	139 дней
1-692067345	76	74.2 дня
1-722362086	75	20.8 дня

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

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

Продукт	Заявок
PROD424	882
PROD660	484
PROD253	226
PROD383	205
PROD494	186

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

Продукт	Средняя длина цепочки событий
PROD788	62.00
PROD510	56.00
PROD303	49.00
PROD227	46.00
PROD396	44.00

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

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

Метрика	Значение
Медиана по времени процесса	7.55 дней
Среднее арифметическое	12.08 дней
75-й перцентиль	12.41 дня
95-й перцентиль	35.69 дней
Максимум	771 день (2+ года!)

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

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

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

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

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

Тип ожидания	События	Доля
Queued + Awaiting Assignment	11 544	17.62%
Accepted + Wait - User	4 217	6.43%
Accepted + Wait	1 533	2.34%
Accepted + Wait - Implementation	493	0.75%
Accepted + Wait - Vendor	313	0.48%
Accepted + Wait - Customer	101	0.15%
Итого	18 201	27.8%

3.3 Пинг-понг

3.4. Аномалии

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

3.5. Продукты

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

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

#	Проблема	Масштаб	Причина
1	Долгое время процесса	медиана 7.5 дней	Ожидания, пинг-понг
2	Пинг-понг	52.5% заявок	Заявку берут те, кто не может решить
3	Ожидания	27.8% событий, 67.5% заявок	Ждём пользователя, вендора, «реализации
4	Аномалии	29 заявок >50 событий	Заброшенные заявки
5	Раздутая классификация	704 продукта	Нет фокуса

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 заявки. Если это типовой продукт, многие проблемы могут решаться:

Через базу знаний (пользователь сам находит решение)
Через автоматическую диагностику (система сама определяет причину)
Через скрипты самовосстановления

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

Метрика	AS-IS	TO-BE (прогноз)
Медиана времени процесса	7.5 дней	1–2 дня
Пинг-понг	52.5%	<10%
Ожидания	27.8% событий	<10%
Уникальных вариантов	2 278	<100
Аномалии (50+ событий)	29	0–2

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

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

Описание - 7 554 заявки, 4 типа событий, 13 состояний (Шаг 1)
Моделирование - 13 комбинаций, 2 278 вариантов (Шаг 2)
Анализ - медиана 7.5 дней, пинг-понг 52.5%, ожидания 27.8% (Шаг 3)
Оптимизация - 4 конкретных улучшения
Реинжиниринг - смена логики: от очереди к владельцу, от линий к продуктам

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

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

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

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

ЗАКЛЮЧЕНИЕ

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

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