Нет, не нужно. Несмотря на то, что в процессе обработки инцидента (Incident handling and resolution) в ITIL 4 приоритизация не упоминается как отдельный шаг, она остается важным компонентом практики управления инцидентами. Приоритизация рассматривается как сквозной процесс и включена в факторы успеха практики, необходимые для минимизации негативного влияния инцидентов. Организациям не нужно выбрасывать текущие ITSM-системы или кардинально менять процессы — можно продолжать использовать приоритизацию как часть управления инцидентами, но принять более гибкий подход, когда приоритеты могут пересматриваться несколько раз в течение жизненного цикла инцидента.

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

ITIL рекомендует формулировать требования к срокам через конкретные даты и оценку влияния на бизнес. Например, вместо «это срочно» бизнес должен указать: «изменение нужно внедрить до 15 сентября, иначе будет потеряно 100 клиентов». Такой подход устраняет субъективность и позволяет ИТ-команде спланировать загрузку. Для emergency-изменений сроки определяются критичностью инцидента: если сервис недоступен, решение нужно «до восстановления сервиса», что фиксируется в метриках времени восстановления (MTTR).

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

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

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

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

Относительные приоритеты бизнеса учитываются при расчете общего показателя качества через использование весовых коэффициентов. Например, при объединении показателей из различных групп услуг (mission-critical, business-critical и обычные) каждой группе присваивается вес, отражающий ее степень важности для бизнеса. При расчете общего интегрального показателя эти веса учитываются в формуле, например, при вычислении взвешенного среднего арифметического. Если mission-critical услуги имеют вес 0.5, business-critical — 0.3, а обычные — 0.2, то их показатели будут пропорционально учитываться в общем результате. Это позволяет управлять акцентами в оценке и более точно отражать стратегические приоритеты бизнеса.

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

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