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

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

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

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

Методика «Пять «Почему?» («5-why») заключается в последовательном задавании вопроса «Почему?» для выявления причин явления (проблемы). Начиная с исходного события, на каждом шаге фиксируется ответ, и к этому ответу снова применяется вопрос «Почему?». Данный подход позволяет, как утверждается в ITIL SO (4.4.4.3), на пятой итерации добираться до корневой причины проблемы. Однако процесс может включать ветвление ответов на каждом этапе, поскольку на вопрос «Почему?» часто существует несколько возможных ответов, что усложняет однозначное определение корневой причины.

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

Шестой принцип DevOps по DASA 'Автоматизируйте всё, что можете' охватывает два основных аспекта автоматизации: во-первых, автоматизацию процессов разработки программного обеспечения, включая непрерывную поставку (continuous delivery), которая сама подразумевает непрерывную интеграцию (continuous integration) и непрерывное развёртывание (continuous deployment). Во-вторых, автоматизацию всего инфраструктурного ландшафта, что в современных практиках реализуется через подход 'инфраструктура как код' (Infrastructure as Code). Такой широкий взгляд на автоматизацию позволяет снизить человеческий фактор, ускорить процессы разработки и доставки, повысить надёжность и воспроизводимость систем, а также обеспечить возможность быстрого масштабирования и восстановления систем при необходимости.

В настоящее время буква «R» в методологии SMART чаще всего означает «relevant» (релевантный), а не «realistic» (реалистичный), как иногда ошибочно используют. Под этим понимается соотнесение цели с контекстом и проверка, насколько целесообразно и уместно её достигать в данном конкретном случае.

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

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