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

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

Сет Годин выделяет девять типов клиентского сервиса: 1) Сервис исключительного качества как стратегическое преимущество; 2) Продажа недорогих товаров в промышленных масштабах; 3) Минимальные издержки на взаимодействие с клиентами; 4) Максимальное завышение ожиданий; 5) Плотный и постоянный контакт с клиентами; 6) Снижение негатива от клиентов; 7) Разный сервис для разных клиентов; 8) Снижение расходов на обслуживание; 9) Отношение к клиентам, как к себе. Эти типы помогают компаниям выбрать стратегию, соответствующую их целям.

Flow Efficiency представляет собой отношение времени, потраченного на непосредственную работу над созданием ценности (Touch Time), к общему времени, которое задача провела в потоке (Time in Process). Это значение выражается в процентах. Touch Time — сумма всех промежутков времени, в течение которых работа над задачей активно выполнялась (без учета времени ожидания, нахождения в очередях и т.д.). Time in Process — общее время, в течение которого задача находилась в рассматриваемом состоянии системы, обычно совпадающее с Lead Time — периодом от момента начала работы до момента завершения.

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

Основные проблемы реализации «доски аварий» связаны со сложностью точного определения влияния инфраструктурных инцидентов на конечные ИТ-услуги. Например, влияние может быть отложенным или незаметным для пользователей, а простое отображение упавшего сервера без контекста может привести к ложным выводам. Для точной оценки требуется детальный анализ связей между компонентами, что противоречит идее «быстрого и наглядного» отображения. Дополнительная сложность — необходимость тщательного описания связей в CMDB для прогнозирования влияния на услуги.

Новый принцип "Оптимизируйте и автоматизируйте" (Optimize and automate) появился в ITIL 4 2019 года и представляет собой одно из основных изменений по сравнению с предыдущей версией. В ITIL Practitioner Guidance 2016 года автоматизация упоминалась в контексте других принципов, например, принципа простоты (Keep it simple), но не выделялась как отдельный руководящий принцип. Введение этого нового принципа отражает возросшую важность автоматизации в современной практике управления услугами, вероятно, под влиянием таких подходов, как DevOps. Принцип подчеркивает необходимость постоянной оптимизации процессов и поиска возможностей для их автоматизации, что позволяет повышать эффективность и качество предоставления услуг.

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

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

Арифметическое среднее не учитывает дисбаланс между метриками: при крайних значениях (например, K1=100%, K2=0%) оно даёт искусственный результат 50%, что не отражает реальной ситуации, когда одна из метрик полностью игнорируется. Tension-метрики должны поощрять баланс, а арифметическое среднее не гарантирует это, поскольку позволяет компенсировать низкое значение одной метрики высоким значением другой. Геометрическое среднее, напротив, требует поддержания обоих показателей на приемлемом уровне, так как пренебрежение одной метрикой приводит к обнулению общего KPI.