Стандарт INCITS 494-2012 добавляет к базовому набору RBAC команды, необходимые для работы с расширенным функционалом, в частности, для обработки динамических ограничений. Примеры таких команд включают 'GetRule', 'ParseRule', 'GetValue' и другие, которые предназначены для взаимодействия с внешними политиками и правилами. Эти команды позволяют системе получать правила от внешних источников, обрабатывать (парсить) их и извлекать значения для применения динамических ограничений. Они дополняют базовые команды административного, системного и контрольного типов, обеспечивая расширенный функционал, который позволяет RBAC учитывать внешние факторы при принятии решений о предоставлении доступа.

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

Основная цель деловой игры Grab@Pizza заключается в том, чтобы помочь участникам лучше понять ключевые аспекты построения эффективного взаимодействия между бизнесом и ИТ. Игра позволяет на практике проработать ситуации, связанные с управлением бизнес-процессами, решением кризисных ситуаций, приоритизацией задач, взаимодействием с технической поддержкой и другими аспектами, которые важны для успешного функционирования компании. Она также помогает выявить способности участников к выполнению определённых ролей и демонстрирует основные принципы ITSM и ITIL.

После устранения major-инцидента необходимо: оперативно оповестить ИТ-специалистов, чтобы они могли завершить обработку всех связанных обращений и проверить восстановление ИТ-услуг; уведомить конечных пользователей о восстановлении сервисов; провести мини-расследование (major incident review) с формированием отчета, направленного на предотвращение повторения инцидента; оценить действия по обработке инцидента и при необходимости зарегистрировать проблему, известную ошибку или новые мероприятия по улучшению ИТ-услуг (например, в рамках service improvement plan или реестра CSI).

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

Согласно ITIL 4, SLA (Service Level Agreement) — это документированное соглашение между поставщиком и заказчиком, которое определяет требования к услуге и ожидаемый уровень предоставления этой услуги. SLA фиксирует договоренности между двумя субъектами сервисных отношений, где заказчик должен определить свои требования и ожидания относительно потребляемой услуги, а также требования других стейкхолдеров, таких как регуляторы.

Output (выход) — это результат деятельности поставщика услуг, который сам по себе не представляет ценности для потребителя, но является необходимым промежуточном этапом. Outcome (результат) — это конечный эффект, который достигает потребитель услуг, выражаясь в реальной пользе или удовлетворении его потребностей. Например, торт от пекарни — это output, тогда как счастливые дети на дне рождения — outcome.

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

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

В ITIL V3 2011 роль менеджера изменений не была отдельно описана - вместо нее существовали роли владельца процесса, менеджера процесса, инициатора, практика, авторизующего и участника CAB. В ITIL4 роль менеджера изменений (Change manager) стала официальной в рамках практики 'Поддержка изменений' (Change enablement) как специфическая роль, включающая управление жизненным циклом отдельных изменений и развитие самой практики. В ITIL4 также появилась дополнительная роль координатора изменений (Change coordinator) для работы в ограниченном контексте, в то время как владелец практики отвечает за общее управление практикой.