COBIT5 for Risk (ранее известный как Risk IT) предлагает строгий, структурированный подход к описанию и управлению рисками. Его отличительной особенностью является учет дополнительных параметров при оценке рисков, таких как прогнозируемая длительность негативного влияния, критичность события относительно календарного периода или времени суток. Документ содержит множество практических примеров, размещенных в виде плашек на полях, и включает сотни примеров рисков, классифицированных по 20 категориям – от управления ИТ-инвестициями и проектами до рисков, связанных с поставщиками, вредоносным ПО, атаками и регуляторами. Для каждого риска указаны соответствующие контрмеры.

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

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

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

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

У первой линии поддержки существуют следующие ограничения при оценке влияния инцидентов: 1) Доступны только субъективные оценки пользователя, без технической диагностики. 2) Объем диагностической информации минимален на начальном этапе обращения. 3) Пользователь может не знать о проблемах других сотрудников. 4) Сложности в объективной оценке степени недоступности функционала ('совсем не работает' против 'частично не работает'). 5) Необходимость быстро принять решение об уровне влияния, имея ограниченную информацию. Эти ограничения делают важным разработку четких вопросов для пользователя, которые позволяют максимально объективно определить влияние инцидента.

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

Автоматическая функциональная эскалация может корректно работать только в одном случае: если время обработки на уровне Ln истекло, и при этом этот уровень поддержки не только не решил инцидент, но даже не принял его в работу. Это работает как страховка от перегрузки конкретного уровня поддержки, позволяя автоматически привлечь следующий уровень (Ln+1). Однако такой сценарий предполагает, что специалисты обязательно сначала отмечают прием заявки в работу, а только потом фиксируют ее решение. На практике это условие часто нарушается, особенно в ситуациях с major-инцидентами, где множество заявок обрабатываются массово при закрытии общего инфраструктурного инцидента, не требуя индивидуального приема в работу каждым специалистом.

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

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