В процессе «Управление проблемами» выбор между полным решением проблемы и временным обходным путем (workaround) определяется на основе оценки ресурсов, требуемых для реализации каждого варианта, и ожидаемого бизнес-влияния. Процесс подразумевает, что не всегда целесообразно тратить значительные ресурсы на полное устранение проблемы, особенно если частота инцидентов низкая или влияние на бизнес незначительно. Если стоимость постоянного решения превышает выгоду от его внедрения, выбирается временный обходной путь с документированием в виде «известной ошибки». Решение принимается после анализа соотношения затрат и выгод для бизнеса в конкретной ситуации.

Для эффективного управления проблемами необходимо: 1) Четко отличать проблемы от инцидентов и не смешивать эти понятия; 2) Сформулировать бизнес-ценность управления проблемами и оценить негативное влияние от инцидентов; 3) Сфокусироваться на проактивной деятельности, а не только на реактивной; 4) Обеспечить доступ сервисных команд к базе известных ошибок (KEDB); 5) Регулярно измерять эффективность работы в управлении проблемами; 6) Инвестировать в устойчивость систем и обучение персонала; 7) Постоянно анализировать эффективность обходных решений и оценивать целесообразность применения постоянных решений.

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

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

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

Стандарт ISO20000:2011 в разделе 4.2 требует от поставщика услуг демонстрировать governance процессов, оперируемых другими сторонами путем: демонстрации ответственности за процессы и полномочий требовать соблюдения процессов; контроля определения процессов и интерфейсов с другими процессами; определения эффективности процессов и соответствия требованиям процессов. Это позволяет поставщику управлять результатами подрядчиков без прямого управления их ресурсами.

При трансляции ожиданий заказчика в формальные требования к услугам возникает несколько серьезных проблем: 1) Часто заказчик затрудняется четко сформулировать свои реальные потребности и ожидания, выражая их в общих и расплывчатых формулировках; 2) Сервис-провайдер сталкивается с трудностями в правильной интерпретации и расшифровке этих нечетко сформулированных требований; 3) Ожидания заказчика часто завышены или не соответствуют реальным возможностям сервис-провайдера; 4) Отсутствие глубокого понимания бизнес-процессов заказчика у сотрудников сервис-провайдера приводит к неправильной интерпретации реальных потребностей.

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

Активно расширяющиеся компании выделяют на 'развитие и управление ИТ' лишь 1-2% от общего размера ИТ-бюджета, что значительно меньше, чем компании, придерживающиеся стратегии выживания (которые выделяют 4-8%).

Вывод о целесообразности внедрения управления уровнями ИТ-услуг зависит от стадии зрелости организации и её стратегических целей. Если компания не планирует расширять сервисный подход на разработку и останется на разделении ALM и ITSM как постоянном решении, то управление уровнями услуг может принести меньше пользы, чем ожидается. В этом случае организация может ограничиться реализацией операционных процессов управления на уровне зрелости «Controlled», что будет более адекватным решением. Однако для компаний, где зависимость от ИТ высока и требуется постоянное развитие систем, необходим переход к интегрированному подходу с полной сквозной ответственностью за услуги.