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

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

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

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

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

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

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

Шестой принцип DevOps DASA предполагает широкий взгляд на автоматизацию, включая не только процессы разработки программного обеспечения, но и весь инфраструктурный ландшафт, что реализуется через подход 'инфраструктура как код' (Infrastructure as Code). Это означает, что конфигурация и управление инфраструктурой должны быть определены через код и версионироваться, как и любое другое программное обеспечение. Такой подход позволяет автоматически воссоздавать инфраструктуру, обеспечивать её согласованность в разных средах, быстрее разворачивать новые экземпляры и легко откатываться к предыдущим версиям при необходимости. Инфраструктура как код также интегрируется в процессы непрерывной поставки, что позволяет тестировать изменения инфраструктуры так же, как и изменения приложения, повышая общую надёжность и стабильность системы.

Согласованный 'внеплановый' простой отличается от реального аварийного простоя тем, что он заранее запланирован, согласован со всеми заинтересованными сторонами и документирован, даже если и выходит за рамки обычного календаря плановых работ. Он имеет чёткие временные рамки, процедуры восстановления и оценку рисков. В отличие от него, аварийный простой возникает внезапно, без предварительного планирования, негативно влияет на бизнес-процессы и требует срочного реагирования через процессы управления инцидентами. Различие критично для правильной отчётности и анализа причин проблем, так как согласованные простои являются управляемыми элементами процесса, в то время как аварийные простоя сигнализируют о реальных проблемах с надёжностью систем.

Магический квадрат Гартнера по ITSM-продуктам вызывает критику за то, что он недостаточно концентрируется на технических характеристиках продуктов и слишком ориентирован на оценку компаний-поставщиков как стратегических партнеров. Это приводит к ситуации, когда позиции вендоров могут резко меняться на основе факторов, не связанных напрямую с качеством их решений, например из-за изменений в маркетинговой стратегии. Кроме того, аналитика Гартнера имеет тенденцию к усреднению и отставанию от реального состояния ITSM-рынка.