PRB (Problem Review Board) необходим для обсуждения сложных проблем с участием экспертов, но его роль не сводится к реакции на major-инциденты. PRB анализирует глубинные причины, планирует стратегии решений и утверждает временные обходные пути. Ошибочное применение PRB только после критических инцидентов (вместо регулярного анализа) искажает процесс — PRB должен функционировать как постоянно действующий орган для координации сложных проблем, а не как экстренная группа.

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

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

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

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

В ITIL проблема — это причина или потенциальная причина одного или нескольких инцидентов, тогда как инцидент — это сам факт незапланированного прерывания услуги. Пример: если пользователь не может распечатать документ (инцидент), то проблемой может быть конфликт драйвера сетевого принтера с диспетчером печати Windows, который привел к этому инциденту. Проблема требует анализа для выявления корневой причины, чтобы предотвратить повторение инцидентов.

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

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

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

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