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

Управление проблемами и время решения инцидентов

Задача сокращения среднего времени решения инцидентов стоит перед многими руководителями. На традиционный вопрос «Как сделать так, чтобы инциденты решались быстрее?», есть не менее традиционный ответ «Давайте проанализируем, где теряется время». Здесь работает простая аналогия с подходом к сокращению затрат: начать надо с выявления наиболее затратных областей. Именно там усилия по сокращению затрат могут принести наибольшие результаты.

Где же искать ответ? В книге ITIL Service Design в главе про управление доступностью есть любопытный раздел «Expanded incident lifecycle». Это метод, описывающий основные этапы решения инцидента с целью последующего анализа, за счёт чего можно сократить время обработки на каждом из этапов – быстрее выявлять инцидент, быстрее выполнять диагностику и так далее. Кроме того, в ITIL Service Operations конечно говорится о том, что косвенное влияние на сокращение времени решения инцидентов оказывает управление проблемами – за счёт определения наиболее эффективных обходных решений повторяющихся инцидентов. Но, как мне кажется, влияние управления проблемами на скорость решения инцидентов весьма недооценено.

Вот иллюстрация. Пусть у нас есть инженер второй линии поддержки, который в среднем тратит на решение одного инцидента 20 минут. Для простоты предположим, что он в основном занят именно устранением инцидентов. Тогда за 8 рабочих часов он теоретически может решить до 24 инцидентов. И если бы они поступали равномерно и последовательно, то при количестве инцидентов от 1 до 24 среднее время решения оставалось бы равным 20 минутам, что очень хорошо. Но дело в том, что они поступают неравномерно (вспомните стохастические отклонения у Голдратта). Распределение инцидентов по времени дня обычно имеет вид кривой с одним или двумя пиками (отчего она называется верблюдом) с большей нагрузкой в первой половине дня. Это значит, что вновь поступающие инциденты будут попадать в очередь и ждать, пока инженер разрешит инциденты, открытые ранее. В наихудшем случае (если все инциденты пришли одновременно утром) это приведёт к среднему времени решения … 4 часа 10 минут. Те же самые 24 инцидента! А если бы инцидентов за день приходило не 24, а 12? Тогда с теми же показателями производительности (в наихудшем предположении, что все инциденты пришли одновременно) среднее время решения будет только 2 часа 10 минут. То есть в два раза меньше.

Отсюда вывод, что из-за неравномерности поступления инцидентов, их среднее время решения зависит не только от производительности персонала (а значит эффективности выявления, диагностики и так далее), но и от общего количества инцидентов. Я не знаю, как управлять равномерностью поступления инцидентов. Но знаю, как сокращать их количество – за счёт организации и исполнения процесса управления проблемами.

Да, это непростой процесс. Прежде всего, по двум причинам:

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

Но это очень важный процесс. В нашей проектной практике мы обычно рекомендуем закладывать его основы сразу при организации управления инцидентами, не дожидаясь накопления «волшебной» статистики по инцидентам за год. Ценность такой статистики для выявления проблем, по-моему, сильно преувеличена. А вот влияние процесса управления проблемами на скорость решения инцидентов – напротив – недооценено.

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

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

  • Nargiza Suleymanova

    “..не дожидаясь накопления «волшебной» статистики по инцидентам за год. Ценность такой статистики для выявления проблем, по-моему, сильно преувеличена.”
    Полностью согласна, за год статистика в реале не нужна. Достаточно периода от 2 недель до 3-х месяцев, в зависимости от критичности/повторяемости инцидентов.

    “А вот влияние процесса управления проблемами на скорость решения инцидентов – напротив – недооценено.”
    Я вам более скажу, очень полезно совмещать роли инцидент и проблем менеджера. Хотя меня тут уже критиковали за подобную “ересь”.

    • “Достаточно периода от 2 недель до 3-х месяцев, в зависимости от критичности/повторяемости инцидентов.”

      И даже это необязательно. Для того, чтобы процесс начал работать, достаточно подать на вход десяток проблем. Уверен, TOP 10 проблем менеджеры в состоянии просто взять и перечислить без всякой статистики по инцидентам. Пока процесс переваривает эти проблемы, начнёт набираться статистика по инцидентам. К PRB долго привыкают (статистика по инцидентам копится быстрее), поэтому привыкать лучше заранее.

      “Я вам более скажу, очень полезно совмещать роли инцидент и проблем менеджера”

      Я думаю не стоит давать такой совет как общеупотребительный. Такое совмещение ролей возможно, но его успешность сильно зависит от конкретного исполнителя. То есть это риск, на который надо идти разумно, с открытыми глазами. У Вас работает – прекрасно, респект Вам, как менеджеру. Но это не значит, что заработает у остальных.

      • Nargiza Suleymanova

        “И даже это необязательно. Для того, чтобы процесс начал работать, достаточно подать на вход десяток проблем.”
        Озвучить текущие проблемы-да, достаточно просто спросить у менеджеров, но вот инициировать по ним работу, тут уж статистика по инцидентам становится нужной.

        “Я думаю не стоит давать такой совет как общеупотребительный. Такое совмещение ролей возможно, но его успешность сильно зависит от конкретного исполнителя.”
        Радует уже то, что кто-то соглашается, что подобное совмещение возможно 🙂

      • Pavel Solopov

        Уверен, TOP 10 проблем менеджеры в состоянии просто взять и перечислить без всякой статистики по инцидентам.

        А почему бы тогда не взяться и не решить эти проблемы безо всякого процесса? Ведь как Вы сами же пишите “многие проблемы для диагностики и решения требуют не просто поочерёдной работы нескольких команд”. Т.е. каждая проблема это своего рода проект, подход к которому должен быть индивидуальный. И навряд ли в регламенте процесса дело пойдёт дальше общих слов “собрать рабочую группу”.
        Я уверен, что менеджеры к ТОР 10 проблем смогут добавить ещё и ТОР 10 причин, почему эти проблемы до сих пор не решены.

        Сомневаюсь, что управление проблемами значительно улучшит дело с решением хронических проблем, ценность управления проблемами в оперативном выявлении и устранении “текущих (операционных)” проблем.

        • “А почему бы тогда не взяться и не решить эти проблемы безо всякого процесса?”

          Это целиком определяется тем, какую задачу Вы перед собой ставите, как ИТ-руководитель. Если “решить 10 проблем”, то действительно процесс может быть избыточен. Вместо процесса управления проблемами можно организовать “проект решения проблем”. Аналогично можно подойти к решению инцидентов и реализации изменений – выбрать TOP 10 и решить/реализовать 🙂 Если Вы увидите задачу немного повыше, то ситуация, я уверен, изменится.

          • Pavel Solopov

            Вы меня не совсем верно поняли, точнее поняли лишь отчасти.
            Основной мой посыл в том, что полезность управления проблемами в оперативном выявления вновь возникающих проблем и столь же оперативном их решении.
            А если есть какие-то “хронические” проблемы о которых все давно знают, но до сих пор не решили, то навряд ли они решатся, если вы их подадите на вход вновь разработанного процесса управления проблемами. Ибо их решение кроется в нежелании или невозможности их решать, а вовсе не в отсутствии регламента организации рабочей группы по их решению.

            • “Ибо их решение кроется в нежелании или невозможности их решать, а вовсе не в отсутствии регламента организации рабочей группы по их решению.”

              Если речь о нежелании, то процесс помочь может. Потому что нежелание исполнителей можно преодолеть только пинками руководителей. Но они, как правило, носят нерегулярный характер (потому что руководитель не может помнить обо всех задачах всех подчиненных). Процесс эту деятельность наконец-то может организовать системно, обеспечив регулярный контроль. Что касается невозможности, то выше головы, конечно, не прыгнешь. Но и невозможность на поверку часто превращается в пункт 1 – в нежелание шевелить головой и руками. Любой разумный руководитель на ответ “Это невозможно, потому что …” спросит “ОК, а что возможно сделать в рамках имеющихся ограничений?” (по времени, людям, деньгам, …). Это поворачивает разговор в плоскость поиска возможностей, что гораздо продуктивнее.

              • Pavel Solopov

                Если нежелание у исполнителей, то несомненен, процесс как-то их может растолкать.
                Но даже если есть нежелание у исполнителей, то ТОР 10 проблем могут быть решены на инициативе руководителя, уж десяток проектов он в силах запомнить, наверное.

                Любой разумный руководитель на ответ «Это невозможно, потому что …» спросит «ОК, а что возможно сделать в рамках имеющихся ограничений?» (по времени, людям, деньгам, …). Это поворачивает разговор в плоскость поиска возможностей, что гораздо продуктивнее.
                И опять же, что мешает задавать такой вопрос не имея процесса? Или вы не к тому?

                • “И опять же, что мешает задавать такой вопрос не имея процесса?”

                  Только то, что при таком подходе очень много оперативных задач концентрируется на очень небольшом числе управленцев, отнимая у них время на то, чтобы заниматься развитием, работой с персоналом и другими перспективными задачами. А остается времени и сил только на то, чтобы помнить и пинать. Для руководителя стремление уйти от такой ситуации – один из значимых драйверов организовывать работу с бОльшим вовлечением в управление менеджеров среднего звена. Так мы учимся переходить от TOP10 (а таких “топов” по разным направлениям деятельности у нас очень много, не только TOP10 проблем, верно?) к регулярным процессам.

                  “Или вы не к тому?”

                  Конечно, не к тому. Пост был не про процессный подход в целом, а про вполне конкретный вопрос влияния процесса управления проблемами на казалось бы смежную область. И TOP10 был упомянут только как “первая пища” для процесса, а не как способ организации деятельности.

                  • Pavel Solopov

                    ТОР 10 проблем, может оказаться той пищей, которая встанет поперёк горла процессу-младенцу. 🙂

  • Maxim Luzin

    А можно поподробнее что вы вкладываете в понятие “основы [управления проблемами]”, которые закладываются сразу при организации управления инцидентами?

    • Реактивное управление проблемами. Меньше акцент на выявление проблем, больше – на обработку проблем и известных ошибок. В частности такой акцент делается потому, что большинство заказчиков довольно быстро осознают необходимость обработки проблем/ошибок после закрытия инцидента. Процесс регламентируется, автоматизируется, запускается, попадает в цикл оценки и совершенствования процессов.

  • Konstantin G

    Интересный цикл жизни инцидента на рисунке. Все заканчивается Restore. Как я понимаю, это восстановление работоспособности. А предполагается ли в этом жизненном цикле закрытие инцидента? И должен ли в этом жизненном цикле быть анализ причин инцидента? Или решение инцидента не подразумевает анализ и указание причин его возникновения? Закрыли, забыли…


Добавить комментарий

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM
;