В очередной раз в обсуждении с заказчиком я сталкиваюсь с серьёзным непониманием отличий процесса управления проблемами от управления инцидентами. Корневых причин такого непонимания (простите за каламбур) я вижу две: невнятный текст про взаимодействие этих процессов в книгах ITIL (в частности, однозначная рекомендация привлечения PRB к решению major-инцидентов) и отсутствие специфичных алгоритмов обработки проблем в средствах автоматизации процессов ITSM, по которым зачастую осознают процессы как заказчики, так и консультанты.
Размышляя об этом явлении, хотел бы сформулировать основные отличия этих процессов. Главный тезис заключается в том, что процесс управления проблемами – это не «медленный» инцидент-менеджмент и не «другой» инцидент-менеджмент, который работает по отношению к наиболее страшным инцидентам и так далее. Это совсем другой процесс. Отличия начинаются с разницы в назначении процессов (этот факт известен всем), но на этом не заканчиваются. Вот ключевые отличия от управления инцидентами в организации деятельности:
- Определение сроков. В отличие от инцидента, у проблемы нет единого срока устранения, и в общем случае он не может быть определён (тем более при регистрации проблемы). Вместо этого есть сроки обработки проблемы на различных этапах – диагностика, решение и так далее. Часть этих сроков может быть нормирована, часть – является результатом планирования (например, срок решения проблемы может определяться по результатам планирования изменения, необходимого для решения проблемы).
- Обработка известных ошибок. В отличие от инцидентов, которые должны быть устранены как можно быстрее любым приемлемым способом, управление проблемами регулярно сталкивается с ошибками, которые определены, но не могут быть сразу устранены. Поэтому процесс управления проблемами должен организовывать деятельность по контролю известных ошибок, которая управлению инцидентами абсолютно не свойственна.
- Триггеры процесса. Если управление инцидентами в основном запускается пользователями (внешним триггером) и они не заставят себя ждать, процесс управления проблемами сам собой работать не начнёт, если не определить способы порождения проблем и не контролировать, что эти способы применяются.
- Ролевая структура. Серьёзное отличие от управления инцидентами – необходимость диагностирования проблем с привлечением различных групп специалистов. Это приводит к необходимости назначения координаторов отдельных проблем, что в целом для управления инцидентами нехарактерно (пожалуй, за исключением MIM). Процесс также должен определять порядок контроля деятельности координаторов проблем.
- Метрики. Забудьте о метрике «доля своевременно решённых проблем», это метрика инцидент-менеджмента. У процесса управления проблемами своя логика работы и свои метрики (см., например, здесь).
Про проактивное управление проблемами даже не упоминаю. В первую очередь потому, что проактивное управление проблемами – суть тактический процесс, стоящий рядом с управлением мощностями и доступностью. Это совсем не просто «довесок» к реактивному управлению проблемами, и я склонен выделять их в разные процессы.
Готов дискутировать с несогласными.
Дима, ты даже не представляешь, как мы согласны 🙂