Связка стандартов RBAC (INCITS 359-2012, INCITS 494-2012 и INCITS 459-2011) устанавливает общую терминологию и определяет элементы, множества, интерфейсы, команды и модели, которые можно использовать при проектировании систем управления доступом. Это обеспечивает единообразие в подходах к реализации RBAC, позволяет создавать совместимые системы и облегчает процесс анализа их функциональных возможностей. Первый стандарт определяет базовую модель, второй добавляет гибкость за счет поддержки динамических ограничений, а третий обеспечивает корректную комбинацию всех компонентов и их взаимодействие. Совместное использование этих стандартов помогает создавать эффективные решения для управления доступом, которые соответствуют современным требованиям безопасности и бизнес-процессов.

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

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

Метод Management By Objectives важен для Continual Service Improvement, потому что он позволяет более полно использовать творческий потенциал руководителей, вовлекая их в процесс развития организации, и повышает степень их ответственности за получаемые результаты. Это достигается через совместное определение целей и критериев их измерения, что способствует лучшей мотивации и более точному выполнению задач по улучшению услуг.

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

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

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

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

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

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