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

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

Бизнесу предоставляется механизм взаимодействия, позволяющий по их собственной инициативе пересматривать соглашение. Конкретные заказчики могут заключать дополнительные соглашения по конкретным ИТ-сервисам, которые будут изменять положения общего SLA 'AS IS'. Это дает бизнес-подразделениям возможность выразить свои требования и скорректировать условия обслуживания под свои потребности, но при этом не блокирует старт процесса согласованием со всеми заинтересованными сторонами.

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

Предложенная метрика решает проблему сложности установки целевых значений за счет своей нормированности - она всегда находится в диапазоне от 0 до 1. Это позволяет легко определить целевые значения (например, 80-90%) без сложных расчетов, зависящих от объема работы. При этом существует два варианта методики установки целевого значения: ориентация на соотношение длительности отчетного периода к среднему времени решения проблем, или фиксация целевого уровня (например, 80-90%), при условии выбора отчетного периода, равного или немного большего среднего времени решения проблемы. Это делает цели измеримыми и достижимыми.

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

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

Разделение этапов жизненного цикла необходимо, поскольку общий показатель простоя не даёт информации о том, на каком этапе возникают задержки. Например, если инцидент длился 1 час, но устранение проблемы заняло всего 5 минут, без разбивки невозможно определить, что 55 минут ушли на ожидание информации или диагностику. Детальный анализ каждого этапа позволяет целенаправленно оптимизировать слабые места процесса, что в совокупности сокращает общее время простоя и повышает надёжность предоставления услуг.

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

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