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

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

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

В IT4IT функциональные компоненты организованы вокруг сервисной модели (Service Model), которая представляет собой Service Backbone архитектуры. Эта модель охватывает все стадии, необходимые для создания и предоставления ИТ-услуг, что напрямую соответствует концепции жизненного цикла услуги из ITIL. Конкретно, функциональные компоненты в IT4IT распределены по четырем Value Streams, каждый из которых охватывает определенную фазу жизненного цикла: Strategy to Portfolio (S2P) - управление портфелем и стратегией; Requirement to Deployment (R2D) - разработка и развертывание; Request to Fulfill (R2F) - предоставление услуг; Detect to Correct (D2C) - управление эксплуатацией и решением проблем. Таким образом, набор функциональных компонентов в IT4IT охватывает все этапы от идеи услуги до ее непрерывного улучшения, полностью зеркалируя концепцию жизненного цикла услуги, только структурированную в виде потоков создания ценности.

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

В управлении внеплановыми простоем при срочном внедрении изменений задействованы три основных процесса ITIL: управление изменениями (Change Management), который отвечает за процесс внедрения изменений и формирование документа PSO; управление уровнем услуг (Service Level Management, SLM), который занимается обсуждением и согласованием с заказчиком целевых показателей доступности на период внедрения изменений; и управление доступностью (Availability Management), который проверяет соответствие плановой доступности целевым значениям и оценивает влияние изменений на доступность сервисов в долгосрочной перспективе.

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

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

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

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