Согласно исследованию Google Project Oxygen, восемь ключевых качеств хорошего менеджера включают: быть хорошим коучем; раздавать ответственность, избегая микроменеджмента; проявлять заинтересованность в успехах сотрудников, включая личные аспекты; быть нацеленным на результативность и достижение целей; обладать навыками эффективной коммуникации; помогать в карьерном росте подчинённых; иметь чёткое видение и стратегию для команды; обладать важными техническими компетенциями, позволяющими поддерживать команду. Эти качества были сформулированы после многократных опросов, анализа данных по методу «360 градусов» и интервью с уходящими сотрудниками, что позволило определить, какие характеристики наиболее существенно влияют на результативность работы подчинённых.

Целевые значения показателей ИТ-сервисов должны определяться на основе требований и ожиданий конечных пользователей сервиса. Рекомендуется провести работу по сбору этих требований через интервью, опросы или совместные встречи с ключевыми потребителями. Например, для электронной почты можно выявить, что 95% доступности является минимально приемлемым порогом, ниже которого начинаются серьезные проблемы с работой сотрудников. Целевые значения также могут быть основаны на отраслевых стандартах, исторических данных работы сервиса или бизнес-требованиях организации. После определения целевых значений их необходимо зафиксировать в SLA (соглашениях об уровне сервиса) и регулярно пересматривать, учитывая изменения в бизнес-потребностях и возможностях ИТ-инфраструктуры.

Фаза problem control (PC) включает диагностику проблемы, определение ее корневой причины и вариантов решения. Эта фаза заканчивается, когда определены возможные решения проблемы. На противоположной стороне находится фаза error control (EC), которая начинается после диагностики и включает реализацию выбранного решения, проверку его результативности и, при необходимости, контроль известной ошибки. Разделение происходит в момент завершения диагностики, когда переход к error control означает переход от поиска решения к его внедрению.

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

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

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

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

Практики управления рисками интегрируются в процесс управления проблемами, особенно в его проактивной составляющей, следующим образом: 1) Идентификация возможных событий - в процессе управления проблемами происходит выявление потенциальных проблем, которые могут привести к инцидентам. 2) Оценка вероятности и степени влияния - каждая выявленная проблема оценивается с точки зрения ее серьезности и вероятности возникновения, что позволяет приоритизировать проблемы. 3) Контроль реестра событий и актуальных оценок - ведется систематизированный реестр проблем с периодическим пересмотром их приоритетов и статусов. 4) Разработка и реализация мер по предотвращению рисков - для критически важных проблем разрабатываются проактивные меры по их устранению или минимизации влияния. Проактивная составляющая управления проблемами фактически представляет собой специфический вариант управления рисками, сфокусированный на технических и операционных рисках в сфере предоставления услуг. Эта интеграция позволяет не только реагировать на возникающие инциденты, но и предотвращать их возникновение.

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

У первой линии поддержки существуют следующие ограничения при оценке влияния инцидентов: 1) Доступны только субъективные оценки пользователя, без технической диагностики. 2) Объем диагностической информации минимален на начальном этапе обращения. 3) Пользователь может не знать о проблемах других сотрудников. 4) Сложности в объективной оценке степени недоступности функционала ('совсем не работает' против 'частично не работает'). 5) Необходимость быстро принять решение об уровне влияния, имея ограниченную информацию. Эти ограничения делают важным разработку четких вопросов для пользователя, которые позволяют максимально объективно определить влияние инцидента.