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

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

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

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

Книга рекомендует даже в ситуациях, когда ИТ-подразделение находится внутри компании, рассчитывать стоимость услуг и управлять ИТ-подразделением почти как бизнесом (more like a business), даже если фактических взаиморасчетов с бизнес-подразделениями нет. Это позволяет ИТ-руководству более четко обосновывать затраты, выстраивать сервисные отношения с бизнесом, определять приоритеты развития и доказывать ценность ИТ для компании. Учет стоимости услуг помогает в принятии решений о развитии или закрытии тех или иных сервисов и делает ИТ-менеджмент более прозрачным и понятным для бизнес-руководства.

Стандартное восприятие SLM (Service Level Management) как процесса, который ограничивается подготовкой и актуализацией каталога услуг, SLA и OLA, имеет довольно ограниченное применение. Фактически, создание и поддержка этих документов составляет не более половины содержания SLM как процесса. При этом практика ведения каталога технических услуг и OLA применима лишь к очень небольшой доле компаний, где реализован сервисный подход, а каталог бизнес-услуг с различными уровнями обслуживания востребован преимущественно в сценариях массового обслуживания. Это восприятие важно осознавать, особенно когда процесс управления уровнем услуг сводится только к документированию.

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

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

Для небольших и средних ИТ-организаций рекомендуется сначала рассмотреть объединенный подход к управлению инцидентами и сервисными запросами, чтобы избежать излишней сложности и организационных конфликтов. Если организация все же решит разделить процессы, необходимо разработать четкие и простые критерии классификации, провести обучение персонала, обеспечить возможность гибкой переклассификации запросов и назначить ответственного за координацию между процессами. Важно помнить, что в ITIL v2 подчеркивалось, что практика показывает схожесть обработки сбоев и сервисных запросов. Перед внедрением разделения рекомендуется провести анализ, оценить реальную добавленную ценность и убедиться, что разделение не создаст больше проблем, чем решит.

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