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

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

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

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

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

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

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

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

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

kpi, управление проблемами

+ 0 —

Бычков Валерий [vbychkov], 08 июня 2011, 15:57

()

Комментарии (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 в этом процессе - это кол-во инцидентов?

Свернуть Ответить
- Рубинштейн Кирилл [krubinshteyn], 10 июня 2011, 12:34
  
  + 0 —
  
  Вопрос армянскому радио:
  — Как снизить количество проблем?
  — Перестать их регистрировать!
  
  Ответить
Яковлев Андрей Михайлович [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, 15:00
        
        + 0 —
        
        Для полноты картины надо определить и термин ОПЕРАЦИОННАЯ деятельность.
        
        Ответить
- Солопов Павел [PaSol], 21 июня 2011, 13:10
  
  + 0 —
  
  "Для этого многотомные мануалы и KPI не нужны."
  
  Насчёт KPI, возможно вы и правы, а насчёт мануалов не соглашусь с Вами. Например, Cisco в сертификации отдельно выделяет такую тему, как траблшутинг. Дело в том, что выявление проблем не простая задача, хотя надо признать, что её решение лежит не столько в процессной области, сколько в области технологической методологии.
  
  Свернуть Ответить
  - Рубинштейн Кирилл [krubinshteyn], 21 июня 2011, 13:11
    
    + 0 —
    
    Это уже немного другого рода мануал (инструкция по выявлению проблем) -- против таких я ничего против не имею :). Чем больше, тем лучше. Как вы правильно сказали -- тут речь о технической методологии.
    
    Свернуть Ответить
    - Солопов Павел [PaSol], 21 июня 2011, 13:22
      
      + 0 —
      
      Беда в том, что о ней-то сейчас думать и не принято. Все увлечены процессами и сервисами, как будт-то это отменяет необходимость "крутить гайки".
      
      Ответить