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

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

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

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

В ITIL V3 ответственность за координацию изменений формально не закреплена за конкретной ролью. Вместо этого упоминается, что координация является частью процесса управления изменениями в целом и может быть возложена на различные лица в зависимости от ситуации. Это могут быть менеджер процесса, практик изменений или участники CAB (Change Advisory Board). Например, в главе 4.2.5 описываются активности по координации, но не уточняется, кто именно их выполняет. Таким образом, ITIL предоставляет гибкость в распределении ответственности, ориентируясь на особенности организации, но это может привести к неоднозначности при внедрении процесса.

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

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

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

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

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