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

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

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

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

Операционный бюджет ИТ формируется через последовательность шагов: получение бизнес-планов через взаимодействие с владельцами бизнеса (BRM/SLM), согласование планов потребления услуг с заказчиками (SLM и управление емкостью сервисов), разработка планов ресурсного обеспечения включая кадры (управление емкостью ресурсов), расчет стоимости ресурсов и услуг с учетом косвенных затрат (Финансовый менеджмент в ИТ), и финальный расчет стоимости услуг по потребителям с обоснованным формированием бюджета. Этот процесс требует тесной увязки бизнес-потребностей, технических возможностей и финансового планирования.

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

BRM участвует на всех основных этапах жизненного цикла услуги согласно ITIL. На этапе Service Strategy BRM держит руку на пульсе бизнеса заказчика, знает его задачи и изменения в деятельности, помогает коммуницировать стратегические цели заказчика ИТ-специалистам. На этапе Service Design BRM помогает сформулировать ценность услуги для заказчика и правильно расшифровать требования ИТ-специалистам. На этапе Service Transition BRM обеспечивает вовлечение заказчика в тестирование и передачу/приемку услуги. На этапе Service Operation BRM следит за тем, чтобы заказчик получал ожидаемую ценность и удовлетворенность, управляя процессом обработки жалоб. На этапе CSI (Continual Service Improvement) BRM определяет возможности по оптимизации услуги и участвует в service reviews для постоянного улучшения предоставляемых сервисов.

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

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

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