Управление ИТ-услугами (ITSM, IT Service Management) на бумаге часто выглядит четкой, понятной картинкой. Вы определяете процессы, выбираете правильные инструменты, приводите всё в соответствие с фреймворком, таким как ITIL, и начинаете работу. Но когда приходит время воплотить всё это на практике, всё быстро усложняется. Согласно наблюдениям экспертов, большинство организаций сталкиваются с одними и теми же точками трения; некоторые ожидаемы, другие — нет.
Этим сложностям статья и посвящена — восемь самых распространенных проблем и применимые на практике способы, как с ними справиться (а не только теория).
Давайте пройдемся по ним одна за другой.
Некоторые из этих проблем появляются на раннем этапе выстраивания всей системы управления, в то время как другие возникают, когда система уже работает. В обоих случаях они, как правило, отражают разрыв между тем, как происходит управление ИТ, и тем, как должны работать лучшие практики ITSM.
Раннее распознавание этих проблем упрощает корректировку курса, прежде чем их станет сложнее исправить.
1. Неясные роли и обязанности
Даже когда процессы хорошо задокументированы, часто можно увидеть, что работа над задачей застревает из-за проблем с владельцем. Задачи простаивают без внимания, потому что никто не уверен, кто за них отвечает. Хуже того, несколько человек могут предполагать, что кто-то другой их выполняет.
Это обычно происходит, когда роли определены расплывчато или когда обязанности меняются, но коммуникация об этом не происходит должным образом. Например, эскалации инцидентов могут останавливаться, если служба поддержки не знает, какая группа второй линии должна принять их на себя, или если нет четкой матрицы RACI для утверждений изменений.
Часто к таким сбоя приводят отсутствие открытой коммуникации и слабые отношения часто. Если люди избегают решения напряженности или не делятся информацией прозрачно, процесс не выдержит. Команды должны открыто разговаривать, работать через конфликты и поддерживать четкие связи.
Чтобы избежать этого, убедитесь, что у каждой услуги, процесса и задачи есть назначенный владелец. Четко распределите обязанности между функциями и пересматривайте их, когда ваша организационная структура меняется. Обязательно фиксируйте распределения ролей во внутренних регламентах и информируйте, сообщайте командам, при необходимости проводите внутренние обучения. В ITSM-системе, которую вы используете для автоматизации работы, предусмотрите атрибут владельца, ответственного для каждого объекта управления.
2. Плохая категоризация и маршрутизация запросов
Если объекты (запросы на обслуживание, инциденты, события, согласования и т.п.) попадают в неправильную очередь, прогресс останавливается. Когда это происходит? Прежде всего – когда нет единого понимания, как мы, как ИТ-поставщик работаем: какие услуги предоставляем, кому, на каких условиях, какие компоненты нужны для предоставления услуг и как они взаимосвязаны, и соответственно, кто вовлечен в ту или иную деятельность.
Таким образом, первичная задача – убедиться, что мы хорошо сами понимаем свои услуги. Например, понимаем ли мы перечень наших услуг и круг потребителей – это вопрос про каталог услуг.
Если у нас каталог услуг слишком широк, плохо структурирован, нет четкого понимания границ услуг, то нужно заняться улучшениями в этой области. Ведь каталог услуг — это не просто список формальность, а инструмент, помогающий нам находить общий язык и с заказчиком, и с пользователями, и между нашими сотрудниками.
Еще один вопрос – про взаимосвязи наших компонентов. Если мы не понимаем, как устроены наши услуги, если нет четкой картины, как связаны компоненты между собой, нужно думать об управлении конфигурациями. Нужно понять, какая информация о компонентах и кому нужна, продумать модель данных базы конфигурационных единиц (CMDB), определить все важные связи между компонентами, а после – заполнить базу информацией и поддерживать ее в актуальном состоянии.
Без всего этого любая автоматическая маршрутизация будет построена на шатком фундаменте.
Таким образом, проблема плохой маршрутизации — это лишь симптом. Лечить нужно причину: отсутствие целостного взгляда на свои услуги.
3. Непоследовательное использование платформы ITSM
Даже если в организации есть правильный инструмент, он не будет хорошо работать, если люди используют его непоследовательно или вообще обходят его. Одна команда может регистрировать инциденты, ЗНО, проблемы, изменения в платформе, в то время как другая предпочитает побочные каналы, такие как чаты в мессенджерах или электронную почту. Это создает слепые зоны и делает отчетность почти бесполезной.
Инструменты ITSM приносят ценность только тогда, когда используются как центральный хаб. Это не означает введение строгих правил без гибкости, но это требует установления ожиданий и предоставления обучения.
Постепенно формируйте привычки использования, интегрируя платформу в повседневные рабочие процессы обслуживания. Подчеркивайте, как это приносит пользу: будь то за счет более быстрого времени реакции, сокращения переключения контекста, полноты необходимой информации или более четкой коммуникации.
4. Слабое управление знаниями
Слишком многие команды полагаются на неявные знания в головах сотрудников, даже когда база знаний технически доступна. Если документация устарела, ее трудно искать или ее не поддерживают те, кто выполняет работу, ее игнорируют.
Эта проблема становится более заметной во время ввода в должность, передач смены или текучки персонала, не важно, вызванной ли карьерным ростом или увольнениями. Ценный контекст теряется, и команды тратят время на повторное открытие решений, которые уже были известны.
Управление знаниями должно быть живой частью ваших процессов ITSM, а не второстепенной деятельностью. Поощряйте сотрудников документировать свои шаги, пополнять информацию в случаях, когда становится известно что-то новое, планируйте повторяющееся время для проверки и обновления статей. Отслеживайте, какие знания используются, и выявляйте пробелы на основе повторяющихся ситуаций нехватки информации.
5. Отсутствие согласованности с бизнесом
Сервисные команды часто сосредотачиваются на SLA, объемах заявок и времени решения. Хотя это допустимые индикаторы, они не всегда отражают то, что действительно нужно бизнесу. Например, достижение целевых показателей SLA может хорошо выглядеть на дашборде, но все равно оставляет конечных пользователей разочарованными, если ключевые проблемы не расставлены по приоритетам правильно.
Часто в ИТ мы склонны смотреть на деятельность с точки зрения так называемого транзакционного подхода. «Как прошел этот инцидент?» «Как был выполнен этот запрос?» « «Выполнили ли мы наши цели по доступности?» Но при этом мы не смотрим комплексно на общее впечатление от наших услуг с точки зрения заказчиков и пользователей. А то, как потребители воспринимают ИТ-услуги, их удовлетворенность, зависит не от одной транзакции. Она основана на множестве транзакций, она формируется как ощущение, довольны ли они ИТ-услугами или недовольны, и конечно, она субъективна.
Чтобы оставаться согласованными, привлекайте бизнес-стейкхолдеров к обсуждениям приоритетов, определений услуг и критериев успеха. Не просто отчитывайтесь о производительности — связывайте это с влиянием на бизнес. Это может означать, например, демонстрацию того, как простой повлиял на выручку или как автоматизация запроса сократила время ожидания при онбординге нового сотрудника.
6. Реактивное управление изменениями
Управление изменениями часто формализуется достаточно поздно, не в первую очередь. Команды изначально обрабатывают изменения неформально или задним числом. Но по мере роста систем и вовлечения большего числа команд риски увеличиваются. Одно некорректно прокоммуницированное или проведенное обновление, не учитывающее все заинтересованные стороны, может вызвать простой услуги, который массово затронет пользователей.
Чтобы предотвратить это, управление изменениями следует вводить рано и масштабировать постепенно. Это не означает, что с первого дня вам нужны полномасштабные заседания CAB (совета по изменениям). Начните с простого процесса для проверки, документирования и планирования изменений в общей системе. Затем развивайте его, добавляя потоки утверждений, оценки воздействия или шаблоны стандартных изменений по мере развития вашего окружения.
7. Плохое разделение инцидента и проблемы
Управление инцидентами и управление проблемами служат разным целям, но часто обрабатываются одинаково. В результате временные исправления регистрируются как решения, а коренные причины никогда не устраняются.
Их легко спутать, когда есть давление с целью быстрого решения заявок. Но долгосрочная стабильность зависит от выявления шаблонов и устранения основных причин. Например, если один и тот же инцидент происходит повторно, вероятно, существует проблема, которая требует анализа, а не очередного обходного решения.
Хорошей практикой является определение критериев для того, при каких условиях во время или после случившихся инцидентов должно запускаться расследование проблемы. Например, если произошел значительный инцидент или при обзоре ежемесячного отчета о повторяющихся инцидентах. Со временем вы также сможете перейти к проактивной работе с проблемами, чтобы не дать инцидентам случиться даже в первый раз.
8. Отчетность, которая либо слишком поверхностна, либо слишком сложна
Отчеты часто попадают в две крайности: это либо базовые метрики с малой возможностью сделать на основе их корректные выводы о том, как в целом работает ИТ и что стоит улучшать, либо перегруженные дашборды, которые никто на самом деле не читает. Оба результата приводят к одному и тому же: решениям, основанным на неполной или неправильно понятой информации.
Помогает сначала спросить: «Кто читает отчет и что ему от него нужно?» Агенту могут потребоваться тренды размера очереди. Менеджера может больше волновать пропущенные SLA и возраст бэклога. Руководители обычно хотят краткие отчеты с бизнес-контекстом.
Создавайте разные представления отчетов для разных аудиторий и регулярно пересматривайте их. Привязывайте отчетность к действиям — что означают цифры и что, понимая их, стоит делать дальше.
В заключение
Построение хорошо работающей системы управления ИТ-услугами — непростая задача, даже при наличии хороших инструментов и фреймворков. Большинство проблем, которые мы здесь рассмотрели, проистекают не из технической сложности, а из рассогласованности между людьми, процессами и приоритетами. Хорошая новость заключается в том, что эти проблемы решаемы.
При четком владении, последовательных практиках и фокусе на практических результатах управление ИТ-услугами может начать приносить реальную ценность. Помните, что ITSM — это не про закрытие заявок, а про улучшение услуг.
На основе статьи (англ.)
