Процессы EDM02, EDM03 и EDM04 в COBIT 5 совместно обеспечивают оценку, направление и мониторинг системы управления ИТ по трём основным направлениям, которые важны для заинтересованных сторон: EDM02 отвечает за формирование ценности и обеспечение получения выгод, EDM03 — за оптимизацию рисков, EDM04 — за оптимизацию использования ресурсов. Эти процессы ориентированы на руководство системой управления ИТ, которая включает в себя набор из 32 процессов.

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

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

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

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

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

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

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

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

В системе Kanban отсутствует визуализация временных потерь, потому что её основная задача — организация и управление потоком работ, а не анализ и выявление неэффективностей. Kanban фокусируется на том, чтобы регулировать поступление задач в систему, контролировать их прохождение через различные этапы и предотвращать перегрузку отдельных участков процесса с помощью ограничений WIP. Для анализа временных потерь и оптимизации процесса обычно используется инструмент, такой как карта потока создания ценности (VSM), который позволяет подробно оценить не только активное время работы, но и время ожидания на каждом этапе процесса.