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

Измерить эффективность процесса управления проблемами бывает достаточно сложно. Сложность еще и в том, что эффективность управления проблемами во многом зависит от зрелости других процессов, например, от того, как регистрируются инциденты. Если доверить формирование KPI бизнес-руководству, то можно получить самые неожиданные показатели. Попробуйте отчитаться о «количестве инцидентов в прошлом месяце, предотвращенных благодаря управлению проблемами».
Вот некоторые действительно полезные индикаторы для управления проблемами.
- Количество зарегистрированных проблем
- Количество разрешенных проблем
- Количество и процент проблем у которых выявлена основная причина
- Количество и процент проблем для которых найдено обходное решение
- Средний возраст проблемы, по степени воздействия на бизнес
- Процент инцидентов относящихся (вызванных) к известным проблемам по отношению к общему количеству инцидентов за период
- Частота обновления известных проблем
Частота обновления — особо полезный показатель на ранних этапах управления проблемами, показывающий регулярность работы над анализом проблем. Для того, чтобы процесс был эффективным нельзя вечно откладывать работу. В то же время с проблемами именно это часто и происходит, особенно когда сотрудники полностью поглощены другими более срочными и актуальными задачами. В итоге многие компании, зная о пользе управления проблемами, не могут найти на него время из-за большого количества инцидентов. Закрыть инцидент — доблесть, решить проблему — оставить себя без работы. Естественно, что без эффективных KPI, заставляющих концентрироваться на разрешении проблем, сотрудники занимаются этой работой в последнюю очередь.
Наличие KPI определяют эффективность и качество процесса управления проблемами. Правильные KPI помогают, как концентрироваться на поиске решения известных проблем, так и на выявлении причин инцидентов и открытии новых проблем. По идее также работают «палки» в милиции/полиции, впрочем там как раз выбраны не лучшие варианты KPI.
И нужно помнить о том, что эффективное управление проблемами может быть только в тесном сотрудничестве со службой Service Desk. Именно у SD есть все необходимые данные об инцидентах, необходимые для анализа и выявления проблем.
По материалам itsmperfection.com
Дополнительные материалы
Комментарии (17)
КомментироватьЗанегин Дмитрий [Dimazan], 09 июня 2011, 02:36
Бизнес = потребности = 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
блудыпродавцы. Кто-нибудь реально по 20 KPI с оценкой SQI работал? Из практики - половина KPI "внедрены" менеджером проекта для подчеркивания собственной значимости.Peshkov Alexander [PA], 09 июня 2011, 23:07
Возможно, самый важный KPI в этом процессе - это кол-во инцидентов?
Рубинштейн Кирилл [krubinshteyn], 10 июня 2011, 12:34
— Как снизить количество проблем?
— Перестать их регистрировать!
Яковлев Андрей Михайлович [swtws], 09 июня 2011, 23:49
Рубинштейн Кирилл [krubinshteyn], 10 июня 2011, 12:38
Солопов Павел [PaSol], 21 июня 2011, 13:05
Рубинштейн Кирилл [krubinshteyn], 21 июня 2011, 13:07
Солопов Павел [PaSol], 21 июня 2011, 13:21
Может всё зависит от подхода к процессу, может надо определить его периодичность (процессы ведь обладают какой-то периодичночтью, так ведь?).
И если для управления инцидентами периодичность может составлять часы и минуты (с появлением нового инцидента запускается новый экземпляр процесса), то у управления проблемами периодичность может равняться месяцам.
Рубинштейн Кирилл [krubinshteyn], 21 июня 2011, 13:59
Солопов Павел [PaSol], 21 июня 2011, 14:13
Вы хотите сказать, что в решении проблем нет повторяемости, что какждый раз это некая уникальная деятельность. Т.е. каждая проблема это как бы проект и нет смысла пытаться свести всё к общему процессу?
Солопов Павел [PaSol], 21 июня 2011, 14:14
Рубинштейн Кирилл [krubinshteyn], 21 июня 2011, 14:19
Я, возможно ошибочно, полноценно процессной считаю только операционную деятельность. В остальных случаях речь идет о некоторых повторяющихся вехах, реализация которых уже никак особо не регалментируется (больше идет от технологий/умений). При инциденты, впрочем, так тоже сказать можно, но там периоды повторения чаще.
Солопов Павел [PaSol], 21 июня 2011, 15:00
Солопов Павел [PaSol], 21 июня 2011, 13:10
Насчёт KPI, возможно вы и правы, а насчёт мануалов не соглашусь с Вами. Например, Cisco в сертификации отдельно выделяет такую тему, как траблшутинг. Дело в том, что выявление проблем не простая задача, хотя надо признать, что её решение лежит не столько в процессной области, сколько в области технологической методологии.
Рубинштейн Кирилл [krubinshteyn], 21 июня 2011, 13:11
Солопов Павел [PaSol], 21 июня 2011, 13:22