KPI техподдержки. Вопрос по расчету. #747096

Насколько я понимаю, общепринятые KPI техподдержки: - Количество решенных задач, к нерешенным - Количество задач, которые удалось решить, не прибегая к помощи других отделов - Удовлетворенность пользователей Примерно так представляю расчет KPI: - N% заявок решено за M времени - Кол заявок / кол решенных заявок - Не более N эскалированых заявок - % положительных отзывов по решению заявок Вопрос: Насколько я понимаю, "Кол заявок / кол решенных заявок" никогда не будет равен 1. Получается нужно принять примерно такую шкалу: Или я не правильно понимаю?

Насколько я понимаю, общепринятые KPI техподдержки: - Количество решенных задач, к нерешенным - Количество задач, которые удалось решить, не прибегая к помощи других отделов - Удовлетворенность пользователей Примерно так представляю расчет KPI: - N% заявок решено за M времени - Кол заявок / кол решенных заявок - Не более N эскалированых заявок - % положительных отзывов по решению заявок Вопрос: Насколько я понимаю, "Кол заявок / кол решенных заявок" никогда не будет равен 1. Получается нужно принять примерно такую шкалу: Или я не правильно понимаю?

> Насколько я понимаю, "Кол заявок / кол решенных заявок" никогда не будет равен 1. А если в прошлом месяце закрыли 100% поступивших заявок этого месяца + 3 заявки позапрошлого?

Ну как бэ: Если > 0,98 Тогда 100% ИначеЕсли > 0,95 Тогда 90% ИначеЕсли > 0,80 Тогда 80%

А согдашение о качестве обслуживания есть? Вообще kpi однозначно работают только на уровне организации/ организаций в холдинге. На уровне отделов - профанация.

Нет. А зачем оно конкретно для техподдержки? Про второе не понял...

Скорость ответа - вообще ни о чем. Все зависит от сложности вопроса. Количество решенных к нерешенным - тоже фигня. Почему саппорт должен отдуваться за косяки разработчиков? То же самое и с помощью других отделов - косяки их, а зарплату режут саппорту. Ну и удовлетворенность пользователей - тоже не только от саппорта зависит.

Свои предложения?

Деньги платишь ты или другой? Что поддерживаешь? Всё подряд? из серии сферического коня...

Поскольку основной задачей всех работников является максимизация прибыли организации, то и KPI надо строить от этой печки. Были убытки по вине саппорта - депремируем. Саппорт помог увеличить прибыль - премируем. Например, если из-за медлительности или нежелания помочь саппорта сорвалась крупная сделка - саппорт сидит без премии. Если проблема на стороне программистов - значит программисты сидят без премии. Если саппорт оперативно скооперировался с программистами и оба отдела быстро устранили проблему - все получают обычную премию. Все остальные варианты чреваты бесполезным изображением бурной деятельности и перепиныванием мяча в зону ответственности другого отдела.

"задачей всех работников является максимизация прибыли организации" - ха, ха, ха....

С точки зрения хозяина бизнеса это именно так. Ну если только это не ФГУП какой-нибудь, где основная задача пилить бюджет.

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

Если работникам не платить - они будут вредить, т.е. вместо экономии убытки будут. Проще их тогда вообще не нанимать.

а как же в таком разе увеличить прибыль подразделениям МВЗ??

Иметь минимально достаточное количество работников и минимально возможный уровень затрат.

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

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

Это какая-то суперподдержка, которая влияет на совершение сделок. У нас все скромнее. - не печатает принтер - переставили ПК, не достает wi-fi - переместили ТСД на другую точку, не работает. - не работает сканер на складе - принять экзамен по 1С у пользователя - не работает почта И фиг знает как именно каждый инцидент влияет на прибыль... Но ее получению, он вроде бы мешает.

ИМХО. Половина примеров из перечисленных, это повторный вызов из-за некачественной работы исполнителей первого этапа. Начните с повышения квалификации мальчиков на побегушках.

вот, в чем dmpl прав, так это - создание KPI на уровне отдела самим отделом без привязки к иерархии организации действительно профанация))

Какая разница-то? Работа же должна быть выполнена.

Так кто платит или не платит? Кто заказывает музыку?

а какая разница??

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

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

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

Что за слово "эскалированых" ?

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

передать на вышестоящий уровень - эскалировать проблему..

Премию надо платить за минимизацию обращений по определённого направлению. Но в подобном деле невозможно включать прямую схему KPI. Иначе будет кадровая текучка и в конечном итоге резкое снижение качества обслуживания.

Вопрос не понятен. Техподдержка - работают на фикси. Ну допустим. А в другой раз принтер не печатал, но покупатель подождал. И чего по разному оценивать?

Правильное замечание. Переданные специалисту с более высокой квалификацией.

ты ответил )) платишь не ты. Следовательно, имитация бурной деятельности. ИМХО, начинать надо не с KPI.

А если это был не покупатель, а поставщик, то наоборот сэкономилм XD

Не понял. ПК и принтеры перестанут ломаться? И чего? Поддерживать-то все равно надо.

самым главным критерием должно быть "отсутствие повторных обращений по одному и тому-же вопросу" теперь немного из теории: 1. тех поддержка (первая линия) относится к ресурсному управлению (то есть ресурсы фиксированы), по этому - скорость ответов зависит от загрузки и не может быть КПИ отдела - количество заявок решенных - да может быть критерием КПИ но только при их жесткой классификации, что на практике не реально - количество "эскалированых заявок" это вообще не показатель работы, по тому как они ОБЯЗАНЫ эскалировать заявки вне своей компетенции

Спасибо. Я уже понял, что туповат немного.

Принтер не печатал - значит производительность отдела снизилась, так что тоже повод для депремирования. Тут смотря как - если это был поставщик с самым выгодным предложением под заключенный контракт - то нифига не сэкономили, если не найти еще более выгодного поставщика ;)

а где в кпи обязанность юзеров генерить трафик вопросов?

а вообще советую заглянуть в Ваш договор SLA, именно в нем на 100% расписаны все критерии KPI отдела в целом, а вот как делить их на конкретных исполнителей это вопрос...

Ну можно, раз в день заявки просматривать, а можно и чаще. Зачем нужна четкая классификация? Сложные/временные заявки не в их компетенции. Да, но и не должны отвлекать спецов, типовыми вопросами.

Не хотел обидеть. Дело не в тебе. см там всё по делу.

Та он не про себя)

"отсутствие повторных обращений по одному и тому-же вопросу" Вот тут вопрос. Как правило, если возникают системные проблемы, то и решать их нужно системно. А это уже не ответственность поддержки.

> самым главным критерием должно быть возможность посредством кпи оптимизировать выплаты персоналу на желаемую величину, не?)

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

Ну да, сначала выводим персонал на максимальную производительность, потом сокращаем половину ненужного персонала :)

Допустим этот вопрос решен.

> сокращаем половину ненужного персонала чтобы сократить половину ненужного нужно сначала нанять соответствующие 100%

что мешает "допустить", что и сабжевый вопрос решен?)

Дык а зачем KPI еще вводить? Если лишних людей нет - сэкономить не получится.

таки ж, не для экономии кипиай... а для управления задачами достижения целей

чтоб новых не нанимать

+ 1. Нафантазировали...

> Дык а зачем KPI еще вводить? скучно, не?

Все дальше - ИМХО. KPI организации или организаций в холдинге, вполне обоснован. Деятельность организации зависит только скорости реакции самой организации на изменение внешних факторов. Поэтому KPI можно вводить. Они будут показывать именно эффективность организации. Для подразделений KPI бессмысленны, просто в силу того, что подразделения не являются самостоятельными бизнес единицами а зависят в своей деятельности от смежных подразделений. Пример на хепдеске. Количество решенных проблем зависит не только от качества специалистов поддержки, но и от качества сотрудников у которых возникают проблемы. Также от качества работы кадровой службы, и от культуры управления знаниями и много еще от чего. Вводя KPI на уровне подразделений пытаются изолировать подразделение от деятельности компании. Это все равное что в часовой механизм на каждый узел ввести KPI. Поставить одну шестеренку с алмазным напылением что б не стачивались зубья у нее. Что тогда получится? Остальные зубья будут разрушаться из-за того что одна будет хорошо работать. На сколько курсов не ходил по KPI везде одно и тоже... вся теория хороша когда идет разговор на уровне организации, но как только встает вопрос про подразделения, то у всех профессионалов начинается "вода" в стиле - "KPI подразделений должны соответствовать целям подразделения...". Когда начинаешь спрашивать про конкретику... все текут. Так-что мое представление о KPI на уровне подразделений - это игрушка для менеджмента в те моменты когда жизнь хороша. В кризис, никакие KPI не помогают, а только мешают. Ну есть конечно исключения - очень большие организации (транснациональные), но там проблема сложности управления решается по другому. Обычно делается холдинговая структура.

не соглашусь ... KPI нужен для 1. Мотивирования 2. Анализа и то и другое конечной целью ставит увеличение эффективности, а значит экономии.

Анализ, мониторинг - да. Мотивация - вряд ли. Зная механизм расчета KPI участник процесса может делать так, что б его показатели только повышались. Вводить ошибки для возникновения инцидентов и т.д.

кстати интересный разговор слышал между кассирами Ашана (не знаю правда или нет) мол у них зп зависит от времени проведённого на кассе, и количества косяков (ошибок), но вообще не зависит от количества транзакций или от суммы смены....

Млять, как достали эти теоретики-кипиайщики! Ну как-то ввели у нас KPI на саппорте. И даже не такие дебильные, как количество заявок (это вообще идиотизм - одна заявка "Как мне группировку в отчет добавить?", а другая "У меня анализ налогового учет на идет по 250 документам"). Ввели количество заявок, выполненных в срок. После этого ессно все двухминутные консультации по телефону стали фиксироваться и ессно они нивелировали реально сложные заявки, которые никак не вписывались в SLA. И которые реально сложные, важные и напрягали клиента. Не нужно вводить безумные KPI только для того, чтобы они были. Затрахаете людей бюрократией, а дело не будет двигаться. Нужны показатели, достижение которых двигает компанию к цели. А не для галочки о "внедрении KPI".

"не зависит от количества транзакций или от суммы смены" // заставляет кассира гаситься на крайней кассе :)

да и в не федеральных сетках такая же по кассирам система

> Нужны показатели, достижение которых двигает компанию > к цели. цель: внедрить к обозначенному сроку kpi во всех подлежащих оптимизации подразделениях - чядн?)

Имхо, КПЭ в саппорте дело мертвое. Будет работать только в условии стандартизации обращений, а с учетом изобретательности пользаков - это нереально, да и изобретательность самого саппорта нельзя отменять. Это то же самое, что психологу KPI вводить. Пробовали внедрять. Был пример того, что одна и та же проблема "принтер не печатает" может решиться как за 30 секунд кнопкой "вкл", так и за несколько часов курения серверного spool'а. И как тут стандартизировать? обращение копеечное, а трудозатраты мама не горюй. Да и эскалацию туда приплетать тоже опасно, смотрел и этот вариант. Премию-то хочется и начинается хватание за тяжелые проблемы с большим коэффициентом, вне своей компетенции, в ущерб мелким текущим задачам. Как бывший руководитель саппорта заявляю: неэффективная модель :)

Встречала вариант когда в качестве критерия оценки использовалась степень удовлетворенности заказчика. После закрытия заявки программистом заказчику задается вопрос, удовлетворен ли он выполнением заявки. Если ответ: "Да, конечно", то +1. Все остальные ответы фиксировались, но в расчетах не участвуют. Если пользователь не удовлетворен, то заявка считается незакрытой до разбирательства. Таких за довольно долгий срок были единицы. В конце месяца высчитывался коэффициент "Да, конечно" к общему количеству заявок.

Цель компании - увеличить выручку на хх%, увеличить долю рынка до хх%, увеличить прибыль на хх% и т.п. То, что Вы назвали не цель компании, а способ убить время топ-менеджерами, мающимися от безделья.

В результате это выльется в разрушение архитектуры информационной системы. Т.к. проектировать систему будет не архитектор (или разработчик), а заказчик. Исполнителю легче договорится с заказчиком чем пытаться уговорить его что задачу нужно решать по другому. Поэтому и величина "разбирательств" низкая.

:) точно.

В каких единицах измеряется "степень удовлетворенности"? Заявка по-любому считается не закрытой, если заказчик не подтвердил ее исполнение. Или если ответ от него не получен после уведомления о выполнении в период времени, оговоренный в SLA. Логичнее тут оценивать количество жалоб - когда закрытую заявку заказчик возвращает обратно.

Вроде все логично. Но а как тогда понимать, насколько качественный продукт выпускает подразделение? Может ему ресурсов не хватает, а может наоборот баклуши бьют. А может вообще продукт не востребован? "Нужны показатели, достижение которых двигает компанию к цели" Каким макаром, техподдержка двигает компанию? Чем кончилось-то? По идее заказчик должен "закрыть" решенную задачу. Если не "закрыл", то написать претензию.

У них степени: "Нет", "Да", "Да, конечно". Ну и возможно какие-то промежуточные. В расчет идут только "Да, конечно". Речь идет о техподдержке, они ничего принципиально нового не разрабатывают, и уж тем более не лезут в архитектуру. Что не входит в их компетенцию они передают выше, разработчикам. А у тех к оценке работы специалиста заказчик не имеет отношения.

[Каким макаром, техподдержка двигает компанию?] достаточным условием является,что не торомзит

Это точно поддержка или разработка нового функционала?

Так профанация же...

Это только поддержка, у разработки совсем другие критерии.

да понятно.тут еще надо посмотреть на коллектив сначала,а уж потом умными словами раскидываться.почему только смотрится в одну сторону

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

(+74) Боюсь представить что будет если оценку разработчиков отдать рядовым пользователям) Наверное в таких случаях рождаются шедевры:

- Я нажимаю на зеленую кнопку, и жду что вылезет коричневая бумажка. - Перед тем как нажать на зеленую кнопку, дерните за белую веревочку. - ... - Вы удовлетворены? - Нет, я не желаю дергать за веревочки! И как тут быть?

кстати    Галахад а зачем вашей конторе понадобилась сия штука?система оценки есть как класс?

у него есть руководитель,который посвящен в ширину берегов IT службы.и что будет если вышел

Ну и? Чтобы обеспечить нужно чинить поломанное. И быстро. И как-то потом оценивать. А чем как не "безумными" KPI?

Собственник хочет отойти от оперативного управления.

система подачи заявок пользователей устная?

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

Советую забить на эту херь)

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

С такой шкалой весь KPI будет в глубокой ЖО, ибо они в принципе недостижимы никак физически.

Письменная. В смысле в 1С. "бесперебойность" - есть такой критерий. Но не у техподдержки. Техподдержка решает вопросы, где стоимость простоя, это стоимость простоя одного сотрудника. Если простаивает сервис, это уже другой уровень ответственности. Посоветуйте свою шкалу. Или метод.

где можна ознакомиться со всем списком аутентичных целей ?)

> Кроме того KPI не способ депремирования и т.п. злые языки клевещут, что когда-то за подобные нетрендовые заявления объявляли еретиком вплоть до на костер, не?)

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

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

KPI вроде другая тема. Вы опять ее трансформировали в зарплату. А по существу показатели должны обеспечавать стабильный уровень качества. Если невозможно - применяйте другие показатели. KPI может просто нах демотивировать :)

Именно. В нынешней конторе это как раз способ надуть сотрудника и кинуть его на зарплату :) Но внедрял KPI человек, которой понятия не имел не только о них, но и о системе сбалансированных показателей вооюще. Как и о системе мотивации сотрудников как таковой - у нее система "мотивации" - это загнобить, нае...ть и не заплатить. А не обучить, развить или заинтересовать. И соответственно люди в ответ так же работают.

существует два подхода по построению KPI: 1. Строишь систему на том, что посчитать. Это стандартный путь, так все делают. В результате получается, как у всех 2. Думаешь, какие процессы нужно контролировать. Думаешь, в чем выражается производительность этих процессов. Учишься эти показатели считать. Строишь систему на этих показателях. Но это долго, нудно и не весело, по этому все, как я уже сказал, пользуются первым подходом. Я к тому, что спрашивать на улице, какие показатели нужны - как-то наивно.

к вам вообще соваться нельзя? KPI похоже есть. Как считаете разовые получасовые консультации и заявки продолжительностью день?

Тролль, который придумал подменить понятие KPI на нагибалово по зарплате, был гениален, надо признать это. KPI вообще-то придуманы для управления процессами, но всем пох*уй, все с их помощью считают зарплату. Поскольку управлять процессом - это целая работа, а резать зарплаты сервисного персонала задорно и весело, мозгов в общем не нужно для этого.

следующий!