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

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

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

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

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

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

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

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

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

Nj не может включать все обработанные обращения, потому что в расчёт должна включаться только завершённая работа — обращения, по которым процедура проверки решения полностью завершена. Это могут быть закрытые без рекламаций инциденты или те, которые были возвращены на доработку (Sj). Если включить в Nj все обработанные обращения, в том числе те, где процесс проверки не завершён, это исказит метрику FTR, так как не отразит реальное качество работы группы.