Прежде чем сломать: о шаблонах и проверках

Вы точно знаете: «То, что нельзя измерить — нельзя улучшить». Но это лишь половина правды. Вторая половина: «То, что нельзя понять в контексте — нельзя правильно измерить».

Что вам скорее всего дадут при входе в проект? Стопку регламентов и презентацию с KPI. И скажут с гордостью «вот как у нас всё устроено» или скорее со смирением «так исторически сложилось».

Но система — это не то, что написано в регламентах. Это то, что на самом деле происходит, когда никто не смотрит. А чтобы это узнать, нужно провести аудит.

В этой статье — мой пошаговый план диагностики отдела, проекта или целого направления. Он подойдет и новому руководителю, и тем, кто чувствует: «что-то пошло не так», но не может понять, где именно.

Потому что они отвечают на вопрос «КАК делать», пропуская этап «ЧТО и ПОЧЕМУ у нас сломано». Универсальный KPI вроде «скорости ответа» может быть бесполезен, если 80% обращений - это один и тот же баг в продукте, о котором молчит разработка.

Система - уникальный организм из трех слоев:

· Данные (что на самом деле происходит)

· Процессы (как это происходит)

· Люди (кто это делает и что они при этом чувствуют)

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

Здесь ищем не «красивые» метрики для отчетов, а диагностические.

Что делаем:

1. Выгружаем все обращения за последние 3-6 месяцев. Если у вас поддержка — это тикеты из HelpDesk. Если разработка — задачи из таск-трекера. Нам нужен массив, с которым можно работать.

2. Классифицируем вручную 50-100 случайных записей. Не по тем категориям, которые заведены в системе, а по реальным: «баг», «вопрос», «хотелка», «доступ», «платеж». Обычно реальная картина отличается от официальной раз в десять.

3. Смотрим не на среднюю температуру по больнице, а на распределение:

o Вместо CSAT — тренд повторных обращений по одной теме. Если люди приходят с одним и тем же по три раза — это не проблема поддержки, а проблема продукта или документации.

o Вместо «среднего времени ответа» — распределение времени по типам запросов. Одно дело — 5 минут на сброс пароля, другое — 5 часов на техническую проблему.

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

o Для поддержки: от первого обращения до закрытия (не первого ответа, а именно решения)

o Для разработки: от постановки задачи до выкатки на прод

o В одном из проектов этот цикл составлял 20+ дней. Данные показали, что дело не в лени поддержки, а в 4-дневных задержках на согласование с финансами, о которых мы даже не думали.

Что на выходе:

· Понимание, какие типы запросов реально занимают время команды

· Один-два узких места, где процесс буксует (конкретные цифры)

· Гипотезы, которые будем проверять дальше

Слой 2. Процессы (Где теряется энергия и качество?)

Теперь знаем, что болит по данным. Идем смотреть, как это выглядит в реальности.

Что делаем:

1. Картируем путь типичного запроса. Берем 5-7 реальных кейсов (простой, сложный, эскалированный) и проходим весь их путь от первого сообщения до закрытия. Не по документации, а в реальности.

2. Фиксируем все рукопожатия:

o Сколько передач между людьми?

o Сколько времени висит в ожидании у каждого?

o Где информация теряется или искажается?

3. Ищем точки «глупости». Главный вопрос на этом этапе: «Какой шаг выглядит максимально тупо для клиента или для сотрудника?» (спросите первую линию – они знают, проверено)

o Часто это точка, где информация «сбрасывается в чат» или уходит в черную дыру другой команды без статуса

o Или момент, где нужно в пятый раз ввести одни и те же данные

o Или ожидание подписи, которая нужна только для галочки

Что на выходе:

· Карта текущего состояния (как есть, а не как написано в регламенте)

· Список самых болезненных передач и ожиданий (с таймингом!)

· Понимание, где процесс помогает, а где — мешает

Слой 3. Люди (Кто и как это делает?)

Самый важный и самый деликатный слой. Здесь смотрим не на KPI, а на компетенции, мотивацию и боль.

Что делаем:

1. Проводим наблюдение. Садимся рядом (физически или виртуально) и смотрим, как человек работает в реальном времени. Не контроль, а именно наблюдение:

o Сколько открыто вкладок?

o Где ищет информацию? (в базе знаний, в чате у коллег, в голове?)

o Какие действия повторяет вручную?

2. Проводим 1-by-1 с вопросами о помехах, а не об эффективности:

o «Что отнимает у тебя больше всего времени?»

o «Какая самая бестолковая операция в твоей работе?»

o «Какой информации тебе не хватает для идеальной работы?»

Важно: просто записываем.

3. Результат этого слоя — понимание, являются ли текущие процессы помощниками или врагами для наших специалистов.

Что на выходе:

· Понимание реальной загрузки и узких мест команды

· Список того, что бесит людей больше всего (часто это совпадает с точками глупости из процессов)

· Оценка готовности к изменениям

Вот каркас, с которым можно начинать. В идеальной картине мира на один блок уходит 1 неделя.

ЧЕК-ЛИСТ: АУДИТ КЛИЕНТСКОГО СЕРВИСА

Блок 1: Данные

· Выгрузить все обращения за последние 3-6 месяцев

· Вручную классифицировать 50-100 случайных тикетов по реальным причинам

· Выявить 3-5 ключевых метрик, которые реально влияют на бизнес (доля повторных обращений, цикл решения для топ-3 проблем, стоимость обращения)

· Найти один операционный цикл, критичный для бизнеса, и замерить его полную длительность

Блок 2: Процессы

· Выбрать 5-7 реальных кейсов (простой, сложный, эскалированный)

· Пройти их путь от лица клиента и от лица специалиста

· Зафиксировать все точки передачи ответственности, ожидания и смены инструментов

· Найти минимум одну «точку глупости» (где создается фрустрация)

Блок 3: Люди

· Провести наблюдение за работой 2-3 сотрудников

· Провести 1-by-1 с каждым с вопросами о помехах

· Зафиксировать, что бесит команду больше всего

· Оценить готовность к изменениям

Блок 4: Синтез

· Сопоставить данные слоев: где самые больные метрики? совпадают ли они с самыми запутанными процессами и болью команды?

· Сформулировать одну ключевую гипотезу (не «надо всё починить», а конкретную)

· Наметить один небольшой эксперимент для проверки гипотезы на следующий месяц

Вместо совета и заключения

Аудит — это не про то, чтобы найти виноватых. Вам нужно увидеть систему такой, какая она есть. Без прикрас, без «у нас так принято», без «ну это же очевидно».

Когда вы видите систему целиком — вы перестаете «тушить» симптомы и начинаете чинить причину. И да, после первого аудита обычно хочется все сжечь и построить заново. Не надо.
Просто выберите задачу и сделайте один маленький шаг.