Как понять, что можно существенно улучшить процесс управления проблемами (Problem Management)?

В недавно опубликованном посте «When Problem Management is the Problem» Michael Keeling задаётся вопросом, почему, несмотря на то, что человечество занимается решением проблем всю свою историю, нельзя сказать, что эта практика полностью изучена, освоена и не вызывает вопросов.
Если говорить об ITSM, то, по мнению автора, во многих организациях процесс управления проблемами работает не так, как им хотелось бы. Более того, иногда приглашённые для анализа такой ситуации консультанты приходят к выводу, что реализованный процесс управления проблемами на самом деле является частью проблемы.

Если вы подозреваете, что процесс управления проблемами у вас работает не так, как мог бы, можете воспользоваться коротким списком вопросов, предлагаемых Michael Keeling.

1. Ваш процесс охватывает и проактивный и реактивный Problem Management?

Как пишет автор, если Ваша первая реакция на этот вопрос: «Что значит «проактивный»?», то ответ очевиден. Согласно ITIL, разница между ними в том, что является триггером, запускающим процесс: в реактивном – это, в основном, инциденты; в проактивном – запланированные работы по улучшению сервисов (в частности анализ трендов [например, схожих причин уже произошедших инцидентов]). Таким образом, реактивный problem management дополняет процесс управления инцидентами, тогда как проактивный дополняет работы в рамках CSI [постоянное улучшение сервисов]).

2. Когда у Вас запускается процесс управления проблемами?

Michael Keeling указывает на то, что рекомендуемое ITIL разделение процессов управления инцидентами и управления проблемами некоторые понимают слишком буквально, считая, что пока сервис не восстановлен, процесс управления проблемами не может начать работу. На самом деле в книге ITIL Service Operation явно указано, что запуск процесса управления проблемами во время инцидента – это решение которое принимает каждая организация для себя. Наиболее распространённый случай, когда такая ситуация неизбежна, – не удаётся соотнести инцидент с существующими проблемами и известными ошибками.

3. Вы обучили сотрудников производить анализ?

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

4. Про известные ошибки (known errors, KE) и обходные решения (workarounds, WA).

В этом пункте Michael призывает не переусердствовать в следовании принципу ITIL, согласно которому для регистрации KE необходимо зафиксировать причину проблемы и задокументировать обходное решение. Отсутствие абсолютной необходимости в «формальном» обходном решении для регистрации KE автор обосновывает тем, что почти всегда есть какое-то обходное решение (в противном случае нам пришлось бы признать, что мы не можем решить инцидент… даже временно, что в нормальной ситуации является редким явлением). Т.е. если мы можем восстановить сервис, предлагается документировать KE.

Разумеется, на полноценный check-list данный список не претендует. Но, возможно, какие-то из  вопросов позволят найти в своём процессе «точки роста»
Интересно, какие решения в перечисленных областях приняты у вас?

ИНТЕНСИВ С ТРЕНЕРОМ

VAP: Управление поддержкой ИТ-услуг

Строим эффективную ИТ-поддержку, оптимизируем существующую