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

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

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

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

Шаг Plan (Планируй) в цикле Деминга предполагает разработку плана улучшений, формулировку гипотез и определение метрик для измерения результатов. В то время как шаг Act (Корректируй) сосредоточен на принятии решений относительно дальнейших действий после анализа результатов проверки (Check). Act включает либо внедрение успешных улучшений в постоянную практику, либо игнорирование неудачных результатов, либо запуск цикла заново с учетом накопленного опыта. Таким образом, Plan направлен на планирование изменений, а Act — на определение дальнейшего развития процесса после реализации и оценки этих изменений.

При практическом применении метрик FLR и FCR часто возникают две основные проблемы. Первая связана с излишней задержкой обращения на первой линии – сотрудники могут удерживать звонок слишком долго в попытке разрешить максимальное количество обращений. Вторая и более сложная проблема заключается в правильном определении значения N для расчёта – общего количества релевантных обращений, так как часть заявок физически невозможно решить на первой линии из-за ограничений регламентов, политик или отсутствия необходимого уровня доступа у сотрудников первой линии.

Проактивное управление проблемами напрямую связано с минимизацией негативного влияния на бизнес следующим образом: 1) Предотвращение инцидентов - выявляя и устраняя потенциальные проблемы до их превращения в инциденты, проактивная работа предотвращает простои и сбои в предоставлении услуг, что напрямую сохраняет бизнес-процессы в работоспособном состоянии. 2) Минимизация скрытых потерь - многие проблемы до своего проявления в виде инцидентов уже оказывают негативное влияние на бизнес в форме снижения производительности, увеличения времени обработки запросов, ошибок в данных. Проактивное управление выявляет и устраняет эти скрытые проблемы. 3) Улучшение репутации - регулярное предотвращение проблем демонстрирует клиентам и внутренним стейкхолдерам надежность поставщика услуг, укрепляя доверие к организации. 4) Снижение затрат на исправление - предотвращение проблемы всегда дешевле, чем устранение ее последствий, особенно когда это связано с срочными исправлениями и работой в аварийном режиме. 5) Раннее выявление системных проблем - анализ трендов и потенциальных слабых мест позволяет обнаружить глубинные системные проблемы до того, как они превратятся в серьезные инциденты. 6) Оптимизация ресурсов - сосредоточение на проактивной работе позволяет более рационально распределять ресурсы, выделяя их на предотвращение проблем, а не на ликвидацию последствий. Проактивное управление проблемами фактически переносит фокус с реагирования на инциденты к их предотвращению, что кардинально меняет подход к минимизации влияния на бизнес - вместо минимизации последствий уже произошедших событий мы работаем над предотвращением самих событий.

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

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

Обычно выделяются четыре уровня влияния инцидентов: 1) Максимальный уровень (критический) - когда ИТ-услуга недоступна для всего отдела или компании, что приводит к полной остановке бизнес-процессов. 2) Высокий уровень - когда несколько сотрудников сталкиваются с полным отсутствием функционала. 3) Средний уровень - когда у группы пользователей доступна только часть функционала. 4) Низкий уровень (минимальный) - когда у одного сотрудника недоступна только часть функционала ИТ-услуги. Эти уровни могут варьироваться в зависимости от принятой в организации методологии и дополнительных критериев оценки, таких как VIP-статус пользователей или критичность системы.