Правда, здорово, когда своевременность решения инцидентов в вашей организации составляет более 95%? Даже отраслевая статистика ниже – средний уровень своевременности решения находится на уровне 82%, и только 13% компаний добрались до лидерских 96-100% («IT Service Management Metrics Benchmarks», Pink Elephant, 2013). Так что больше 95% – это действительно круто. Или нет?
Многие конечные пользователи считают, что нет. И вполне обоснованно, потому что высоких показателей своевременности несложно добиться просто увеличением целевого времени решения. И вот ИТ-отчетность вся в зеленой зоне, а пользователи жалуются – инциденты решаются неприемлемо долго. Своевременность – это косвенный показатель. Он вполне годится для процессного контроля, но с точки зрения конечных пользователей гораздо важнее среднее время решения, поскольку оно ближе к их непосредственному восприятию. И лучше в разбивке по уровню влияния (или другому параметру, который определяет срок). Радоваться же высокой своевременности без учета времени решения – наивно. (Ваш Кэп)
А вот с точки зрения процессного контроля все немного сложнее. Фактически, у руководителя есть две принципиально различные стратегии. Первая – выставить высокий показатель своевременности при относительно большом сроке решения и постепенно его сокращать. Например, своевременность 95%, время решения для начала 8 часов, потом постепенно снижаем. Вторая – установить более жесткое целевое время решения, постепенно поднимая планку по своевременности. Например, сразу установить срок решения 2 часа, но начать со своевременности на уровне 50%, постепенно приближая его к целевым 80-90%. И из этих двух вариантов я, пожалуй, голосую за второй.
Во-первых, при прочих равных он заставляет двигаться быстрее, а это именно то, что нужно от управления инцидентами. Во-вторых, о более коротких сроках восстановления легче договориться с заказчиками услуг. А в-третьих, установив целевое время решения далеко от текущих показателей, мы с большей вероятностью избежим ловушки локальной оптимизации. То есть начнем думать не только о том, как быстрее реагировать на поступающие инциденты, но и о том, как сократить их количество, какие заготовить обходные решения и как научиться использовать мониторинг. А поможет нам в этом очень полезный метод – Expanded incident lifecycle.
Возможно, в бенчмарках мы с такими рассуждениями будем не на первых местах. Или, по крайней мере, не сразу. Но есть ведь и более важные критерии успеха?
Правильно я понимаю, что отраслевая статистика, на которую автор ссылается в начале заметки, подтверждает, что большинство респондентов выбирают именно вторую стратегию?