При адаптации COBIT5 в Бахрейне 37 процессов были сгруппированы в следующие 8 блоков: стратегия и руководство (6 процессов), управление финансами (4 процесса), люди и ресурсы (2 процесса), инфраструктура и эксплуатация (8 процессов), управление приложениями (3 процесса), планирование услуг и архитектура (3 процесса), управление рисками и безопасностью (7 процессов), управление портфелем и проектами (4 процесса).

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

Публичные почтовые сервисы, такие как Gmail или Яндекс.Почта, как правило, не включают в свои соглашения об уровне обслуживания (SLA) штрафные санкции или даже четкие измерения и оценки уровня предоставления услуги. В таких сервисах пользователи часто сталкиваются с формулировками, что услуги предоставляются «как есть», без гарантий соответствия требованиям пользователей или обеспечения непрерывной, надежной работы. Это означает, что ответственность за предоставление услуг ложится в основном на пользователя, а поставщик не несет обязательств по компенсации за возможные перебои или недостатки.

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

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

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

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

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

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

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