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

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

SLM (Service Level Management) - это процесс управления уровнем обслуживания, а SLA (Service Level Agreement) - это конкретное соглашение, которое фиксирует уровень предоставления услуг. При проектировании процесса SLM важно определить, как формируются и утверждаются SLA. В данном случае предложен метод, когда на этапе старта процесса SLM формируется базовое SLA 'AS IS', которое затем может корректироваться бизнесом через дополнительные соглашения, обеспечивая баланс между необходимостью запуска процесса и учетом потребностей заказчиков.

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

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

Для определения достаточного уровня полномочий владельца конкретного процесса нужно провести анализ каждой обязанности владельца процесса и оценить степень критичности выполнения этой обязанности для успешного функционирования процесса в конкретной организации. Можно использовать десятибалльную шкалу, где 10 соответствует самой критичной обязанности, без выполнения которой процесс не сможет работать. По результатам оценки выделяют обязанности с высоким баллом (8-10), которые определят минимально необходимый уровень полномочий. Например, если обеспечению ресурсов процесса присвоено 9 баллов, значит владелец должен иметь возможность влиять на все подразделения, участвующие в процессе. Если организации только начинает внедрять процессный подход, высокие оценки получат больше обязанностей, что потребует более высокого уровня полномочий владельца. В зрелых процессных организациях достаточно будет сконцентрироваться на нескольких ключевых обязанностях.

Шестой принцип DevOps DASA предполагает широкий взгляд на автоматизацию, включая не только процессы разработки программного обеспечения, но и весь инфраструктурный ландшафт, что реализуется через подход 'инфраструктура как код' (Infrastructure as Code). Это означает, что конфигурация и управление инфраструктурой должны быть определены через код и версионироваться, как и любое другое программное обеспечение. Такой подход позволяет автоматически воссоздавать инфраструктуру, обеспечивать её согласованность в разных средах, быстрее разворачивать новые экземпляры и легко откатываться к предыдущим версиям при необходимости. Инфраструктура как код также интегрируется в процессы непрерывной поставки, что позволяет тестировать изменения инфраструктуры так же, как и изменения приложения, повышая общую надёжность и стабильность системы.

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

Термин «аутсорсинг бизнес-процесса» может быть неточным, так как модель сорсинга изначально подразумевает привлечение ресурсов, а не организации процессов. Процесс как форма управления ресурсами и деятельностью должен существовать внутри организации. Предоставляться извне могут непосредственные функции и ресурсы, но не сам процесс управления. Когда поставщик берет на себя управление, заказчик переходит в режим governance (руководства), где управление ресурсами уже не требуется. Следовательно, речь идет не об аутсорсинге процесса, а об аутсорсинге функций внутри этого процесса.

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