Управление проблемами запустили как отдельную функцию, а не как процесс на бумаге

Что болело

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

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

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

Результат авторы называют своим словом — «неуловимые» проблемы, которые из раза в раз перетекали из одного направления в другое, а поймать и устранить их было практически невозможно.

Что хотели получить

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

Отсюда цель: перевести практику из опциональной в обязательную и распространить на все подразделения поддержки, а не на отдельные группы.

Что сделали

Работа началась в октябре 2023 года решением департамента ИТ-поддержки переформатировать процесс целиком. Запуск — с начала 2024 года; сами участники называют это не возрождением, а фактически первым запуском.

Пилот. Взяли по две-три группы поддержки в разных подразделениях и дали одну задачу: привязывать инциденты к проблемам и заводить сами проблемы. Цель поставили измеримую — не менее шестидесяти процентов инцидентов, приходящих на эти группы.

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

Замер трудозатрат. Привязка одного инцидента к проблеме занимала около пяти минут — ровно столько же, сколько среднее время решения самого инцидента. То есть практика удваивала стоимость обработки обращения.

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

Раскатка. Только после этого привязку распространили на остальные подразделения поддержки.

Работа вокруг проблемы разведена по ролям:

Отдельно устроена работа с известными ошибками. Известная ошибка здесь определена честно и по-деловому: это проблема, устранение которой обойдётся компании дороже, чем владение ею. Опасность такого определения авторы понимают и называют вслух — иначе у сотрудников велик соблазн не искать первопричину, а просто присвоить проблеме новый статус.

Поэтому заведён комитет по проблемам, раз в две недели. Чтобы вынести проблему на комитет, координатор обязан сначала доказать, что сделано всё возможное: решение нельзя автоматизировать и передать на первую линию, а инцидент нельзя своевременно ловить мониторингом. И получить согласования руководителей первой линии, оперативной поддержки и поддержки корпоративных сервисов. Признанные известные ошибки регулярно перепроверяют — например, если вендор возобновил поддержку в стране и готов исправить.

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

Чем автоматизировали

Систему в источнике не назвали ни разу. Сказано только «существующая ITSM-система». Поэтому переносится отсюда устройство работы, но не выбор инструмента, и карточки решения у этого проекта в нашем каталоге нет.

Зато названы два собственных инструмента, написанных внутри команды аналитиков на Python.

Проверка корректности привязки. Когда привязку инцидентов к проблемам сделали метрикой, встал вопрос: как убедиться, что команды привязывают именно порождённые проблемой инциденты, а не просто похожие. Ручную проверку пропилотировали и отказались — трудозатраты оказались огромными. Ждать нейросеть было долго. Руководитель команды аналитиков сделал инструмент, который выбирает привязанные инциденты и проверяет их по редактируемому справочнику ключевых слов, а совпадения переводит в проценты. Сравнение с полностью ручной операторской работой дало корректность восемьдесят процентов и выше.

Калькулятор стоимости владения проблемой. Появился после встреч с бизнес-подразделениями, на которых стало ясно, что влияния и числа инцидентов для оценки мало. Консольная утилита принимает номера проблем и отдаёт число связанных инцидентов и заданий, суммарное время в часах и количество FTE на содержание обращений — то есть величину, которая переводится в деньги.

Отчётность живёт на внутреннем портале «Карта здоровья» — общем портале ИТ-отчётности компании, куда добавили и раздел по управлению проблемами: число открытых и решённых проблем, основания регистрации, динамика, покрытие, а также детализация по направлениям. Отчёты под разовые запросы строятся отдельно на PowerBI.

Что получилось

Главная названная цифра: база инцидентов сократилась более чем на двести тысяч обращений.

Кроме этого появилось то, чего не было вовсе: возможность выявлять проблемы, оцифровывать их и прогнозировать срок решения. Бизнес-подразделения получили отчёты, по которым видят топовые проблемы в своей зоне ответственности и на их основании помогают приоритизировать доработки. Департамент ИТ-поддержки видит топ проблем по каждому управлению.

Формулировка авторов про бизнес стоит того, чтобы её привести: он теперь не просто догадывается, а буквально видит и отслеживает проблемные места и системы.

Что не получилось и где было тяжело

Этот раздел в источнике есть — редкий случай для публичного рассказа компании о себе.

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

Корректность привязки — восемьдесят процентов. Инструмент проверки не даёт стопроцентного результата, и авторы этого не скрывают. Значит, примерно каждая пятая привязка может быть неверной. Уровень принят сознательно как рабочий, но при чтении отчётности это надо держать в голове.

Цена практики видна на замере. Пять минут на привязку при пяти минутах на решение инцидента — это удвоение стоимости обработки обращения. Доработка системы часть этой цены сняла, но насколько именно, в источнике не сказано.

Чего в источнике нет совсем: бюджета, численности поддержки целиком, сроков по этапам и того, какая доля инцидентов привязывается сейчас — названа только цель пилота в шестьдесят процентов.

Что отсюда забрать

1. Пилот с измеримой целью, а не приказ по компании. Две-три группы, одна задача, планка в шестьдесят процентов и встречи дважды в неделю. Раскатка — только после того, как замечания собраны и система доработана.
2. Замерьте цену практики до раскатки. Пять минут на привязку против пяти минут на решение — это тот аргумент, с которым идут дорабатывать инструмент. Без замера разговор сводится к «неудобно».
3. Комитет по известным ошибкам. Без органа, который решает, что признать известной ошибкой, статус превращается в способ закрыть тяжёлую проблему, не разбираясь. Требование доказать, что решение нельзя автоматизировать и нельзя поймать мониторингом, — рабочий фильтр.
4. Перепроверяйте известные ошибки. Причина, по которой проблему не устраняли, со временем исчезает: меняется вендор, цена, обстоятельства.
5. Роли в смежных подразделениях под единым методическим началом. Способ охватить все направления, не собирая всех в один отдел.
6. Считайте стоимость владения проблемой в деньгах. Влияния и числа инцидентов бизнесу мало; часы и FTE переводятся в бюджет и делают приоритизацию разговором на общем языке.

На какую зрелость это тянет

По PRBУправление проблемами — третий уровень с движением к четвёртому. Порядок описан и применяется во всех подразделениях поддержки, роли выделены, есть орган принятия решений и регулярная отчётность. Это уверенный третий.

К четвёртому тянет наличие показателей, по которым практикой управляют: покрытие привязки, число новых инцидентов на проблему в неделю, стоимость владения в часах и FTE. Но сами авторы говорят, что покрытие ещё неполное, а качество оценки ресурсозатратно, — то есть измеряют не всё и не устойчиво.

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