Функциональная спецификация в стандарте RBAC определяет три типа команд: административные, системные и контрольные. Административные команды предназначены для создания и работы с элементами множеств и связями при построении различных компонентов модели RBAC. Примеры: 'AddUser', 'DeleteUser', 'AddRole', 'GrantPermission'. Системные команды обеспечивают работу конструкций в течение пользовательских сессий. Примеры: 'CreateSession', 'AddActiveRole', 'CheckAccess'. Контрольные команды используются для проверки результатов выполнения административных команд. Примеры: 'AssignedUsers', 'RolePermissions', 'UserPermissions', 'UserOperationsOnObject'. Каждая команда имеет свой алгоритм работы и предназначена для выполнения конкретных задач в системе управления доступом.

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

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

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

Процесс управления проблемами инициируется не внешними событиями (в отличие от инцидентов), а внутренними механизмами: анализ тенденций множества инцидентов, плановые аудиты, результаты диагностики инцидентов, данные мониторинга систем и рекомендации экспертных групп (например, PRB). Для эффективной работы необходимо внедрить регулярные проверки этих источников и чётко прописать критерии создания записи о проблеме.

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

Реализация стандартных запросов пользователей обычно относится к процессу выполнения запросов (Request Fulfillment), который является отдельным от управления изменениями. Управление изменениями (Change Management)主要用于 контроля и координации изменений в ИТ-инфраструктуре, тогда как выполнение запросов занимается обработкой стандартных запросов, не требующих изменения конфигурации. Однако на практике границы между этими процессами могут быть размыты, что вызывает вопросы у специалистов.

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

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

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