Преимущества метода 5-Why's включают простоту применения, минимальные требования к данным и инструментам, наглядность построения причинно-следственных цепочек и фокус на практические решения. В отличие от сложных статистических методов, он быстро даёт направление для действий и легко встраивается в существующие процессы управления проблемами ITIL, делая диагностику доступной даже для малых команд с ограниченными ресурсами.

Наиболее популярным методом аудита связей КЕ является периодический выборочный аудит. Такой подход подразумевает проверку данных в определенные промежутки времени, но не постоянно. Однако стоит отметить, что регулярность такого аудита может быть разной в разных организациях, что влияет на объективность информации, отраженной в CMDB.

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

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

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

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

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

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

Для линейных менеджеров старших групп поддержки рекомендуется использовать общий KPI на основе геометрического среднего двух tension-метрик: своевременности (K1) и результативности (K2). Формула K = √(K1 × K2) гарантирует, что оценка отражает баланс между скоростью обработки и качеством решения. Это предотвращает искусственное завышение показателей за счет игнорирования одной из метрик и поощряет устойчивую эффективность в оперативном управлении инцидентами.

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