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

Реализация стандартных запросов пользователей обычно относится к процессу выполнения запросов (Request Fulfillment), который является отдельным от управления изменениями. Управление изменениями (Change Management)主要用于 контроля и координации изменений в ИТ-инфраструктуре, тогда как выполнение запросов занимается обработкой стандартных запросов, не требующих изменения конфигурации. Однако на практике границы между этими процессами могут быть размыты, что вызывает вопросы у специалистов.

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

В ITIL 4 назначение практики управления инцидентами формулируется следующим образом: «Минимизировать негативное влияние инцидентов, восстанавливая нормальную работу услуг как можно быстрее». Основной недостаток этой формулировки заключается в том, что она акцентирует внимание преимущественно на скорости восстановления услуги, тогда как в действительности удовлетворённость пользователей зависит от множества других факторов, таких как качество коммуникаций, количество контактов с поддержкой и окончательность решения. Хотя в более подробном описании практики в ITIL 4 упоминается важность удовлетворённости пользователей, в самой формулировке назначения эта цель не отражена явно, что может приводить к тому, что организации сосредотачиваются только на скорости решения инцидентов, упуская из виду другие значимые аспекты.

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

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

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

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

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

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