Risk Scenarios Using COBIT 5 for Risk является расширенной версией основного документа COBIT5 for Risk и тесно связана с процессной моделью из COBIT5 Enabling Processes. Основная ценность этого документа – невероятное количество деталей, структурированно представленных в табличном формате и раскрывающих риск-сценарии, упомянутые в основной публикации. Документ предоставляет подробные описания, которые трудно найти в других источниках, и бережно раскрывает специфику каждого риск-сценария в контексте процессов управления. Такой структурированный подход позволяет глубже понять практическое применение риск-менеджмента в ИТ-среде.

Компонента L в SLA означает 'Level' (уровень) и представляет собой набор измеримых характеристик услуги, которые определяют, что именно измеряется и как оценивается качество предоставляемой услуги. Это могут быть метрики времени ответа, время восстановления после сбоев, доступность системы и другие количественные показатели, которые позволяют объективно оценить выполнение обязательств по соглашению.

Основные аргументы против использования методики EVM для построения комплексной системы оценки проектов включают: 1) Некорректность показателя SPI для оценки соблюдения сроков завершённых проектов, так как он автоматически становится равным 1 после завершения работ, скрывая реальное отставание; 2) Отсутствие в классической методике EVM прямого показателя качества проекта, хотя этот недостаток относительно легко устраняется; 3) Система метрик EVM изначально разработана для текущего мониторинга хода проекта, а не для комплексной оценки эффективности завершённых проектов.

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

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

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

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

Первый шаг модели Коттера состоит из четырех компонент: 1) Объяснение необходимости изменения – нужно четко обосновать, почему именно сейчас нужна трансформация и каковы последствия отсутствия изменений, можно использовать SWOT-анализ; 2) Разрушение текущих комфортных условий – введение новых ограничений и правил; 3) Воодушевление на изменение – подчеркивание позитивных аспектов предстоящих преобразований; 4) Поощрение коммуницирования срочности – информирование сотрудников через различные каналы на ранних этапах проекта.

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

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