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

В контексте соглашений об уровне услуг (SLA) владелец услуги участвует в обсуждении SLA/OLA применительно к услуге, находящейся в его зоне ответственности. Он обеспечивает соответствие уровня предоставления и поддержки услуги согласованным параметрам SLA. Владелец услуги также транслирует требования бизнеса в понятные ИТ-задачи, обеспечивает прозрачные коммуникации с заказчиком по запросам и инцидентам в контексте конкретной услуги и представляет услугу в рамках всей организации, включая участие в обсуждениях на CAB (Change Advisory Board).

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

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

Момент объявления инцидента значительным определяется на основании заранее согласованного и задокументированного определения, утвержденного поставщиком услуг совместно с заказчиком. Любой участник процесса (сотрудник аварийной службы или подразделения поддержки) может объявить инцидент значительным, если ситуация соответствует заранее определенным критериям. После объявления значительного инцидента должна быть активирована специальная процедура, включающая уведомление топ-менеджмента, назначение ответственного лица, организацию совместной работы команд и внедрение специальных мер реагирования. Даже если некоторые службы не видят признаков значительного инцидента, они обязаны следовать установленной процедуре реагирования.

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

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

Outcome зависит от субъективного восприятия потребителя и часто выражается в нематериальных или долгосрочных эффектах, которые сложно зафиксировать количественно. В то время как Output обычно имеет чёткие количественные параметры (например, сроки доставки, объём функционала), что позволяет легко его измерять и отчитываться о нём. Для оценки Outcome необходимо собирать обратную связь, проводить опросы удовлетворённости или анализировать поведение клиентов.

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

Особенности учёта финансовой информации, которые создают сложности при интеграции с CMDB, включают: отсутствие в системах учёта договоров спецификации с перечнем закупленных или обслуживаемых позиций, неучет в бухгалтерских системах нематериальных активов, группировку объектов инфраструктуры в комплекты с описанием состава только в текстовом поле 'Комментарий'. Эти особенности затрудняют корректное сопоставление информации между системами и приводят к проблемам с точностью данных, особенно при попытке определить затраты на конкретные конфигурационные единицы. Для решения этих проблем требуется дополнительная настройка и обработка данных, поскольку автоматическая обработка таких случаев часто невозможна без создания специальных правил преобразования информации.