Как перейти от Цели подразделения техподдержки к показателям, понятным сотрудникам

Задача:

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

Исходные установки и упрощения:

• рассматривать будем поддержку внутреннего клиента;
• считаем, что состояние заявки меняется мгновенно и одновременно с изменением реального состояния объектов (т.е. время регистрации обращения = времени возникновения потребности, время закрытия обращения = времени выполнения требуемых действий);
• стараемся не накручивать детализацию.

Для реализации поставленной задачи фактически необходимо выделить критерии, на основании которых можно осознанно «рулить» приоритетами (порядком решения) задач, и определить правила оценки данных критериев.

Обоснование (теория):

Целевой показатель от бизнеса – минимизация потерь от инцидентов и несвоевременно завершенных запросов на обслуживание.

Попробуем определить, что влияет на целевой показатель:

На этом теоретические изыскания закрываем и пытаемся обработать их плоды.

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

Как помочь определить приоритеты или как оценивать скорость потерь C:

В абсолютных величинах задача не подъемная (да, и не особо нужная), поэтому предлагается вариант использования оценок, заключающийся в том, что считаем стоимость пропорциональной нашей оценке:

Причем, нас не сильно будет волновать значение самого коэффициента пропорции, т.к. эту величину будем считать постоянной, и тогда можно будет перейти от потерь к их оценке (O):

Что же делать с этой оценкой Oi? Разлагать на более понятные и легко оцениваемый параметры, от которых в реальности и зависят потери:

Собственно по оценке стоимости потерь — это все. В итоге непонятную стоимость свели к «широко известной» схеме экспертных оценок.

Пример параметров (частично взято из ITIL):

1. Степень влияния – степень потери от штатного функционирования на элементарном объекте\услуге.
2. Критичность потери – относительная оценка величины потерь на одном элементарном объекте\услуге из-за проблемы.
3. Масштаб проблемы – количественная оценка элементарных объектов, пострадавших от проблемы.

Далее стоит рассказать, что весовые коэффициенты этих параметров определяется экспериментально. А в итоге получается список приоритетов обращений.

Вроде бы ничего нового в ходе рассуждений не изобрели, но когда по этому пути рассуждений проводится сотрудник, то его мировоззрение: «зачем все это» и «почему все именно так», может кардинально меняться.

Также вышеизложенное можно использовать для автоматизации определения приоритетов заявок.

Надеюсь изложенные мысли окажутся полезными.