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

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

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

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

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

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

CMDB (Configuration Management Database) играет ключевую роль в оценке влияния major-инцидента на ИТ-услуги. С её помощью можно определить, каким пользователям и сервисам оказывается воздействие и насколько оно критично, что позволяет целенаправленно информировать затронутые группы и правильно оценивать последствия инцидента. Данные CMDB помогают установить причинно-следственные связи между компонентами ИТ-инфраструктуры и конечными сервисами, обеспечивая более точное управление инцидентом и снижение времени реагирования.

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

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

Для определения истинной корневой причины с использованием метода 5-Why's необходимо последовательно задавать вопрос «почему» к каждому выявленному симптому, формируя цепочку причинно-следственных связей. Метод предполагает, что после пятого уровня анализа будет обнаружена глубинная причина. Однако на практике решающее значение имеет не количество шагов, а достижение точки, где поставщик услуг может повлиять на решение. Например, при анализе принтера анализ останавливается на уровне устаревшей подстанции, так как дальнейшие действия выходят за рамки ответственности поставщика.