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

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

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

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

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

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

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

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

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

В 2010 году в магическом квадрате Гартнера по ITSM-продуктам свои позиции потеряли такие компании, как HP, CA и IBM, которые переместились из категории лидеров в категории претендентов или нишевых игроков. При этом BMC Remedy ITSM Suite осталась единственным лидером. Изменения позиций произошли преимущественно из-за переоценки маркетинговой активности, стратегического видения и способности поддержки долгосрочных партнерских отношений, нежели из-за фундаментальных изменений в продуктах.