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

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

ITIL 4 расширяет подходы ITIL v3, добавляя фокус на управление опытом (experience) помимо полезности и гарантии. Если в ITIL v3 акцент делался на разделении функциональных и нефункциональных характеристик услуг, то в ITIL 4 основное внимание уделяется совместному созданию ценности для заинтересованных сторон, что включает анализ эмоционального и функционального взаимодействия с услугой. Это отражено в практике Drive stakeholder value (DSV), которая уделяет особое внимание CX и UX.

В тексте приведены три основных примера неправильного поведения менеджеров. Первый пример: ИТ-руководитель в игре 'Grab@Pizza', который слишком долго пытается полностью разобраться в сценарии и предсказать будущее вместо того, чтобы начать работу. Второй пример: менеджер инцидентов в 'Apollo 13', который решает, что все инциденты должны проходить через него, и он будет всё регистрировать лично, что оказывается неэффективным уже ко второму раунду. Третий пример: менеджер проекта в 'The Challenge of Egypt', который основное время проводит на стройплощадке, командуя рабочими напрямую, игнорируя важные аспекты проекта вроде бюджета и сроков.

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

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

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

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

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

Наличие дефектов негативно влияет как на бизнес, так и на процесс разработки. Со временем дефекты приводят к экспоненциальному росту потерь - в примере из деловой игры 'Проект Феникс' потери составили 2 000 долларов в первом раунде, 26 000 во втором и 39 000 в третьем. Наличие дефектов замедляет разработку новых функций, так как разработчики вынуждены тратить время на исправление ошибок, и создает технический долг, который становится все дороже в исправлении. Для бизнеса это трансформируется в прямые финансовые потери и ухудшение качества продукта, что отражается на удовлетворенности клиентов.