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

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

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

Обычно выделяются четыре уровня влияния инцидентов: 1) Максимальный уровень (критический) - когда ИТ-услуга недоступна для всего отдела или компании, что приводит к полной остановке бизнес-процессов. 2) Высокий уровень - когда несколько сотрудников сталкиваются с полным отсутствием функционала. 3) Средний уровень - когда у группы пользователей доступна только часть функционала. 4) Низкий уровень (минимальный) - когда у одного сотрудника недоступна только часть функционала ИТ-услуги. Эти уровни могут варьироваться в зависимости от принятой в организации методологии и дополнительных критериев оценки, таких как VIP-статус пользователей или критичность системы.

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

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

Practice Success Factors (PSF) для практики управления инцидентами представляют собой комплексные функциональные компоненты, необходимые для того, чтобы практика реализовывала своё назначение. Согласно описанию в ITIL 4 Practice Guide, к ним относятся: обеспечение своевременного и эффективного восстановления нормальной работы услуг, поддержание удовлетворённости пользователей, соблюдение необходимого уровня прозрачности и коммуникации с пользователями, обеспечение качества решений (включая окончательность решения с первой попытки), контроль количества итераций взаимодействия с пользователем (например, через показатель FCR) и проактивное информирование о ходе решения инцидентов. Эти факторы обеспечивают комплексный подход к управлению инцидентами, выходящий за рамки простого ускорения решения проблем.

Бизнес-роль — это набор системных ролей из разных ИТ-систем, объединённых общей функцией в рамках бизнес-процесса или подразделения. Например, бизнес-роль 'Финансовый аналитик' может включать системные роли 'Пользователь модуля отчётности' (в ERP-системе) и 'Аналитик данных' (в BI-инструменте). Бизнес-роли отражают реальные задачи сотрудников, в то время как системные роли — технические права в рамках отдельных приложений. При масштабировании ролевой модели от уровня приложения до всего предприятия роль администратора управляет бизнес-ролями, которые автоматически распространяют доступ через связанные системные роли.

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

Термин 'владелец процесса' может быть условным в тех случаях, когда человек, занимающий эту роль, не обладает достаточными полномочиями для реального управления всем процессом. Например, когда владельцу не хватает власти над всеми подразделениями, участвующими в процессе, и поэтому он не может напрямую решать возникающие проблемы. В таких ситуациях роль сродни скорее координации и согласования, чем прямому управлению. Поэтому в литературе по процессному управлению часто используются альтернативные термины: 'управляющий процесса' (process manager), 'распорядитель процесса' (process steward) или 'спонсор процесса' (process sponsor). Эти термины лучше отражают суть роли, когда человек не владеет процессом в прямом смысле, но ответственен за его функционирование и развитие.