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

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

Если после попыток делегирования задач у руководителя в RACI-матрице все еще остались R-позиции, необходимо: 1. Проанализировать эти задачи на предмет их критичности и объема работы - возможно, они действительно требуют личного участия руководителя. 2. Для задач, которые все же требуют личного участия, определить, можно ли разделить их на подзадачи, часть из которых можно будет делегировать. 3. Если задача должна выполняться несколькими людьми (включая руководителя), четко определить, кто отвечает за организацию процесса выполнения, а кто выполняет конкретные операции. 4. Рассмотреть возможность использования расширенной RASCI-матрицы, где можно отделить организатора работы от тех, кто просто участвует в исполнении (S - Supports). Это позволит руководителю перейти из позиции R (Responsible) в позицию, связанную с контролем (I или C), сохранив необходимый уровень влияния на процесс без непосредственного выполнения операций. 5. Регулярно пересматривать RACI-матрицу, так как со временем могут появиться сотрудники, готовые взять на себя больше ответственности, что позволит дальнейшее делегирование.

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

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

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

ISO 22301 играет ключевую роль в системе международных стандартов по управлению непрерывностью, так как является основным требуемым стандартом, на который ссылаются другие документы. Он устанавливает общие требования к системе управления непрерывностью бизнеса и служит основой для разработки руководств по применению (таких как ISO 22313), специализированных стандартов (например, ISO 27031) и сводов знаний от различных институтов (таких как GPG от BCI и Professional Practices от DRII).

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

Процессы EDM02, EDM03 и EDM04 в COBIT 5 совместно обеспечивают оценку, направление и мониторинг системы управления ИТ по трём основным направлениям, которые важны для заинтересованных сторон: EDM02 отвечает за формирование ценности и обеспечение получения выгод, EDM03 — за оптимизацию рисков, EDM04 — за оптимизацию использования ресурсов. Эти процессы ориентированы на руководство системой управления ИТ, которая включает в себя набор из 32 процессов.

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