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

Результаты оценки уровня зрелости могут различаться у разных аудиторов даже при использовании одних и тех же контрольных мероприятий, поскольку один процесс может проявлять признаки сразу нескольких уровней зрелости. Отсутствие стандартной математики для определения интегрального уровня зрелости процесса приводит к тому, что каждый аудитор может применять собственные методы оценки, например, использование весовых коэффициентов для признаков разных уровней. Это делает итоговые оценки уровня зрелости субъективными, и поэтому их не следует воспринимать как объективные метрики эффективности процессов.

Повторная обработка инцидента отрицательно сказывается на результате метрики результативности. Чем больше количество инцидентов (M), которые потребовали повторной обработки конкретной группой, тем ниже значение KPI результативности, так как метрика рассчитывается как 1 — (M / N), где N — общее количество инцидентов с участием группы. Таким образом, повторные обработки напрямую снижают показатель результативности и показывают, что группа не смогла завершить задачу полностью и корректно с первого раза.

Практические упражнения, помогающие понять разницу между товаром и услугой, включают в себя анализ примеров из реальной жизни с акцентом на выявление рисков и затрат, которые клиент перекладывает на поставщика. Например, участникам предлагают взять простой товар (шоколадку, автомобиль) и преобразовать его в услугу, определяя: 1) Какие риски и затраты клиент может переложить на поставщика; 2) Какие ресурсы необходимы для предоставления услуги; 3) Какие операции должен выполнять поставщик. Другой вариант упражнения - анализ существующих бизнес-моделей (каршеринг vs покупка автомобиля, аренда жилья vs покупка квартиры) и выделение компонентов услуги: товара, ресурса и операций. Эти упражнения помогают участникам глубже понять концепцию услуги в рамках ITIL4.

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

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

Модель Compass Model - это структурированный подход к анализу потребителя, разработанный Институтом Disney и упоминаемый в курсе ITIL 4 Drive stakeholder value. Модель представляет портрет потребителя в виде четырёх "сторон света": Север (потребности) - основные причины, побуждающие к выбору; Запад (желания) - менее конкретные, скрытые цели и пожелания; Юг (стереотипы) - предвзятость и установки потребителя, основанные на его опыте; Восток (эмоции) - чувства, которые проявляет или ожидаемо проявит потребитель в процессе взаимодействия с услугой. Практическое применение модели помогает структурировать понимание потребителя и определять, как создавать ценность для клиента, разделяя его ожидания на базовые потребности и дополнительные желания, а также учитывая стереотипы и эмоции.

Управление изменениями является менее изученной и внедренной областью в ИТ-среде по сравнению с управлением инцидентами и организацией Service Desk. Это подтверждается тем, что при прямом вопросе о наличии работающего процесса управления изменениями подняли руки лишь около 10-12 человек из 70 участников семинара. Управление инцидентами и Service Desk представляют собой более стандартные и отработанные процессы, в то время как управление изменениями требует более глубокой настройки и часто сталкивается с организационными сложностями.

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

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