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

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

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

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

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

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

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

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

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

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