Деятельность по поддержке пользователей организована в огромном множестве компаний. И измеряется она более-менее стандартно уже много лет. Одним из основных показателей качества поддержки является метрика своевременности, которая, упрощенно говоря, определяется как доля обращений, решенных в рамках норматива, от общего количества обработанных обращений. У этой формулы есть свои изъяны, и мы много писали об этом – и на портале, и в статьях, и в нашей книге про измерение ITSM-процессов.
Но сейчас не об этом. Бывает так, что исполнитель не имеет возможности обработать запрос не по своей вине, а потому что пользователь не предоставил ему всей информации, или не может обеспечить доступ в свои помещения, или не согласовал выделение средств и так далее. И если мы используем показатель своевременности для оценки деятельности персонала, мы должны как-то учитывать вынужденные ожидания, то есть приостановки в обработке запросов не по нашей вине / причине, чтобы не позволять оправдываться в несвоевременном решении словами «это не я, это они, а я все сделал сразу». Для этого во многих ITSM-продуктах есть функциональность, которая позволяет корректировать общее время обработки запроса на длительность такого вынужденного ожидания. И это функциональность очень востребована на практике.
Но если у ИТ-специалиста есть возможность «приостановить таймер», обеспечив себе большее время на обработку поступившего к нему запроса, как не допустить злоупотреблений?
Принципиально есть два подхода. Первый способ – оперативный контроль. Например, при приостановке обработки заявителю уходит уведомление, в котором прямо говорится, что «к сожалению, мы не можем обработать Ваш запрос, пока Вы не сделаете того-то и того-то». Или приостановку может санкционировать только линейный руководитель. И так далее. Все эти методы имеют свои плюсы, но и свои минусы – использование только их не достаточно на большом потоке запросов, то есть там, где контроль обработки индивидуальных запросов затруднен.
Второй способ – статистический, то есть введение времени или общего количества ожиданий в метрики по поддержке. Например, помимо своевременности, можно ставить исполнителям норматив по среднему времени решения, куда включать не только собственно время обработки, но и время ожидания. Это будет стимулировать исполнителей не использовать ожидание там, где без него можно обойтись, и не затягивать ожидание там, где совсем без него обойтись все же нельзя. Или снижать рейтинг по обработке запросов, если в ходе обработки исполнитель инициировал ожидание (хотя лично мне этот способ нравится меньше).
А вопросы мои таковы:
- Используете ли вы в своей практике ожидания, которые позволяют «приостанавливать таймер» обработки запросов?
- Если используете, как боретесь со злоупотреблениями?
- Если для этого вы, в том числе, используете KPI, то какие?
Используем, конечно 🙂 Несмотря на то, что временные параметры обработки заявок уже включают в себя приемлемые задержки, все равно изредка возникают ситуации, когда исполнители не успевают обработать ее в рамках SLA по не зависящим от них причинам (которые, к слову, бывают разнообразными).
Поставить заявку на паузу может исключительно менеджер процесса, при этом исполнитель обязан описать необходимость продления срока. Заказчик, после перевода заявки в статус "ожидание" получает соответствующее уведомление. При таком варианте риск злоупотреблений крайне мал.
В расчете KPI мы считаем как и общее время обработки, так и реальные трудозатраты по заявкам (в рамках привязанных задач). В статусе "ожидание" счетчик останавливается.
По поводу разнообразия причин задержек: кроме стандартных вещей вроде невозможности доступа на площадку или непредоставления информации, есть и совершенные интересные вроде истечения срока договора на техническую поддержку, приходится ждать его продления, а затем доделывать 🙂