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

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

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

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

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

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

В COBIT 5 for Risk для мониторинга рисков используются ключевые показатели риска (Key Risk Indicators - KRI), которые привязаны к ИТ-целям из основной публикации COBIT 5 и целям процесса из COBIT 5: Enabling Processes. Эти показатели позволяют отслеживать ситуацию в реальном времени и предупреждать о приближении нежелательных событий. Для каждого риска в документе указаны соответствующие ключевые показатели, что позволяет организациям использовать их как инструмент для проактивного управления рисками и принятия обоснованных решений.

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

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

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