В расширенном RBAC (стандарт INCITS 494-2012) атрибуты используются для создания динамических ограничений на основе внешних факторов. Атрибутами могут быть: определенный период времени в сутках, местоположение пользователя, цель использования системы, класс пользователя, значение определенного типа данных и тип учетной записи. Например, можно создать правило, которое запрещает доступ к финансовым операциям вне рабочего времени или ограничивает использование определенных ролей только в офисе компании. Атрибуты позволяют сделать систему управления доступом более гибкой и адаптированной к изменяющимся условиям, добавляя контекстную зависимость к правилам доступа, что преодолевает недостатки 'чистого' RBAC.

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

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

SIAM (Service Integration and Management) представляет собой подход к управлению услугами в условиях множества поставщиков. Его основная концепция заключается во введении уровня управления, называемого «сервис-интегратор», который располагается между организацией-заказчиком и её поставщиками услуг. Сервисный интегратор отвечает за управление, интеграцию и координацию различных поставщиков, чтобы клиент получал наилучшее качество сервиса и сокращал накладные расходы на управление множеством поставщиков. SIAM описывается в документе «SIAM Foundation Body of Knowledge», который предоставляет методологию для организации потребления услуг в моделях с несколькими внешними и внутренними поставщиками.

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

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

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

В иерархической RBAC (Hierarchical RBAC) механизм наследования прав работает на основе организации ролей по принципу старшинства. Роли располагаются в иерархическом порядке, и нижестоящие роли наследуют все права доступа от вышестоящих ролей. Например, если роль 'Главный инженер' расположена ниже роли 'Сотрудник' в иерархии, то 'Главный инженер' автоматически получает все права, определенные для роли 'Сотрудник', плюс свои собственные дополнительные права. Это позволяет уменьшить дублирование прав при проектировании системы, так как общие базовые права можно вынести в одну роль, а специфические - в более специализированные нижестоящие роли. Механизм наследования значительно упрощает администрирование крупных систем с большим количеством пользователей и ролей.

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

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