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

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

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

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

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

Повторная обработка инцидента отрицательно сказывается на результате метрики результативности. Чем больше количество инцидентов (M), которые потребовали повторной обработки конкретной группой, тем ниже значение KPI результативности, так как метрика рассчитывается как 1 — (M / N), где N — общее количество инцидентов с участием группы. Таким образом, повторные обработки напрямую снижают показатель результативности и показывают, что группа не смогла завершить задачу полностью и корректно с первого раза.

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

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

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

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