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

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

WIP-лимиты (Work in Progress Limits) оказывают значительное влияние на сокращение Time to Market, ограничивая количество задач, одновременно находящихся в работе. Это предотвращает перегрузку команды, уменьшает контекстные переключения и позволяет сосредоточиться на завершении текущих задач вместо их бесконечного запуска. Когда команда не пытается сделать всё сразу, но фокусируется на ограниченном количестве задач, циклическое время каждой задачи существенно сокращается. Например, в деловой игре 'Проект Феникс' внедрение WIP-лимитов и упорядочение потока работы позволили снизить Time to Market с 25 минут до 40 секунд - 1,5 минуты. WIP-лимиты также делают проблемы видимыми, так как перегрузка и узкие места становятся очевидными, что позволяет оперативно их устранять.

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

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

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

Иерархия ролей (цепочки 'родительская-дочерняя') позволяет упростить управление доступом за счёт наследования прав. Например, родительская роль 'Менеджер отдела' может включать права 'Создание отчётов' и 'Утверждение заявок', а дочерняя 'Старший менеджер' добавляет к ним право 'Контроль бюджета'. При этом дочерняя роль автоматически получает все права родительской. Это избавляет от дублирования настроек, ускоряет назначение сложных ролей и обеспечивает консистентность прав. Иерархия также поддерживает градацию полномочий (например, junior/senior) без необходимости перенастройки базовых прав.

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

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

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