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

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

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

В ITIL за разные аспекты процесса отвечают следующие роли: 1. Дизайнер (технолог/проектировщик процессов): определяет назначение процесса – его базовую функцию в общей процессной модели. 2. Владелец процесса: формирует и актуализирует цели процесса в формате SMART, привязанные к конкретным периодам времени. 3. Менеджер процесса: определяет задачи процесса, обеспечивающие выполнение назначения и достижение целей, и отвечает за оперативное управление процессом. Каждая роль фокусируется на своём уровне детализации: дизайнер на стратегическом, владелец на тактическом, менеджер на оперативном.

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

Чтобы проверить систему на наличие ненужных показателей, необходимо убедиться, что каждый показатель напрямую связан с конкретной целью и используется для принятия решений. Если на вопрос «Зачем это измеряется?» нет чёткого ответа, такой показатель, вероятно, лишний. Также важно проверять, влияет ли показатель на поведение сотрудников в нужную сторону и можно ли его достаточно точно измерить без риска фальсификации.

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

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

В традиционной системе KPI, где оценка основана только на соблюдении максимального времени Tmax, решение инцидента сразу перед истечением срока (например, за 3 часа 55 минут при Tmax = 4 часа) дает полный балл. Это создает обратную мотивацию — исполнители могут откладывать решение до последнего момента, не стремясь к оперативному восстановлению сервисов, что приводит к ненужным простоям и ущербу для бизнеса, хотя формально все нормативы соблюдены.

Событие не считается инцидентом в ITIL, если оно связано с плановыми работами, такими как техническое обслуживание или обновления, которые были заранее согласованы и объявлены пользователям. Например, если печать документов недоступна из-за запланированных работ с сетевым принтером, это не классифицируется как инцидент. Однако, если пользователь не был уведомлен о таких работах, возникает вопрос о качестве коммуникации, который может потребовать отдельного рассмотрения.