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

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

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

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

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

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

Для сбалансированной оценки деятельности групп поддержки необходима пара метрик: 1) Метрика своевременности – оценивает скорость обработки инцидентов с учётом доли ответственности за соблюдение сроков; 2) Метрика результативности – оценивает, насколько группа реально способствует решению инцидента при его обработке (предотвращает «футбол»). Только комбинация этих метрик позволяет объективно оценить как скорость работы группы, так и её реальный вклад в решение инцидентов, а не просто перемещение их между группами.

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

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

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