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

Управление релизами не обязательно должно быть отдельным процессом в ИТ-организации. В зависимости от организационной структуры, управление релизами может быть реализовано как отдельный процесс (в подразделении разработки и сопровождения) или как часть процесса управления изменениями (в подразделении эксплуатации). Во втором случае управление релизами выполняет функцию инструмента управления изменениями, отвечающего именно за внедрение, что соответствует описанию в ITIL и IBM Tivoli Unified Process.

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

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

Накопление опыта и знаний положительно влияет на эффективность внедрения изменений в ИТ через повышение Change capability (способности ИТ-организации проводить изменения). Чем чаще внедряются изменения (выше Release rate), тем больше возможностей для обучения на собственных ошибках, отработки взаимодействия и усвоения уроков. Это приводит к росту компетенций команды, увеличению способности автоматизировать стандартные процессы (Standardization/automation) и улучшению First-Time Implementation Rate (коэффициент успешного внедрения с первого раза). В итоге, усиленная Change capability позволяет сократить Process Time (время работы над изменением) и, как следствие, снизить общий Time to market. Этот процесс образует положительную усиливающую петлю обратной связи, где ритмичные малые внедрения приводят к росту возможностей, что позволяет делать еще больше и качественнее внедрений, создавая эффект непрерывного улучшения процессов.

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

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

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

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

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