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

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

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

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

Геометрическое среднее более строго учитывает дисбаланс: если одна метрика близка к нулю, итоговый KPI также стремится к нулю, что отражает реальную неэффективность работы. Арифметическое среднее позволяет компенсировать провал по одной метрике успехом по другой, создавая ложное впечатление умеренной эффективности. Например, при K1=90% и K2=10% геометрическое среднее дает 30%, тогда как арифметическое — 50%. Первый вариант лучше стимулирует достижение баланса между скоростью и качеством решения.

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

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

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

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

Заказчики не понимают такой компромисс, потому что ожидают от ITSM гарантии времени разработки новых функций и улучшений. Для них SLA (соглашение об уровне услуг) кажется бессмысленным, если поставщик ИТ-услуг не может обеспечить улучшение существующих возможностей или гарантировать сроки новых разработок. Они задают вопросы вроде: «Зачем мне SLA, если текущая функциональность уже работает, а вы не можете гарантировать её улучшения?»