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

Необходимо: 1) Чётко разделять сценарии создания инцидентов (внешние сбои) и проблем (анализ корневых причин по группе инцидентов); 2) Внедрить отдельные этапы для проблем (диагностика, утверждение решения); 3) Обучить персонал специфике процессов; 4) Настроить ITSM-систему для поддержки уникальных атрибутов проблем (например, этапы обработки); 5) Ввести метрики, отличные от инцидент-менеджмента. Ключевой момент — не создавать запись о проблеме 'для галочки' после инцидента, а запускать полноценный анализ причин.

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

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

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

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

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

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

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

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