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

Создание перечня критических бизнес-функций (VBF) может столкнуться с несколькими препятствиями: 1) низкая зрелость бизнеса в области управления процессами, что затрудняет чёткое определение и описание бизнес-процессов; 2) отсутствие готовности бизнеса к открытой коммуникации о своих процессах и их критичности; 3) сложность согласования разных точек зрения на критичность функций между различными стейкхолдерами; 4) отсутствие чётких методик по определению VBF, так как существующие методики оценки зрелости процессов не дают прямых инструкций по этому вопросу. Эти препятствия требуют времени и ресурсов для преодоления.

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

Для большинства проектов достаточным и необходимым является список из четырех ключевых ограничений: сроки, бюджет, качество и охват. Некоторые методологии, такие как PMBoK, могут упоминать большее количество ограничений (до шести), но расширять список следует осторожно. Дополнительные параметры, такие как ресурсы или риски, часто не являются прямым ограничением для заказчика, а представляют собой внутренние аспекты управления проектом. Ресурсы, например, - это внутреннее дело проектной группы, и их обсуждение с клиентом не всегда уместно, в отличие от основных ограничений, понятных заказчику.

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

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

Показатели зрелости, обычно измеряемые по шкале от 1 до 5, можно привести к шкале результативности (0-100%), используя простую линейную или нелинейную конверсию. Например, уровень зрелости 1 может соответствовать 0%, уровень 2 — 25%, уровень 3 — 50%, уровень 4 — 75%, и уровень 5 — 100%. Такая конверсия позволяет визуализировать оба показателя на одном радаре для удобного сравнения и анализа. Это даёт возможность одновременно оценивать текущую пользу процессов (результативность) и степень уверенности в стабильности этой пользы (зрелость).

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

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

Учёт участия нескольких групп поддержки в обработке одного инцидента реализован через пропорциональное распределение ответственности за нарушение срока. Для каждого инцидента, в обработке которого участвовала группа, рассчитывается доля времени (ti/Ti), которое группа потратила на его обработку. Эта доля учитывается при определении степени ответственности группы за просрочку. Если инцидент просрочен, то штрафное значение для KPI распределяется между всеми участвовавшими группами пропорционально их доле в общем времени обработки (ti/Ti). Таким образом, чем больше группа «задержала» инцидент, тем более значительным будет снижение её KPI.