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

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

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

Бизнес-руководство лучше воспринимает метрики, напрямую связанные с их KPI: финансовые последствия, влияние на клиентов, риски штрафов. Например, вместо «среднее выполнение SLA 85%» можно указать «потенциальная экономия 5 млн руб. в год при доведении показателя до 95%». Для визуализации подходят термометры (как в стратегических планах) или светофоры, где зона красного цвета соответствует уровню, при котором возникают штрафные санкции по договорам. Важно избегать ИТ-жаргона (например, «uptime» заменить на «время работы системы»).

После начала предоставления услуг (Service Operation) BRM решает несколько важных задач. BRM должен убедиться, что заложенная ценность извлекается – заказчик достигает необходимых результатов и его ожидания оправдываются. BRM отвечает за мониторинг удовлетворенности заказчика, выявление и сглаживание острых углов. BRM также управляет процессом обработки жалоб, обеспечивая, что ни одна жалоба не остается без внимания, и каждая из них получает ответ. BRM анализирует жалобы как сигналы о явных или скрытых проблемах и организует процесс их устранения. BRM отвечает за предоставление отчетности заказчику и проверку соответствия формальным требованиям, обеспечивая прозрачность процесса эксплуатации услуги.

Автоматические отчёты требуют ручной обработки из-за сложности типов лицензий и их условий использования. Сканеры сети не определяют тип лицензии (например, на процессор, ядро или подключение), а также не учитывают коэффициенты (например, одна лицензия покрывает два процессора). Поэтому человек должен проставлять тип лицензии вручную, чтобы система могла корректно рассчитать охват лицензиями установленного оборудования. Также требуется ручное сопоставление названий ПО из данных сканера с реальными продуктами, так как автоматическое распознавание часто бывает неточным.

Для обеспечения высокого качества решения инцидента необходимо контролировать несколько ключевых компонентов. Прежде всего, важно следить за долей инцидентов, которые были возвращены на доработку, так как это указывает на то, насколько качественно и окончательно были устранены инциденты с первой попытки. Также необходимо уделять внимание количеству коммуникационных итераций между пользователем и поддержкой, стремясь к тому, чтобы инциденты решались с первого обращения (показатель FCR). Кроме того, важно обеспечивать необходимый и достаточный уровень прозрачности процесса решения, включая своевременное информирование пользователя о ходе работ и проактивное уведомление о любых изменениях в статусе инцидента. Качество коммуникации, включая профессиональный этикет и ясность передаваемой информации, также является важным компонентом.

Термин 'хозяин' лучше подходит для обозначения Service Owner в русскоязычном контексте, потому что у него есть переносное значение 'полновластный распорядитель', что гораздо точнее отражает суть роли. Service Owner не просто формально владеет услугой, но активно управляет, распоряжается ресурсами и принимает решения в интересах бизнеса. В отличие от 'владельца', который может ассоциироваться только с правом собственности, 'хозяин' передает идею полноценного управления и ответственности за результат.

Дополняющая услуга становится частью основной услуги, когда она перестаёт восприниматься как изюминка и превращается в обязательное требование со стороны заказчика. Например, если ранее бесплатный Wi-Fi был дополнением к гостиничному сервису, то сегодня клиенты ожидать его в каждой гостинице. В таком случае поставщик услуг должен будет включить его в базовый пакет и соблюдать стандарты качества, как для любой основной услуги.

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