Привет, Хабр! Меня зовут Сергей. В X5 Tech я отвечаю за поддержку системных сервисов магазинов, обновлений и аналитику на уровне второй линии поддержки. Примерно с начала 2024 года у нас стартовала масштабная инициатива по реинкарнации Problem Management. Хотя уже сейчас понятно, что это даже не реинкарнация в прямом понимании этого слова, а фактически запуск.
Я давно (с 2011 года) работаю в X5. За это время успел побывать в множестве разных ролей от системного администратора до бизнес-архитектора. И могу сказать, что большую часть этого времени Problem Management у нас был в том или ином виде. Мне удалось посмотреть и поучаствовать в этом процессе в разных амплуа – от человека, который со стороны поддержки ИТ проблемы регистрирует, до человека, который их решает. В текущей активности я принимаю непосредственное участие в создании и развитии процесса Problem Management, формировании стратегии, а также отвечаю за работу и развитие роли Problem аналитиков. Что это за ребята и чем они занимаются – я расскажу в статье.
Хочу поделиться своим опытом с позиции человека, который сейчас принимает непосредственное участие в создании, становлении и развитии сложного и очень важного процесса управления проблемами в X5 Tech. Надеюсь, наш кейс будет полезен всем, кто развивает направление Problem Management у себя, а также тем, кто только планирует создание такой функции или размышляют над целесообразностью его внедрения.
Для начала давайте определимся с терминами:
Problem Management — это управление проблемами. Оно заключается в поиске первопричин инцидентов, которые возникли по ИТ‑услугам, а также работе с ними, управлении их жизненным циклом.
Проблема — это причина одного или нескольких инцидентов. Пока её не устранить, инциденты будут продолжать возникать. Также проблемой мы называем совокупность инцидентов, причина которых неизвестна, а следствие – налицо.
Немного предыстории
Как я писал выше, Problem Management существовал в Х5 издавна, но, так скажем, в зачаточном состоянии. Было несколько попыток полноценно развить его, благодаря чему направление обросло документацией, сопутствующими процессами и функциями. Однако охват не превышал 3% от всех поступающих инцидентов, так что будем откровенны: да недавнего времени Problem Management в Х5 был опциональным процессом.
Отрывочные данные по причинам возникновения проблем копились у разных людей: в Еxcel, блокнотах, презентациях. Огромное количество горячих проблем устранялось в рамках bug-фикса, по следам аварий каждый раз составлялся план по их недопущению. Но в реальности ни о каком управлении проблемами речи не шло, ведь решение инцидента лежало в зоне ответственности конкретной группы специалистов, о нём не было известно никому более, а вдобавок оно ещё очень редко имело цифровой след.
Таким образом мы получали «неуловимые» проблемы, которые из раза в раз перетекали из одного направления в другое, а поймать их и устранить было практически невозможно.
В таком состоянии Problem Management находился с 2017 года и до прошлого года. Им по мере сил занимались лишь два менеджера, параллельно выполняя другие задачи своего подразделения. Централизованный подход к процессу не просто витал в воздухе, а стал жизненно необходимым в компании.
Стало ясно, что так больше не может продолжаться: нам слишком дорого стали обходиться повторяющиеся инциденты, а эффективные решения для их устранения требовали в том числе статистических данных. И кроме того, мы осознали, что не можем позволить себе и дальше расширять штат для решения всё возрастающего количества инцидентов. А растёт оно атвоматически с ростом количества наших магазинов. Поэтому в октябре 2023 года департамент ИТ-поддержки Х5 Tech взялся за процесс всерьёз: было решено полностью переформатировать его и внедрить Problem Management повсеместно.
Как внедряли
Для начала мывзяли по 2–3 группы поддержки в разных подразделениях нашего департамента и дали им одну задачу: привязывать инциденты к определённым проблемам и фиксировать эти проблемы. Целью поставили привязать не менее 60% всех инцидентов, падающих на эти группы.
Тут надо отдельно сказать, как инцидент привязывается к проблеме.
Если инцидент простой, то для него найдётся типовое решение, и его легко будет отнести к конкретной проблеме — здесь вопросов нет. Но бывают инциденты посложнее, их не так просто сразу же классифицировать. Тогда их крутят, вертят, раскладывают на составляющие, сопоставляют то с одной проблемой, то с другой. В общем, целый детектив получается.
К примеру, приходит обращение от магазина о том, что на какой-то конкретной кассе магазина не взвешивается товар или не работает кассовая клавиатура. Тут в целом всё понятно и каких-то разночтений быть не может. Инцидент легко поддаётся корректной идентификации, дальнейшему решению и привязке к проблеме.
И второй пример — обращения о том, что на кассах не продаётся конкретный товар. Тут всё сложнее. Причин, по которым такая проблема может возникнуть, масса: от плохо читаемого штрих-кода до проблем со связью касс с сервером или непрогруженной карточки товара. Здесь требуется более детальная диагностика, зачастую с привлечением нескольких групп поддержки. И привязка к проблеме возможна только после установления причины обращения.
Или, к примеру, магазин жалуется на несвоевременно поступившие данные по заказам. Тут тоже масса вариантов: от всё тех же проблем со связью до отработавшего с опозданием задания по выгрузке.
Через какое-то время группы стали встречаться дважды в неделю и обсуждать насущное: насколько удобна для наших целей существующая ITSM-система (система работы с инцидентами, проблемами, конфигурациями и т. д.), всем ли понятны принципы заведения проблем и привязки инцидентов, сколько усилий прикладывается, чтобы выполнить задачу. В целом привязка инцидента к проблеме занимала около пяти минут – столько же, сколько и среднее время его решения! Много, конечно.
Поэтому дальше ребята собрали все замечания к системе и выкатили команде развития задачи на доработки. И месяца через два они были воплощены в жизнь.
Например, стала быстрее открываться вкладка «Открытие проблемы», а в самой этой вкладке список проблем стал отражаться в удобном формате, что снизило время поиска конкретной проблемы. Ещё в карточке проблемы появилось поле, в котором видно количество инцидентов, зависимых от массового. И ещё много других «плюшек», сделавших работу специалистов удобнее.
В общем, результаты, полученные после всего вышеописанного, вышли вполне соответствующими ожиданиям. Поэтому было решено начать привязывать инциденты к проблемам и в остальных ИТ-подразделениях поддержки.
Как работаем с проблемой
Понятно, что привязка инцидентов к проблеме не может быть самоцелью. Сейчас расскажу, как мы работаем и планируем работать с инцидентами в новой парадигме.
Всё просто. Сотрудник поддержки получает инцидент и закрывает его временным решением (гасит пожар, так сказать). Простой инцидент закроется типовым решением, для более сложного придётся поискать решение посерьёзней. Далее инцидент привязывается к проблеме, а уж над ней работают несколько человек:
Координатор — на основании данных об однотипных инцидентах выявляет проблему, формулирует её название и описание и регистрирует карточку; описывает work around; инициирует первичную диагностику; координирует все работы, направленные на решение проблемы.
Сотрудники поддержки — связывают инциденты с проблемами; применяют описанные в проблемах временные решения.
Аналитик — верифицирует карточки проблем; готовит статистическую отчётность по проблемам с наибольшим влиянием.
Тех. владелец, тех. эксперты — люди, которые а) ищут наиболее оптимальное временное решение б) находят корень проблемы и предлагают способ устранения.
На будущее же план работы с проблемой более амбициозный. Мы рассчитываем, что она будет формироваться и дополняться автоматически, на базе привязанных инцидентов, с минимальными трудозатратами. А аналитики и тех. эксперты станут оценивать, возможно ли: а) передать исполнение временного решения на первую линию поддержки б) мониторить возникновение инцидентов по данной проблеме в) автоматизировать временное решение.
Известная ошибка
Про известную ошибку и работу с ней надо упомянуть отдельной, так сказать, строкой.
Известная ошибка — это что? Это проблема, про которую мы знаем, но отчего‑то не устраняем. Отчего? Причин может быть несколько, но все они в итоге сводятся к одной: устранение обойдётся компании дороже, чем владение проблемой.
Нельзя, однако, признавать известной ошибкой любую проблему, иначе у сотрудников будет велик соблазн не искать первопричины инцидентов, а просто присваивать проблеме новый статус — ошибки.
Именно поэтому был организован комитет по Рroblem Management (или Комитет по проблемам), который проходит регулярно — раз в две недели.
Процесс выглядит следующим образом. Координатор, видя, что у него есть потенциальная известная ошибка, для начала должен убедиться в том, что для её устранения сделано всё возможное:
решение невозможно автоматизировать и передать на первую линию;
инцидент, вызванный проблемой, невозможно своевременно отлавливать с помощью мониторинга.
Для этого координатор получает согласования руководителя первой линии поддержки, оперативной поддержки и поддержки корпоративных сервисов и аналитики. И с полученными согласованиями бодро заявляется на комитет, где рассказывает, почему вот эту и вон ту проблемы нужно признать известными ошибками.
Кстати, на этом история не заканчивается. Известные ошибки регулярно перепроверяют: вдруг появилась возможность устранить её и сэкономить компании денег? Например, вендор возобновил поддержку в нашей стране и готов всё поправить без ущерба для бюджета Х5.
Добавленная ценность процесса, или аналитики проблем
Особняком стоит работа аналитиков проблем, про неё надо рассказать отдельно.
Отмечу не совсем стандартный, по крайней мере для нас, кейс с сотрудниками. Направление Problem-аналитики, как я писал в самом начале, находится у меня в подразделении. Сейчас оно включает в себя руководителя команды и двух сотрудников. При этом на второй линии поддержки сейчас в этой роли у нас работают 8 человек!
Как так получилось? В какой-то момент мы поняли, что текущим составом не сможем в полной мере и с достаточной степенью качества охватить все проблемы всех направлений. Обсудив это с коллегами-руководителями смежных подразделений, пришли к заключению, что хотим попробовать развить и расширить это направление через создание аналогичных ролей у них, но работать все будут по единым стандартам и под единым началом руководителя команды.
Таким образом у нас появились выделенные роли во всех направлениях, включая экспертов поддержки (люди, которые вовлекаются в проектные активности и начинают работать над поддержкой и Problem Management на самых ранних этапах, фактически ещё до передачи проекта\продукта в поддержку), которые структурно числятся в своих подразделениях, но функционально работают под началом находящегося у меня руководителя команды Problem-аналитиков. Такой вот трудовой франчайзинг получается =)
Теперь давайте разберёмся, кто же всё-таки такие аналитики проблем?
Аналитики проблем — это те люди, которые, помимо прочего, рассматривают весь пул проблем, выявляют наиболее критичные и подсвечивают их заинтересованным подразделениям, а также делают срезовые выгрузки, чтобы показать коллегам, на что следует обратить внимание. Например, отчётность для бизнес-подразделений помогает им приоритизировать задачи и выделять бюджет на необходимые доработки.
Работа аналитиков создаёт дополнительную ценность процессу Problem Management: они автоматизируют решения (об этом ниже), помогают сократить сроки решения проблем – благодаря этим мерам снижается стоимость владения проблемой и в целом негативных последствий от неё становится меньше.
Теперь про основные направления их работы.
1. Верификация карточек проблем
Благодаря регулярной верификации мы можем быть уверены, в том, что:
по всем проблемам корректно заполнены ключевые поля (наименование, описание, статус и т. д.);
проработаны и описаны work around;
выполнены или находятся в работе основные задачи, сокращающие трудозатраты и стоимость поддержки (это задачи по автоматизации и роботизации решений инцидентов, а ещё — по передаче инцидентов на первую линию поддержки).
Что нам это даёт в конечном счёте? Эффективный Problem Management! Судите сами:
Мы можем верно приоритезировать задачи по решениям проблем. Потому что, как говорилось в одной сказке: «Не может царь думать о каждом — царь должен думать о важном». Другими словами, первыми должны решаться проблемы с наибольшим влиянием.
У нас есть разносторонняя, правдивая статистика, которая показывает: сколько есть проблем, решение инцидентов по которым не автоматизировано; у каких из них наибольшее количество новых инцидентов в неделю; сколько проблем, по которым решение инцидентов невозможно передать на первую линию, тем самым сократив их стоимость и т. д.
Мы можем своевременно оценивать необходимость декомпозировать проблемы, что, в свою очередь, влияет на скорость выявления корневых причин, а следовательно, и на общий срок их жизни.
2. Отчётность
Это основное направление для аналитиков. Его условно можно разделить на два стрима.
Первый — регулярные отчёты для заказчиков. Они рассчитаны на то, что коллеги, с их высокой нагрузкой и безумным графиком, смогут сравнительно быстро и просто получать актуальную информацию по состоянию проблем в разрезе своих подразделений:
Для бизнес‑подразделений. Здесь аналитики играют вспомогательную роль, ибо ни бюджетами, ни бэклогом задач команды разработки не управляют. Благодаря отчётам бизнес‑подразделения видят топовые проблемы в их зоне ответственности и уже на основании этих данных помогают приоритизировать их устранение.
Для департамента ИТ‑поддержки. Увидев топ проблем по своему управлению, каждый начальник приложит максимум усилий, чтобы быстро и эффективно устранить их.
Второйстрим — это отчёты под конкретные запросы, построенные на PowerBI. В основном, речь про отчётность, которая не реализована в Карте здоровья по разным причинам.
*Карта здоровья – это единый внутренний портал ИТ-отчётности для визуализации здоровья продуктивных ИТ-сервисов компании. С недавнего времени в нём реализована и отчётность по направлению Problem Management. На портале мы можем как посмотреть общую статистику по направлению (количество открытых и решённых проблем, статистику по основаниям для регистрации, динамику, покрытие и т. д.), так и более детальную: например, информацию по проблемам отдельного направления, детализацию по проблемам (даты регистрации, приоритет, количество связанных обращений, ФИО координатора), детализации в заданных периодах и пр.
Визуально это выглядит так:
Возможно, у направления заказчика узкая специфика, а может, запрошенный отчёт настолько сложен по построению, что его можно сравнить с разработкой, при этом он не нужен заказчику на регулярной основе. Заказчиками, в данном случае, являются смежные отделы поддержки. Под узкой спецификой тут понимается кейс, когда отчёт не имеет под собой какого-то массового запроса или потребности. Поэтому его публикация на общем портале не выгодна (т. к. тратятся общие ресурсы и трудозатраты на разработку).
3. Автоматизация
Автоматизация не являлась и, пожалуй, по сей день не является зоной ответственности рroblem-аналитиков. Но ребята понимают, что обладают нужными компетенциями и поэтому стараются их использовать.
Покажу на примере.
Вот решили начать считать количество привязанных к проблеме инцидентов, раздали соответствующие указания командам, обрадовались, что делаем нужное дело. А после задумались. Как проверить, что ребята из команд не ошибаются и привязывают к проблеме именно те инциденты, которые порождены ею, а не какие‑то «похожие»? Ведь привязка — метрика ценная, важно, чтобы она была максимально корректной.
Поначалу было два варианта:
Проверять всё вручную. Успели даже пропилотировать этот вариант, чтобы оценить трудозатраты. И они оказались огромны.
Призвать на помощь нейросеть. Но этой помощи пришлось бы слишком долго ждать.
А надо было сделать всё быстро и без безумных нагрузок на людей.
Пока рабочая группа размышляла, руководитель команды аналитиков – очень увлечённый своим делом человек — буквально факультативом сделал инструмент на Рython, который позволяет проверять привязанные к проблеме инциденты по редактируемому справочнику. Результаты совпадений подсчитываются и переводятся в проценты.
Суть работы инструмента — в автоматизированной выборке привязанных к проблеме инцидентов и проверке их по ключевым словам, которые предлагает сама система на основе анализа инцидентов и который можно отредактировать вручную.
Разумеется, это не 100%-ный метод, но все наши тесты показали, а тестировали мы его, в том числе, сравнивая с полностью ручной операторской работой, что процент корректности 80% и более. И в целом, на текущий момент это для нас то, что нужно!
Второй яркийпример — создание инструмента, с помощью которого оценивается стоимость владения проблемами. Аналитики разработали его после встреч с бизнес-подразделениями, в ходе которых пришло озарение: нужно расширять критерии оценки проблемы. Важно не только учитывать влияние и количество инцидентов, но и среднюю стоимость поддержки по этим инцидентам, и общее количество времени, и FTE, затраченных на поддержку.
В итоге мы получили некую консольную утилиту, Рython скрипт, калькулятор, если угодно, которому на вход мы даём номера интересующих проблем. А на выходе получаем данные по общему количеству связанных инцидентов и заданий, а также сумму времени (в часах), затраченного на их решение, и количество FTE, затрачиваемое на «содержание» обращений, которые легко переводятся в стоимость.
Чего достигли
В первую очередь, мы получили возможность выявления проблем, их оцифровки во всех смыслах этого слова и появления прогнозируемого трека их решения. Что в совокупности, в итоге, даёт нам возможности оптимизации работы поддержки, сокращения стоимости и количества обращений, повышение стабильности систем и т. д.
База инцидентов у нас сократилась более чем на 200 тысяч обращений, а значит, компания может оптимизировать работу поддержки и сделать её гораздо эффективней.
Бизнес, в свою очередь, теперь не просто «догадывается», а буквально видит и отслеживает все «особо проблемные места» и ИТ-системы, что позволяет ему более эффективно управлять доработками.
Разумеется, мы понимаем, что де факто – это начало длинного пути. Впереди ещё много всего, что нужно поделать и оптимизировать. Видится, что Problem Quality Management должен стать менее ресурсозатратным (за счёт автоматизации), покрытие более обширным, должно появиться эффективное взаимодействие с процессом управления событиями, качество должно оцениваться желательно с использанием ИИ и много чего ещё.
Сейчас мы активно работаем над созданием стратегии по развитию Problem Management, в которую непременно будет включено всё, что позволит нам сделать это направление ещё более полезным и эффективным.