Портал №1 по управлению цифровыми
и информационными технологиями

Когда Problem Management – проблема.

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

Problem

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


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

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

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

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

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

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

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

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

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


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

«VAP: Управление поддержкой ИТ-услуг»
Строим эффективную ИТ-поддержку, оптимизируем существующую

Комментариев: 8

  • Корскаков Арём

    Как вы считаете, насколько разумен хрестоматийный триггер “не удаётся соотнести инцидент с существующими проблемами и известными ошибками” для регистрации проблемы в реальной практике? Ведь не все инциденты, которые не могут быть соотнесены с проблемами, требуют выяснения корневой причины и должны направляться в управление проблемами. Если следовать этому триггеру, то для каждый рядовой инцидент будет порождать запись о проблеме. Но ведь эти инциденты исчерпываются в управлении инцидентами и анализировать, почему стёрлось фото на смарт-карте, стало западать колесо прокрутки мыши или вышел из строя не HDD на ноутбуке сотрудника не целесообразно.

    • Вполне разумный и используемый в некоторых компаниях триггер. Возможно, даже кто-нибудь из читающих признается 😉
      По-моему, этот вариант триггера имеет смысл воспринимать следующим образом.
      Если мы поклонники детерминизма 🙂 , то верим в то, что у каждого инцидента есть причина (aka проблема). Так что, если разберёмся с проблемой, то исключим повторение инцидента, ею вызванного. Но, как Вы правильно заметили, разбираться с каждой проблемой может быть нецелесообразно.
      Такой сценарий возможен, думаю, в одном из двух случаев.
      1. У нас всё настолько хорошо в смысле качества всего ИТ-шного хозяйства, включая наличие ресурсов (т.е. и ломается не сильно часто и есть возможность поразбираться с каждым сбоем), что работа ИТ переходит на качественно новый уровень. Пофантазировав можно представить, что при дальнейшем совершенствовании в этом направлении в теоретическом пределе управление инцидентами, страшно сказать, вообще будет не нужно. Работа сведётся к спокойной, плановой работе в рамках проактивного управления проблемами. То есть, будем выявлять и устранять проблемы ДО того, как они смогут проявиться инцидентами.
      2. Мы определяем определённый фильтр (например, экспертная оценка сочетания повторяемости и влияния инцидента) для того, чтобы не плодить работы в PRB, не ведущие к значимому с точки зрения влияния на бизнес результату.
      Альтернатива – подобная фильтрация на входе процесса PRB (как в классике).

      • Корскаков Арём

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

        • Если под классикой понимаем ITIL, то имеет смысл обратить на следующие места в книге Service Operation
          1. «Закрытие инцидента» [4.2.5.9], пункт «Ongoing or recurring problem?»
          2. «Обнаружение проблемы» [4.4.5.1], описание триггеров реактивного управления проблемами
          Подробностей там нет, поскольку таких деталей в каждой области довольно много. Потому и обсуждаем такие вопросы и на портале, и на курсах, чтобы дополнить рекомендации ITIL деталями, которые могу возникнуть на практике.

          Если в практике управления инцидентами нет доступа к информации о проблемах (в частности, к KEDB), то выполнение обсуждаемой процедуры вообще невозможно, насколько я понимаю. Т.е. вопрос о работоспособности такого триггера снимается автоматически.
          Кстати такой случай (отсутствие процессе управления инцидентами информации о проблемах) описывается в разделе «Трудности и риски» и по процессу управления инцидентами [4.2.9] и по процессу управления проблемами [4.4.9].

          • Корскаков Арём

            Спасибо. Мы наконец согласовали свои триггеры регистрации проблем.
            Если мы исходим из позиций детерминизма, не кажется ли вам абсурдным такой, например, триггер, как: “Analysis of an incident by a support group which reveals that an underlying problem exists, or is likely to exist”, который упоминается в разделах [4.4.4.2] и [4.4.5.1]? Согласно определению из глоссария ITIL проблема — это причина одного или нескольких инцидентов. Здравый смысл нам подсказывает, что у каждого инцидента есть причина, то есть underlying problem exists априори, не зависимо от того, обнаружит это группа тех-поддержки в ходе анализа или нет.
            В эту же копилку падает триггер: “Suspicion or detection of a cause of one or more incidents by the service desk, resulting in a problem record being raised”.

            • Артём, нет, абсурдным не кажется.
              Потому как, «знать (путь даже точно), что причина есть» и «заниматься её поиском и устранением» – это, как говорят в Одессе, две большие разницы, если мы включим в уравнение деньги.

              Если мы хотим обеспечить не только эффективное, но и рациональное предоставление услуг (что означает, что и к процессам мы предъявляем такие же требования), то вполне вероятны (и в жизни встречаются) ситуации, когда мы не будем заниматься поиском причины сбоя(и), несмотря на то, что сбои, вызываемые этой причиной, могут иметь или уже имеют негативное влияние на бизнес.
              Например, потому, что затраты (в общем смысле) на поиск и устранение могут быть несопоставимы с негативным влиянием. И мы продолжаем «перезагружать (вместо поисков причины зависания)». Или, например, потому, что мы «скоро переезжаем, так что капающий кран ещё две недели потерпим 🙂 ».

              С учётом этого, фраза «Analysis of an incident by a support group which reveals that an underlying problem exists, or is likely to exist», как мне кажется, необязательно означает, что support group не является сторонником детерминистического подхода. Это может означать и то, что в некоторых случая, понимая, что причина есть всегда, решение о том, что надо бы ею позаниматься, support group будет принимать не всегда. Т.е., по-моему, фразу имеет смысл воспринимать так: «анализ показывает, что причиной имеет смысл позаниматься».

              Вторая процитированная фраза, действительно, в «эту де кпоилку». Т.е. пояснения по ней ровно такие же.

            • Да! И про определение термина “проблема”.
              Нужно помнить, что в нём не остаётся места для проактивного управления проблемами (что бы это ни было – отдельная процедура в процессе, отдельный процесс или часть CSI [мы тут как раз на днях эту тему обсуждали]).

              • Корскаков Арём

                Спасибо за обогащение понимания ITIL осмысленными интерпретациями!


Добавить комментарий для Корскаков АрёмОтменить ответ

Ваш адрес email не будет опубликован. Обязательные поля помечены *

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM