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

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

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

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

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

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

Поток создания ценности (value stream) - это последовательность этапов, которая описывает решение задачи от начала до конца (сквозной процесс). Это конструкция, которая объединяет различные части организации во благо продукта(ов). В этом потоке ресурсы организации (включая людей) могут вовлекаться в выполнение работ на различных этапах. Отношение между организационными подразделениями и этапами потока является отношением многие-ко-многим: одно подразделение может участвовать в нескольких этапах потока, и для выполнения одного этапа может потребоваться несколько подразделений. Для структурирования анализа этих связей могут использоваться дополнительные слои сущностей, такие как практики в ITIL4 или 'способности' в TOGAF.

Прозрачность результатов работы команды важна потому, что это помогает всем участникам процесса совместно и согласованно понимать, какую ценность они создают. Когда разработчики видят реальные реакции пользователей на их работу (негативные отзывы, запросы на новые возможности, положительный отклик на митапах), это значительно повышает их вовлеченность, по сравнению с абстрактными показателями типа "увеличение конверсии на 0,07%". Это позволяет команде осознанно определять приоритеты, оценивать результаты своих решений, понимать, почему одни задачи более важны, чем другие. Прозрачность предотвращает ситуацию, когда разработчик просто разрабатывает фичи по очереди и забывает о них, не видя их реального эффекта.

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

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