Смартсорсинг.ру

Сообщество руководителей ИТ-компаний, ИТ-подразделений и сервисных центров

Статьи в блогах Вопросы и ответы Темы в лентах Пользователи Компании Лента заказов Курс по ITSM

KPI для управления проблемами

KPI для управления проблемами

Измерить эффективность процесса управления проблемами бывает достаточно сложно. Сложность еще и в том, что эффективность управления проблемами во многом зависит от зрелости других процессов, например, от того, как регистрируются инциденты. Если доверить формирование KPI бизнес-руководству, то можно получить самые неожиданные показатели. Попробуйте отчитаться о «количестве инцидентов в прошлом месяце, предотвращенных благодаря управлению проблемами».

Вот некоторые действительно полезные индикаторы для управления проблемами.

  • Количество зарегистрированных проблем
  • Количество разрешенных проблем
  • Количество и процент проблем у которых выявлена основная причина
  • Количество и процент проблем для которых найдено обходное решение
  • Средний возраст проблемы, по степени воздействия на бизнес
  • Процент инцидентов относящихся (вызванных) к известным проблемам по отношению к общему количеству инцидентов за период
  • Частота обновления известных проблем

Частота обновления — особо полезный показатель на ранних этапах управления проблемами, показывающий регулярность работы над анализом проблем. Для того, чтобы процесс был эффективным нельзя вечно откладывать работу. В то же время с проблемами именно это часто и происходит, особенно когда сотрудники полностью поглощены другими более срочными и актуальными задачами. В итоге многие компании, зная о пользе управления проблемами, не могут найти на него время из-за большого количества инцидентов.  Закрыть инцидент — доблесть, решить проблему — оставить себя без работы. Естественно, что без эффективных KPI, заставляющих концентрироваться на разрешении проблем, сотрудники занимаются этой работой в последнюю очередь.

Наличие KPI определяют эффективность и качество процесса управления проблемами. Правильные KPI помогают, как концентрироваться на поиске решения  известных проблем, так и на выявлении причин инцидентов и открытии новых проблем. По идее также работают «палки» в милиции/полиции, впрочем там как раз выбраны не лучшие варианты KPI.

И нужно помнить о том, что эффективное управление проблемами может быть только в тесном сотрудничестве со службой Service Desk. Именно у SD есть все необходимые данные об инцидентах, необходимые для анализа и выявления проблем.

По материалам itsmperfection.com

Дополнительные материалы

Комментарии (17)

  • Аватар

    Занегин Дмитрий [Dimazan], 09 июня 2011, 02:36

    2
    По моему в статье изначально ошибочные исходные данные. KPI не может формировать человек не разбирающийся в процессе. Будь то бизнес-руководство или кадровое-руководство или ... Если процесс оценивает человек не понимающий в нем, то результат будет, в лучшем случае, так себе. Глухой может отрегулировать громкость музыки "по приборам", но не сможет отличить красивую музыку от какофонии.
    Бизнес = потребности = SLA.
    SLA = набор сервисов и их стоимости (для бизнеса) = доход IT (затраты на входящие сервисы, оборудование и зарплаты сотрудников IT). Относительный доход IT падает в силу инфляции (это около 20% в год) и в силу отказа бизнеса от более не нужных сервисов и растет при внедрении новых сервисов. Плюс абсолютный доход IT растет в силу роста стоимости входящих сервисов (но для IT это не доход, а средства проходящие "сквозь" IT).
    Как следствие, IT заинтересованы находить новые сервисы полезные для бизнеса (иначе их бизнес просто не примет) = развитие IT и компании (бизнеса). Старые сервисы для бизнеса становятся все дешевле и дешевле (чему бизнес только рад), но без новых сервисов это стагнация (застой).
    Естественно IT не заинтересованы в отказе от старых сервисов (пусть копеечка, но капает исправно), и тут бизнес должен "думать".
    Пример: Бумажный документооборот => много принтеров и медленная работа с документами. Внедряем электронный документооборот => работа с документами существенно быстрее. Но IT не заинтересовано в демонтаже 50% принтеров (для чего?!). И тут бизнес должен сам от них отказаться. Для бизнеса, на начальном этапе, затраты возрастут (надо оплачивать новый сервис), но потом бизнес выйграет в скорости работы (конкурентное преимущество) и в затратах на бумагу, расходники и оплату IT содержания большого парка принтеров.
    А если KPI уже кем-то написаны и там нет ни слова об электронном документообороте, то для чего IT прорабатывать этот вопрос? Из любопытства? Из любви к новинкам? Слабенький мотиватор. Скорее всего "ковырять" такие системы IT-шники будут, из любознательности, но внедрять в бизнес - навряд ли (плюсов для IT нет, а по голове, если что не так, получить можно).
    IMHO KPI для IT должен писать IT директор (или его аналог) и постоянно корректировать (исходя из текущей ситуации). Для HR директор по персоналу и т.д.

    Удачи нам,
    ребята!
  • Аватар

    Яковлев Андрей Михайлович [swtws], 09 июня 2011, 17:57

    0
    Перечисленно 7 KPI на 1 процесс - это слишком много, столько никто не осилит в отчете, уважайте время менеджеров. Такие советы дают консультанты и прочие словоблуды продавцы. Кто-нибудь реально по 20 KPI с оценкой SQI работал? Из практики - половина KPI "внедрены" менеджером проекта для подчеркивания собственной значимости.
  • Аватар

    Peshkov Alexander [PA], 09 июня 2011, 23:07

    0

    Возможно, самый важный KPI в этом процессе - это кол-во инцидентов?

  • Аватар

    Яковлев Андрей Михайлович [swtws], 09 июня 2011, 23:49

    0
    Нет. Тут причинно-следственная связь другая - большое число повторяющихся инцидентов указывает на возможную проблему. Важно общее число проблем и процент решенных. Метрики по числу основных причин и обходных решений тогда избыточны, управление проблемами, в отличие от управления инцидентами корневую причину и ищет, обходы нужны именно в управлении инцидентами, где все решает срочность.
  • Аватар

    Рубинштейн Кирилл [krubinshteyn], 10 июня 2011, 12:38

    0
    Не устану повторять, что Управление проблемами — это вообще процесс с натяжкой. Точнее, как процесс он в большинстве случаев и не нужен, а если и нужен — то только с поверхностно описанными "чекпойнтами". Самое важное, чтобы у ИТ-руководства было понимание того, что управлением проблемами нужно заниматься — анализировать инциденты, выявлять связь, фиксировать проблему и планировать её решение. Для этого многотомные мануалы и KPI не нужны. Особенно в ИТ-службах на 20 человек, где ИТ-руководитель непосредственно контролирует всю операционную деятельность (иногда у него есть руководитель helpdesk-а, которому делегируется управление инцидентами).
    • Аватар

      Солопов Павел [PaSol], 21 июня 2011, 13:05

      0
      А почему процесс с натяжкой? Повторите, будьте добры, я первый раз слышу.
      • Аватар

        Рубинштейн Кирилл [krubinshteyn], 21 июня 2011, 13:07

        0
        В том смысле, что в управлении проблемами меньше процессной составляющей, нежели идейной, что процессом этим нужно заниматься вообще.
        • Аватар

          Солопов Павел [PaSol], 21 июня 2011, 13:21

          0
          Как-то туманно опять же...
          Может всё зависит от подхода к процессу, может надо определить его периодичность (процессы ведь обладают какой-то периодичночтью, так ведь?).
          И если для управления инцидентами периодичность может составлять часы и минуты (с появлением нового инцидента запускается новый экземпляр процесса), то у управления проблемами периодичность может равняться месяцам.
          • Аватар

            Рубинштейн Кирилл [krubinshteyn], 21 июня 2011, 13:59

            0
            Я тогда даже и не знаю, как сформулировать. Вобщем, для внедрения процесса управления проблемами процессные консультанты нужны меньше всего. Как-то так.
            • Аватар

              Солопов Павел [PaSol], 21 июня 2011, 14:13

              0
              Да почему? Не пойму я никак. :-)
              Вы хотите сказать, что в решении проблем нет повторяемости, что какждый раз это некая уникальная деятельность. Т.е. каждая проблема это как бы проект и нет смысла пытаться свести всё к общему процессу?
            • Аватар

              Солопов Павел [PaSol], 21 июня 2011, 14:14

              0
              А нужны ли процессные консультанты для процесса бюджетирования, например?
              • Аватар

                Рубинштейн Кирилл [krubinshteyn], 21 июня 2011, 14:19

                0
                Так, видимо у нас разные словари терминов :)

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

      Солопов Павел [PaSol], 21 июня 2011, 13:10

      0
      "Для этого многотомные мануалы и KPI не нужны."

      Насчёт KPI, возможно вы и правы, а насчёт мануалов не соглашусь с Вами. Например, Cisco в сертификации отдельно выделяет такую тему, как траблшутинг. Дело в том, что выявление проблем не простая задача, хотя надо признать, что её решение лежит не столько в процессной области, сколько в области технологической методологии.
      • Аватар

        Рубинштейн Кирилл [krubinshteyn], 21 июня 2011, 13:11

        0
        Это уже немного другого рода мануал (инструкция по выявлению проблем) -- против таких я ничего против не имею :). Чем больше, тем лучше. Как вы правильно сказали -- тут речь о технической методологии.
        • Аватар

          Солопов Павел [PaSol], 21 июня 2011, 13:22

          0
          Беда в том, что о ней-то сейчас думать и не принято. Все увлечены процессами и сервисами, как будт-то это отменяет необходимость "крутить гайки".

Также рекомендуем