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

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

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

Организация работы через веб-клиент позволяет сотрудникам работать с системой через любой браузер, что обеспечивает полный функционал без ограничений, характерных для почтового клиента. Однако этот метод требует стабильного онлайн-соединения с сервером на протяжении всего сеанса работы и предъявляет определенные требования к браузеру (поддержка CSS, JavaScript, AJAX и других современных технологий), что может создавать сложности при использовании на устаревшем оборудовании или в условиях плохого интернет-соединения.

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

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

Противоречие заключается в том, что процессы EDM01 и EDM05, которые должны описывать управление системой руководства ИТ, следуют той же структуре практик (оценка, направление, мониторинг), что и процессы руководства системы управления ИТ (например, EDM02–EDM04). При этом в COBIT 5 проводится чёткое разграничение между руководством и управлением. Если процессы EDM01 и EDM05 представляют собой процессы управления системой руководства, их структура должна быть ближе к управленческим циклам, например, PDCA (планирование-реализация-оценка-корректировка). А если это процессы руководства, тогда возникает вопрос о том, кем и в чьих интересах осуществляется руководство над системой руководства, что представляется избыточным.

Ролевая модель формируется после ответа на вопросы «Кто?» и «Как?», учитывая реальную организацию труда в компании-заказчике. Каждая роль должна иметь чётко определённые зоны ответственности, доступ к необходимым данным и инструментам, а также понимание своей роли в достижении общих целей процесса. Ошибкой является перенос ролей из других проектов без проверки их релевантности.

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

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