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

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

Задачи процесса рекомендуется фиксировать в регламенте процесса, так как они меняются реже целей и отражают устоявшуюся технологию реализации процесса. Они определяют конкретные функции, которые процесс должен выполнять для соответствия своему назначению (например, накопление знаний по устранению инцидентов для службы поддержки). Цели процесса, напротив, регулярно пересматриваются (на зрелости уровня 3+), так как привязаны к конкретным временным периодам и бизнес-задачам. Их фиксация в регламенте приведёт к частым изменениям документа, поэтому их размещают в планах управления или картах показателей, где они могут обновляться без переработки основного регламента процесса.

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

Термин 'менеджер услуг' (service manager) в ITIL представляет собой общий термин для обозначения любого руководителя в организации поставщика услуг. В словаре ITIL 2011 он описывается как руководитель, который может относиться к менеджерам по взаимоотношениям с бизнесом, менеджерам процессов или к высшему руководству, отвечающему за ИТ-услуги в целом. При переходе на ITILv3 этот термин формально сохранялся, но фактически не использовался из-за слишком обширного смыслового наполнения. В ITIL 4 упоминание сущности 'менеджер услуг' полностью исчезло.

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

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

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

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

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