Магазин закрыт. Кассы зависли. Команда меняет батарейки.
Магазин сообщил о проблеме - кассы перестали работать. Прошел час. Потом второй. Никто не позвонил, никто не приехал. Когда я спросил команду поддержки - что случилось? - ответ был честным. Мы не видели. Были в другом чате. Один менял батарейки в мыши у кого-то в офисе. Другой помогал секретарю с Excel. Третий - картриджи.
А магазин в это время просто стоял.
Чатов с заявками было больше двадцати. Отдел вырос - завели отдельный чат. Вышли в новый регион - завели региональный. На старте был один сотрудник и один чат. Потом у пяти человек оказалось двадцать с лишним чатов. Приоритет определял тот, кто первым успел написать, или тот, кто мог физически дойти до нужного инженера. Если проблема была действительно критической, она могла потеряться в общем шуме. По каким-то мелочам при этом эскалировали до CEO.
Внутри команды выработалось рабочее решение: написать в чат и следом добавить CEO. CEO - это сигнал, что надо бросить всё и делать то, что скажет CEO. Команда адаптировалась: из потока заявок выбирали что-то простое и делали. По остальным логика была другой - CEO придет, скажет что важно.
Вот и вся система приоритизации.
CEO как ручной маршрутизатор
Участие CEO в ежедневных ИТ-вопросах было запредельным. В начале - до десяти обращений в день. Люди это знали и использовали. Если не добавить CEO - можно ждать бесконечно. Если добавить - получишь реакцию.
Это не была слабая команда. Это была команда без управляемой системы.
Единого входа для заявок не было - только чаты. Матрицы приоритетов не было - только громкость голоса и право прямого доступа. Категоризации не было - никто не знал, где чаще всего ломается и почему. Владельца на заявку и срока закрытия - тоже. Аналитики повторов - не существовало, и понять, где источник проблем, было невозможно.
Когда случался массовый сбой - все чаты разрывались от сообщений. Координировать действия в этой куче было невозможно. Вытащить информацию - тоже.
Бизнес жаловался на ИТ. ИТ просило людей. Получало закономерный ответ: у вас в текущем составе порядка нет - добавим людей, будет больше беспорядка.
Выйти из этого тупика можно было только одним способом - поменять архитектуру, а не залить хаос дополнительными людьми.
Пока обращения жили в чатах, у поддержки не было настоящей экономики. Нельзя было посчитать, сколько стоит один тип проблемы, какие сбои повторяются, где команда тратит время и какой OPEX уходит на ручную маршрутизацию. Бизнес видел только раздражение. Цифр не было.
Первый честно измеренный SLA: 48%. Это не было падением.
Начали с покупки системы учета заявок на базе 1С. Инструмент обошелся в 40 000 рублей. Но результат дала не цена системы, а правила вокруг нее. Настройка - простая: любая проблема уходит на почту, в ответ приходит номер зарегистрированной заявки. Можно написать в чат - но только с номером. Без номера - нет управляемого SLA.
Договорились начать с одного подразделения. Через неделю провели первый разбор - категорий по источнику и способу закрытия оказалось слишком много. Начали упрощать.
Параллельно ввели матрицу приоритетов - не по должности заявителя, а по влиянию на бизнес:
- блокирующий: остановка работы компании
- критический: остановка группы магазинов или склада
- высокий: остановка одного магазина или офиса
- нормальный: остановка одной кассы, одних весов - всё, что снижает уровень сервиса
- низкий: всё, что может подождать
Ввели категоризацию - где произошло, что сломалось, кто владелец домена. Ввели способ закрытия: ремонт, вызов подрядчика, ошибка в программе, ошибка пользователя, инструкция, ошибка в данных.
За две недели систему масштабировали на все подразделения: каждый второй день закрывался один чат. Все двадцать с лишним чатов ушли внутрь единой системы.
Теперь по каждому типу проблем была картина: сколько их, сколько занимает решение, как они закрываются.
Первый честно измеренный SLA оказался 48%.
До запуска учета объективного SLA не существовало - только ощущение вечной перегрузки. Когда начали фиксировать критичные обращения - оказалось, что только 65% из них получали реакцию в тот же день. Остальные тонули в очереди или терялись полностью.
48% - это не было падением. Это была первая правда о состоянии сервиса.
Что изменили: конкретная механика
Рабочее место инженера
Заявки в системе стали сортироваться по приоритету - не по времени поступления. Старший смены получил отчет: сколько заявок у каждого сотрудника, сколько решено, сколько высоких приоритетов, среднее время на заявку. Тот же отчет - каждому сотруднику о себе и о команде.
Быстро стало видно, кто решает меньше всех или медленнее всех. Разбирался с каждым случаем отдельно. 90% - не нежелание работать. Просто не было опыта. Для них назначил кураторов - более опытных коллег. Условие простое: куратор помогает, подопечный оставляет след - пишет инструкцию, как решить эту проблему в следующий раз. Остальные 10% просто не хотели работать. Теперь это было видно. Кто-то ушел, кого-то перевели туда, где они давали больше пользы.
Роль старшего смены
Поменял режим работы - 2 через 2, по 12 часов, со смещением начала смен. Покрытие выросло до 12+ часов в сутки. В каждой смене - старший с одной задачей: приоритизировать входящий поток и вести все обращения с высоким приоритетом и выше. Прописал порядок эскалации для критичных ситуаций - кого и как уведомлять.
Закрытие обходных каналов
Это было управленческим изменением, а не технической настройкой. Директора магазинов и функции привыкли писать напрямую, подключать CEO и добиваться реакции через личный доступ. Первый чат выбирали осознанно - там было несколько директоров магазинов. Поговорили с каждым: что изменится, почему это лучше, как будет работать дальше. Проблем с негативной реакцией не было. По остальным - подготовка и информирование перед каждым закрытием.
Договорились на берегу: нет номера заявки - нет обязательства по сроку. Любое обращение в обход системы означает, что у него нет ни приоритета, ни срока, ни ответственного. Это правило закрепили не приказом, а логикой: система стала единственным местом, где заявка вообще существует.
Те, кому изменение не нравилось, приходили ко мне напрямую. Садились и разбирались, в чем конкретно проблема. Те, кто поднимал вопрос к CEO - получали от него один ответ: разберитесь, и шли ко мне. За счет подготовки сильного сопротивления не было.
Механизм эскалации поменялся. Ко мне стали приходить с номером заявки - и директора магазинов, и топы других департаментов. В начале - до 10 раз в день. К концу - 1-2 раза в неделю. Это тоже был измеримый сигнал: модель работает.
Итерационная настройка SLA
После первой недели SLA составил 63%. Те же люди, та же численность - но SLA вырос с 48% до 63% только за счет того, что заявки перестали идти к тому, кто первым взял трубку. Дальше настройка шла итерационно: анализировал, почему не укладываемся, корректировал матрицу. Через первый месяц - 76%.
Анализ закрытых заявок: 60% - не ИТ
Параллельно с работой над SLA шел второй анализ - как фактически закрываются заявки. Способ закрытия был обязательным полем: ремонт, замена, ошибка пользователя, инструкция, ошибка в программе, ошибка в данных.
Более 60% закрытых заявок лежали не в ИТ. Они были в знаниях и умениях сотрудников. Люди просто не знали, как работать с системами.
Начал отслеживать это регулярно и нашел закономерность. Каждый новый магазин создавал волну обращений - в первый месяц работы 200+ заявок. Стандартный уровень у работающих магазинов был в разы ниже. Проверили программу обучения новых сотрудников. Стало понятно почему: работе с нужными системами их не учили.
Поправили программу. Волна исчезла. После нескольких итераций новый магазин перестал отличаться по объему обращений от обычного работающего.
Это был разговор с бизнесом - не про ИТ, а про операционный процесс. Результат анализа стал основанием для пересмотра программы обучения, а не только для расширения штата поддержки.
Дальше - регулярная работа с разработкой: процедура допуска релизов, контроль обновлений. Информационный канал: новости о сбое и времени устранения, чтобы магазины не разрывали чаты в поисках ответа. Структура поддержки усложнилась - появились специализированные группы по кассам, сетям, программам и круглосуточный мониторинг 24/7. По оборудованию - регулярные обслуживания на точках, другой механизм закупки, контроль всплесков после глобальных изменений.
Разговор с CEO: как обосновать расширение штата
После первого месяца - SLA 76%, данные по 41 000+ обращениям на 500+ магазинов - я пошел к CEO.
Разговор был коротким.
Я показал: вот объем проблем по доменам. Вот что мы решаем тем же штатом сейчас - и как быстро. Вот что накапливается: заявки, которые не успеваем закрыть в SLA. Вот оценка потерь в часах простоя и деньгах по выручке - это было видно, потому что у бизнеса были данные по каждому магазину и каждому часу работы.
Вывод на цифрах был однозначным: стоимость накопленных нерешенных инцидентов перекрывала стоимость дополнительных смен. Не "ИТ просит людей" - разговор с цифрами, у которых есть очевидный вывод.
CEO внес пару правок в матрицу SLA - доработал по паре приоритетов исходя из своего понимания бизнес-критичности. И дал 4 штатные единицы. Потому что не надо было убеждать - надо было показать.
Результат за 6 месяцев
SLA рос по шагам:
- старт - 48%
- первая неделя - 63%
- первый месяц - 76%
- 6 месяцев - 99%
Доступность критичных сервисов: с 65% до 99,9%.
Объем обращений: с 41 000+ в месяц на 500+ магазинов до 6 000+. Каждый магазин - с 2,5+ обращений в день до 2,5+ обращений в неделю.
Кассовые инциденты: с 50 до 2 в месяц на магазин. Это отдельная история - про кассу как точку денег, профилактику, подменный фонд и физическое состояние кассового узла. Здесь важно другое: без единой системы, приоритетов и анализа повторов мы бы даже не увидели этот контур как отдельную проблему.
Про доступность отдельно. Рост SLA сам по себе не равен росту доступности критичных сервисов. Доступность поднялась с 65% до 99,9% потому, что из заявок начали системно вытаскивать повторяющиеся причины: оборудование, кассы, сеть, релизы, обучение, подрядчики. Поддержка перестала только тушить обращения и стала источником данных для профилактики. Это разные вещи.
Через полгода я спросил CEO: сколько раз за последний квартал его просили повлиять на ИТ-вопросы?
Он задумался. Потом сказал: не помню. Давно не просили.
Для меня это была лучшая оценка результата. Не SLA 99%, а то, что CEO перестал быть ручным маршрутизатором критичных ИТ-проблем.
Вывод
SLA не растет от давления на команду поддержки. От давления растет только выгорание.
Пока обращения живут в чатах - у поддержки нет настоящего OPEX. Есть только ощущение вечной перегрузки. Стоимость сервиса становится видна только когда каждое обращение получает категорию, приоритет, владельца, срок и причину закрытия. Тогда можно обосновать расширение штата не словами, а цифрами. Тогда можно убрать из потока целый класс проблем - как это получилось с программой обучения.
SLA вырос потому, что хаос получил архитектуру: единый вход, приоритет по влиянию на бизнес, категорию, владельца, срок, понятный способ закрытия.
Без этого поддержка - не сервис. Это очередь к тому, кто громче эскалирует. И очень часто этот человек - CEO.
Директор магазина не спрашивает номер заявки. Он спрашивает, когда снова можно продавать.
Статья написана для портала it-world.ru