В редакцию портала поступил вопрос:
Коллеги, добрый день!
Скажите, кто-нибудь имеет опыт увязывания результатов работы конкретных сотрудников по выполнению запросов/нарядов с их премиями? Понятно, что корреляция не 100%-я, мы хотим, чтобы был коэффициент для каждой должности, кто на сколько процентов вовлечен в обработку запросов — столько процентов премии и будет зависеть от выполнения запросов… интересует сама методика и опыт.
Спасибо!
Андрей, поддерживаю идею! Модель понятная обеим сторонам (компания и наёмный сотрудник). А откуда "фикс"=40? Жизненый опыт? Практика Uber?
У меня был опыт 70%fix/30%премия – не работает. Лишение премии – это целый квест. Да и потеря 30% – не велика потеря, т.к лишают только за очень большой "косяк".
Ребята, спасибо за предложения.
У нас в плане качества выполнения запроса сейчас в системе заведены три показателя:
1) просрочка SLA
2) количество возвратов запросов
3) оценка пользователя.
Эти три вещи должны влиять на премию.
И еще такой момент: мы настроили так, что в запросах есть наряды, то есть несколько человек могут произвести работы по запросу Инициатора. И оценка одна на всех, потому что пользователь (Инициатор) он не знает сколько внутри запроса нарядов (внутренняя кухня ИТ).. Ну тут включается командообразование между подразделениями ИТ, мол, давайте ребята, не подводите друг друга, не футбольте.
Это вводные. А над решением (по поводу примей) – еще размышляем.. Ведь качество выполнения работ по запросам это еще не все, еще и трудовая дисциплина, и выполнение персональных заданий руководителя..все в примю вкладывается, целый комплекс показателей. И для каждого департамента и каждой должности они разные. А значит нужна матрица со всеми значениями. А значит административная обвязка по постоянной актуализации матрицы…что конечно не хочется никому отслеживать.
Проверенной на практике методики нет, есть только идея:
1. Разделить оплату на процесс губ и результативный часть. Первая за соблюдение процесса, т.е. на сколько правильно выполнялась работа, вторая за результаты видимые потребителю.
2. Доля каждой составляющей зависит от требований предъявляемых к роли/должности. Например, сотрудник принимающий обращения в SD 70/30, а руководитель SD 30/70. Чем больше свободы дается в принятии решения, тем больше составляющая за результативность.
3. Главное, чтобы требования, по которым оценивался труд, совпадали с критериями, по которым рассчитывается оплата труда.
4. Метрики используемые в составляющих брать из процесов, в которых участвует сотрудник. Долю их делать в соответствии с тем, на что сотруднику нужно в первую очередь обращать внимание.
Если без конкретики, то как-то так…
Разрабатывал когда-то методику учета трудозатрат. Суть: из учетной системы выгружалась информация о выполнении заявок (ФИО-штуки); создавался справочник соответствия выполнения конкретной работы по каталогу услуг – нормативному времени выполнения; штуки перемножались на время, с учетом кол-ва отработанного рабочего времени – высчитывалась нагрузка на сотрудника в процентах. Чем больше заявок выполнит сотрудник, тем его нагрузка будет выше – можно считать премию. По опыту могу сказать, самое главное, определить правильное нормативное время выполнения той или иной работы. Определять время можно на основании экспертной оценки и/или на основании фотографии рабочего дня (когда можно точно определить фактическое время выполнения работ). Также из опыта могу сказать, что фактическое время выполнения работы, которое считает учетная система на основании статусов жизненного цикла – не соответствует действительности (люди часто "прощёлкивают" статусы или "забывают" поставить выполнение). Нормативное время работы – не путать с временем выполения по SLA. Это разные величины.
Поняла, спасибо.
Да, мы что-то вот такое и хотим, только у нас получается, что для кажого отдела и каждой должности нормативы разные. А значит будет огого какая матрица с разными значениями, которую администрировать надо будет..Это вызывает опасения.
Система премирования, в том числе, зависит от степени зрелости процесса и должна развиваться вместе с процессом. Не следует стремиться сразу учесть в системе все что хочется. Важно что бы система была понятной для участников, что бы они точно понимали, что от них ожидают получить и направляли свое усилие в нужное русло. Сложная система показателей и рассчетов может снизить степень доверия и участники придумают свой путь.
Подумайте, какие функции в процессе необходимо усилить? Сформулируйте метрики и показатели. Премируйте за достижение. Далее переходите к другим метрикам. При необходимости можно возвращаться для закрепления материала.
Использовал схему премирования специалистов поддержки по следующим КПЭ:
1) Выполнение целевого % соответствия SLA
2) оценка пользователя.
Премия 20-30% месячного оклада. Причем эти показатели с разными коэффициентами практически у всех сотрудников влияли на премию, что считаю правильным. Тк если в ИТ не могут обеспечить качественную поддержку ИТ систем и довольных пользователей, то значит надо что-то в консерватории менять.
Для системных администраторов также использовал премию по % доступности – около 15-20%.
Интересная схема. И простая. Спасибо!
у нас 2 схемы:
1. 70% – фикс – 30% – от выполненных нарядов. Есть норма часов, которую должен закрыть инженер. Если выполнил норму, получишь звои 100% з.п., всё, что больше, в +, меньше, соответственно -.
2. 100% – сотрудники эксперты, либо менеджеры. занимаются вопросами, типа управления проблемами, релизами и т.д. Премии – на усмотрение руководства, в основном за выполнения большой задачи.
Также встречал и схемы:
а. 50-50
б. 20-80+
в. 5%-+.
Б и В относилось исключительно к продажникам. Все схемы были достаточно рабочие, всё зависит от того, как выстроены процессы.
Спасибо за отзыв!
Вопрос по 1-му пункту: норма именно в часах? количество нарядов не учитывали? а если человек приписывает себе излишек потраченного на наряды времени? как отслеживали мухлевание?
Норма в часах, количество нарядов/обращений учитывается только в общем показателе службы и при анализе. А для сотрудника нет, поскольку наряд предполагает конкретное время на выполнение, к примеру наряд, трудоемкость которого 0.5 часа сделай инженер его за час или за 10 минут, в з.п. посчитается 0.5.
Относительно мухлевания: наряд должен быть в обязательном порядке связан с обращением пользователя, в этом случае мы всегда можем отследить, для кого и в рамках чего инженер работал.
И только для инженеров старшего звена разрешается самим на себя создавать наряды (для выполнения каких-либо регламентных задач на серверах, ПК пользователей и т.д.) – и в этом случае контроль периодический есть, но в основном такие сотрудники не балуются такими вещами.
БОльшая проблема – когда закрывают наряды, всецело не оказав услугу.
К примеру, пользователь пишет: "не работает хром", на что инженер сразу же, без какой-либо диагностики и уточнений, закрывает свой наряд, а вместе с ним и обращение комментарием: "воспользуйтесь браузером IE".
А причина не в браузере, а в том, что у провайдера авария. И вместо того, чтобы своевременно при диагностике это выявить, вместо одного обращения мы получаем два, когда пользователь снова напишет в SD, уточнив, что проблема не в браузере, а в интернете в целом.
Вот с такими приходится работать более тщательно.
Внедрили схему завязанную на классификации обращений. Составили 2-3 х уровневый классификатор обращений. Я разработал первоначальный вариант. Отдал его в работу. Совместными усилиями, вместе с инженерами его допилили. Установили нормативное время для каждой операции. Внедрили. При закрытии обращения инженеры ставят код работ. + для каждой работы есть типовое решение как ответ инициатору. По итогу на определенном временном горизонте считается нормо часы каждого инженера. Составлен рейтинг. Связали его с действующей системой премирования. Первые трое получают максимум добавки. Кто выше среднего те получают повышенный коэффициент, но меньше лидеров. Определили минимальный порог. Кто ниже тот кандидат на депремирование. Оценка работы инженеров стала менее субъективной. Да, инструмент надо перидочески “затачивать”: пересматривать нормы, дополнять операции. Решается еще и вопрос проблем-менеджмента. Получается таблица затрат на ТП. Какие операции отнимают больше ресурсов, что требует улучшения. Для другой компании разработал классификатор, но до внедрения не дошло. Захотели классификатор внедрить в учетную систему, необходима доработка ПО. В первой компании классификатор внешний. Коды-решения просто копи-пастят.
Жаль, что по такой, с моей точки зрения, важной теме тишина, а в теме "почему доступность в %" аншлаг. А ведь тут тема прям обязательна к обсуждению, т.к. сервис – это люди, а мотивация – один из ключевых моментов в управлении людьми.
Коллеги включайтесь, чувствую я, что тот, кто найдёт наиболее правильный ответ на данный вопрос будет "впереди планеты всей".
Мои идеи (пока на практике не проверялялись) вертятся вокруг модели Uber, когда таксист (ИТ-специалист) видит заказ (заявку) принимает, выполняет – получает за это деньги (по отзыву пользователя может получить не всю сумму – штраф, за некорректное (согласно sla ) исполнение). При этом общий доход строится из фикс оклада (40% от рыночного оклада на данную позицию) и премии, которая сверху ограничена лишь максимальным платежом от Заказчика по услуге за вычетом штрафов, маржинальность, затрат на центральный аппарат с ахо и поделённая между всеми участниками пропорционально вкладу (количество выполненных заявок помноженное на их нормативные показатели – удельный вес). Сразу оговорюсь, что эта идея только для людей, работающих в рамках процесса управления инцидентами/запросами на обслуживание.