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

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

SIAM (Service Integration and Management) - это подход к управлению несколькими поставщиками услуг в сложной экосистеме. В ITIL4 термины 'бизнес-услуга' и 'информационная технологическая услуга' упоминаются в контексте SIAM при описании практики Service Design. SIAM помогает интегрировать и управлять услугами от различных поставщиков так, чтобы конечному потребителю предоставлялась единая, согласованная бизнес-услуга, несмотря на то, что за ней может стоять множество поддерживающих услуг от разных поставщиков.

Подход к управлению непрерывностью ИТ-услуг в ITIL v3 и IT4IT имеет как сходства, так и различия. В ITIL v3 управление непрерывностью представлено как отдельный процесс, который входит в состав этапа Service Design (дизайн услуг) и фокусируется на обеспечении непрерывности бизнеса через ИТ-услуги. В IT4IT управление непрерывностью интегрировано в Value Stream Detect to Correct (D2C), который охватывает весь спектр деятельности по обнаружению и устранению инцидентов и проблем. В рамках этого потока управление непрерывностью рассматривается как часть более широкого процесса обеспечения стабильности и качества услуг. При этом IT4IT делает акцент на том, как система в целом обеспечивает непрерывность через взаимодействие различных функциональных компонентов, тогда как ITIL v3 предоставляет более детализированное описание конкретных процессов и процедур управления непрерывностью. Оба подхода признают важность непрерывности услуг, но структурируют эту деятельность по-разному - в ITIL v3 как отдельный процесс, а в IT4IT - как интегральную часть потока обнаружения и исправления проблем.

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

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

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

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

Различия в описании критических факторов успеха (CSF) между ITIL v3 и IT4IT заключаются в уровне детализации и фокусе. В ITIL v3 критические факторы успеха и ключевые показатели эффективности (KPI) определены для каждого из 26 процессов, что предоставляет очень детализированные рекомендации по управлению отдельными функциональными областями. В IT4IT же CSF и KPI описываются на уровне Value Streams (потоков создания ценности), а не на уровне отдельных функциональных компонентов. Это означает, что IT4IT делает акцент на том, что необходимо для успешного создания ценности через весь поток деятельности, а не только через его отдельные элементы. Хотя в ITIL v3 есть упоминания о критических факторах успеха для фаз жизненного цикла услуги (в последних главах каждой книги), это описание менее структурировано и детально по сравнению с фокусом IT4IT на Value Streams. Таким образом, ITIL v3 предоставляет более операционный, процессно-ориентированный взгляд на CSF, тогда как IT4IT предлагает более стратегический, потоко-ориентированный подход.

Принцип распределения ответственности между группами при обработке просроченного инцидента заключается в том, что степень ответственности каждой группы пропорциональна её доле в общем времени обработки инцидента. То есть, если группа потратила большую часть времени на обработку просроченного инцидента, её доля ответственности будет больше и метрика KPI покажет более низкое значение. Формула учитывает время ti, которое каждая группа затратила на работу с инцидентом, и общее время Ti обработки инцидента. Таким образом, ответственность за просрочку распределяется более справедливо, чем при традиционном подходе, где вся ответственность возлагается на последнюю группу.