Важно получать обратную связь от пользователей с умеренной удовлетворенностью, так как именно они составляют большую часть аудитории и их опыт наиболее близок к среднему уровню качества обслуживания. Если система обратной связи настроена так, что собирает только крайние оценки (очень довольные или очень недовольные), организация не сможет понять, насколько ее услуги удовлетворяют основную массу клиентов. Это приведет к искаженной картине и неправильным решениям при улучшении услуг. Баланс всех типов отзывов дает более полное представление о реальном состоянии дел.

Изменение системы поощрений с фокуса на выходах на фокус на результатах кардинально влияет на поведение команд. Например, вместо премирования за 99,9% uptime сервера (выход), который может не учитывать реальный пользовательский опыт, поощрения привязываются к результату: «95% пользователей не сталкиваются с задержками > 2 сек». В компании Ford замена KPI «количество строк кода» на «снижение времени сборки авто» повысила эффективность ИТ на 200%. Такие изменения стимулируют команды думать о конечной ценности своей работы, а не просто о количестве выполненных задач или технических показателях.

Ответственность за Outcome лежит на обеих сторонах. Поставщик должен предоставить качественный и подходящий Output, а потребитель — использовать его правильно и вовремя. Например, в случае дня рождения пекарня предоставляет торт (output), но родители должны его купить, поставить на стол и устроить праздник, чтобы дети были счастливы (outcome). Если одна из сторон не выполняет свои обязательства, outcome достигнут не будет.

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

Термин Service Capacity Management предлагается заменить на System Capacity Management, поскольку понятие «услуга» может быть связано с разными уровнями: бизнес-процессом, ИТ-системой или ресурсом. Если ИТ-услуга определена как обеспечение бизнес-процессов, то управление мощностью должно относиться к бизнесу, а не к услуге как таковой. Аналогично, если услуга ассоциируется с ИТ-системой, то правильнее говорить об управлении мощностью системы, а не услуги.

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

Основная проблема классификации услуг по модели ITIL V3 в современных условиях заключается в том, что жесткое разделение на бизнес-услуги и поддерживающие услуги не учитывает сложность современных цифровых экосистем, где границы между видами услуг часто размыты. Модель не учитывает, что одна и та же услуга может быть бизнес-услугой для одного потребителя и поддерживающей для другого. Кроме того, в ITIL4 термины 'бизнес-услуга' и 'информационная технологическая услуга' практически не используются, что создает неоднозначность при переходе от V3 к новой версии.

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

Разбиение ИТ-услуги на функциональные блоки (например, доступ инженера к базе обращений, обработка обращений, отправка уведомлений и др.) при анализе дерева отказов позволяет: определить различную критичность функций – некоторые функции могут быть жизненно важными, другие – второстепенными; упростить и ускорить анализ, так как полное дерево для всей комплексной системы может быть чрезмерно громоздким; четко сопоставить отказы конфигурационных единиц (КЕ) с отказами функциональности, что облегчает определение уровня ущерба и установление целевых показателей восстановления; проводить более точную оценку рисков и распределение ресурсов, фокусируясь на наиболее критичных функциях. Такой подход делает анализ управляемым даже для сложно структурированных ИТ-услуг и позволяет получить практические рекомендации, направленные именно на те компоненты системы, отказы которых ведут к самым серьезным последствиям.

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