Портал №1 по управлению цифровыми
и информационными технологиями

Сдельная оплата труда сотрудников техподдержки

Опубликовано 13 декабря 2017
Рубрики: Service Desk, Вопрос из зала, Обо всём на свете, Практика и опыт, Финансы ИТ
Комментарии

В редакцию портала поступил вопрос:

Всех приветствую

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

— С какими сложностями при этом встретились и как их преодолевали;

— Какие параметры оценки эффективности сотрудников в конечном итоге применили;

— На какие грабли не стоит наступать в этом вопросе;

— Какие встречались кейсы по минимизации проблемы необъективных KPI.

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

Имеется:

Техподдержка состоящая из 20 сотрудников. Обращения поступают в основном по телефону. Помимо обработки таких обращений сотрудники выполняют текущие задачи по установке оборудования, программного обеспечения, выезды на объекты компании и т.п. Техподдержка работает 14 часов/7 дней в неделю/365 дней в году.

ИНТЕНСИВ С ТРЕНЕРОМ
VAP: Экономика и финансы ИТ
Бюджетирование, аллокация, расчёт себестоимости, планирование ресурсов

Также по теме:

Комментариев: 11

  • Сергей

    Приветствую. о своём опыте.
    1. “Ставка” специалиста по сдельной оплате подразумевается выше чем постоянной (работа за з\п), т.к. специалисты зарезервированы (что б SLA не провалить) но могут сидеть без заявок – если их нет.
    2. Сдельную оплату стоил по списанному специалистом времени по заявкам и регламентным работам – трудозатратам (тут важен жесткий контроль за списанием трудозатрат, что бы и приписок не было и т.д.). Не забываем при списании трудозатрат учитывать обычные или сверхурочные.
    3. Так как оплата сдельная (ставка у каждого специалиста своя) вопросов разделения сложности исполненных заявок не стоит.
    4. В SLA-уложился в периоде – ок (штрафных санкций не начисляем), сколько времени затратил в периоде – ХХХХчасов (из них по обычной ставке – ХХХ, по сверхурочной – ХХХ).
    Профит.

    • Nargiza Suleymanova

      Позволю добавить по пункту 2:
      желательно иметь нормо-часы выполнения тех или иных заявок/задач, и вот если сотрудник уложился в норму, то проверять не обязательно (я бы даже стимулировала исполнение задач раньше срока оплатой не фактического времени, а по ставке нормы).
      и еще по сверхурочным: нужно понимать, что выполнение заявок типа “инцидент” в сверхурочное время вполне обосновано, а вот с запросами на обслуживание и регламентными работами нужно предусмотреть некоторое согласование во избежание фрода

      • Дмитрий

        Nargiza,
        1. Правильно понимаю: прежде чем выполнять задачу она должна быть занесена, скажем, в что-то наподобие Каталога услуг. В Каталоге учитывается нормативное время выполнения задачи и её стоимость?

        2. Делалась ли какая-то поправка, когда во время технический специалист не укладывался по независящим от него причинам? Допустим при удаленном доступе на стороне пользователя/заказчика плохо работает интернет или производительность оборудования оставляет желать лучшего и медленно происходит копирование данных?

        3. Что бывает, когда “прилетает” задача, которая не указан в Каталоге? Или она не совсем типовая, устанавливается коэффициенты, которыми можно поправить нормативное время выполнения? Упрощенный пример: восстановление базы. Одно дело восстановить базу с данными за неделю, другое дело восстанавливать базу с данными за месяц.

        4. Работают ли по этой системе сотрудники в несколько смен, например утренняя и вечерняя? Если да, то как происходит передача выполнения заявок/задач, когда у одного сотрудника заканчивается смена и заявку/задачу должен передать другому?

        • Nargiza Suleymanova

          Дмитрий, прошу прощения что так долго не отвечала. Давайте по пунктам:

          1. У нас есть список типовых задач в разрезе разных типов заявок. Работа была проделана в свое время титаническая, конечно, но она реально полезная

          2. Да, конечно делаем поправки на такие случаи. Все простои не по вине исполнителя учитываются в системе (но также следим за фродом)

          3. Есть задача типа “консультация/другое”, на которую есть стандартная ставка и нормо-часы. Но они изучаются потом и добавляются в стандартные задачи

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

    • Дмитрий

      Сергей, ставка выражалась в стоимости часа работы?
      И правильно ли понимаю, что задачи делились по сложности? Задачи не сложно типа передаются сотрудникам, назовем, первого уровня, а остальные задачи – сотрудникам второго уровня?

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

      Были ли какие-то коэффициенты сложности, которые обосновать увеличение трудозатрат, если задача не совсем типовая (кроме как выполнение работ в сверхурочные часы)?

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

      • Сергей

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

        по РР было нормативное время (тут реально надо понимать механизм РР который был у нас реализован с привязкой к конкретным КЕ).
        На заявки как такового норматива не разрабатывали (опять же что б не усложнятся) но существовал жёсткий аудит выполненных заявок\списания – и если у проверяющего возникал вопрос почему вдруг (как пример) на замену картриджа списали больше 40 минут – этот ответ должен был быть дан в описании к закрытию заявки. Если описания не было или было непонятно почему так долго – повод провести аудит работы этого специалиста.

        Кооф. сложности не было. См.выше к описанию если вдруг требовалось больше времени чем “обычно” описание должно быть почему так. (без фанатизма конечно, из-за 5 минут превышения никто не ждал что будет написана поэма) 🙂

        Штрафные санкции применялись только к SLA (не к списанию). И только после выявления и разбора что косяк именно специалиста или группы (а не манагеров, кадров не успевших нанять спецов и т.д.)…
        Конечно возврат в работу это ЧП и рассматривалось так же детально. Почему, и т.д. – автонаказания не было.

  • Шамиль Бабаев

    Добрый день,
    Вопрос довольно широкий и требует многих уточнений. Я решил чуть-чуть пофантазировать и вот что из этого вышло. Предполагаю из вашего кейса о наличии необходимых средств автоматизации. А также отсутствие трёх линий поддержки, то есть ваша поддержка не просто регистрирует поступающие обращения по телефону, но и решает их. Есть некий фиксированный каталог работ. Оплата производится раз в отчетный период. В каталог работ включена также оплата за обработку телефонных звонков пользователей заказчика.

    Я пойду от вашей структуры:

    — С какими сложностями при этом встретились и как их преодолевали

    1. Левые потоки обращений. Хорошо пресекаются пользователями при получении информации о созданном обращении.
    2. Неправильная классификация(Категория или приоритет(например: за решение обращения с приоритетом 2, мы платим 5 рублей, а с приоритетом 5 – 100 рублей)). Опять же либо от пользователя(если он заинтересован бить в колокола) + случайная выборка.
    3. Переназначение решенных обращений другими сотрудниками. Ведение истории переназначений. Учёт количества своих обращений самими сотрудниками.
    4. Долгое время выполнения текущих задач. Выставление сроков решения для таких задач.
    5. Решение просроченных обращений. Производить оплату по сниженной ставке(в зависимости от времени просрочки).

    — Какие параметры оценки эффективности сотрудников в конечном итоге применили

    Как пример, возможные метрики для работы на телефоне.

    Для пресечения «левого потока» звонков:
    Доля звонков, несвязанных с обращениями на портале обработки обращений (далее – ЗНСО).

    По статусу в линии:
    Доля статуса «Готов» за текущую смену.
    Доля статуса «Занят» за текущую смену (Имеется ввиду обработка входящего звонка с линии).
    Соответственно зная эти два показателя, мы понимаем долю статуса «Не готов» за текущую смену. Тут стоит уже разобраться в причинах, а именно ушло ли время на положенные ТК РФ и регламентируемые внутренним распорядком перерывы в работе и какие-то потоки задач или на что-то ещё.
    Из этого анализа, мы можем выявить следующую метрику:
    Доля статуса «Не готов» по нелегитимным причинам и за отчетный период. Для удобства назовём её НГНП.

    По учёту звонков (относится к статусу «Готов»):
    Доля непринятых звонков за текущую смену.
    Доля скинутых звонков за текущую смену. (Со стороны поддержки)
    Простой математикой мы поучаем:
    Доля необработанных звонков за отчетный период. Для удобства назовём её НЗ

    Доля простоя в обработке звонков = ЗНСО + НГПН + НЗ
    Далее пример: если предположим, за обработку (в том числе готовность к обработке) звонков по телефону мы платим 10 000 за отчетный период, то за простой в обработке звонков в 50% – заплатим 5 000.

    Плюсы:
    1) Предложенные метрики по учёту звонков решают сложности с нахождением на постоянной основе в статусе «Готов»
    2) Стимуляция мотивации обработки звонков по телефону
    Сложности:
    1) Пресечение злоупотреблением долгих разговоров
    2) Выявление нелегитимных причин

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

    — На какие грабли не стоит наступать в этом вопросе;
    Отсутствие контроля
    Оплата без дифференциации (это зависит от того, что нам важно(срок, влияние, вес, удовлетворенность пользователя, etc)

    — Какие встречались кейсы по минимизации проблемы необъективных KPI.
    Если мы платим за каждую выполненную работу, то количество поступивших обращений мы учитываем в любом случае. А вместе с количеством, нам нужно определить то, что нам важно (например, качество(удовлетворенность пользователя, ршение в срок) и сложность(инцидент 3 категори) каждой выполенной работы). То есть опять же, один показатель не работает.

    • Дмитрий

      Шамиль, ряд вопросов:
      1. Одна из предложенных метрик – “Доля звонков, несвязанных с обращениями на портале обработки обращений (ЗНСО)”. Я правильно понимаю, что это звонки, в ходе которых к ИТ-сотруднику (техподдержке, сервис-деска и т.п.) обращались напрямую?

      2. Метрика “Доля непринятых и скинутых звонков”. Правильно понимаю, что это групповые показатели? Наверно неправильно будет применять штрафные санкции к тому у кого статус “Не готов” в течении дня приближался к нулю и при этом остались непринятые звонки. При этом время устранения сбоев не превышало установленного времени.

      3. В итоге верно ли, что получаем метрики, которые если и зависят от количества поступаемых сообщений, то в малой степени. В этом случае оцениваем:
      – Готовность сотрудника техподдержки помочь. Отслеживание статуса “Готов”/”Не готов”
      – Работу сотрудника с поступившими обращениями. Оцениваем по времени, которое потратил на устранение сбоя. Если уложился по времени, то молодец – получаешь полную плюшку от стоимости задачи, если не уложился её часть по заранее оговоренной схеме.

      4. Какая практика с расчетом Фонда оплаты труда (ФОТ)?
      При расчете заработной платы смотрим какая доля каждого сотрудника в “общее дело” и пропорционально производим оплату?
      Или ФОТ делаем если не безлимитным, то с высокими границами, чтобы позволить сотрудникам хорошо поработать и тем самым хорошо получить?
      При этом имеется ввиду техническая поддержка внутренних пользователей.

      • Шамиль Бабаев

        Дмитрий,
        Прошу прощения за долгий ответ. Пойду от Вашей структуры для удобства:
        1. Не так. Звонки напрямую необходимо исключить (например, убрать из адресных книг, обязать не раздавать). Я лишь хотел показать, в чем может быть уловка. Идея в том, что сотрудники поддержки активно коммуницировали с пользователями. В итоге самые напористые обрели своих “любимых” IT-шников, с которыми можно поговорить не только в контексте Каталога услуг, но и о погоде, что выбрать Xbox или PS4. Так вот если мы платим за готовность и саму обработку входящего звонка, то такие пользователи действовали не в ущерб своим “любимчикам”. Соответственно, для исключения этого и фиксации всех обращений, даже с нулевым коэффициентом (ошибочный звонок) требуется фиксировать все поступающие звонки на портале поддержки. Именно поэтому требуется продумать механизмы контроля (например, случайная выборка записанных звонков, связанных с различным типом обращений (чтобы избежать фрода с регистрацией “левых” обращений)).
        2. Нам же необходимо рассчитывать зарплату не на группу, а на отдельного сотрудника за смену. То есть, когда поступает звонок на линию, в зависимости от заложенного алгоритма, он идёт к одному сотруднику. Если в течении условно трёх гудков трубка не была поднята, то звонок уходит к следующему сотруднику поддержки. Звонки с линии поступают только в том случае, когда оператор находится в статусе Готов.
        3. Отслеживаем “Готов”/”Занят”/”Не готов” и определяем контролируем во избежание фрода.
        4. Для ФОТ верхний край соответствовал максимальной цене на рынке. По Вашему кейсу, техническая поддержка включает в себя сотрудников универсалов, поэтому этот вариант будет близок. То есть берём минимальную и максимальную рыночную (либо ту, которую Вы готовы платить) стоимость и между ними ставим забор. Например, если доля выполненных работ(звонки/обращения/текучка) с должным качеством и сложностью превышает xx%, то попадаем в верхний ценовой диапазон. А дальше смотрим на количественные показатели, чтобы установить цену внутри промежутка от забора до максимальной стоимости.

  • Владимир Невский

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

    Это привело к тому, что руководство компании не было заинтересовано, чтобы первая линия решала как можно больше обращений в точке контакта (особенно, когда кол-во обращений существенно подросло). А иметь первую линию, которая ничего не решает, а только регистрирует и маршрутизирует обращения, по отношению к Заявителям – не так привлекательно, т.к. от этого страдает время решения обращения и клиент ориентированность. В общем, целесообразнее иметь собственною первую линию, а не пользоваться услугами аутсорсинга.

  • Сергей

    Вопрос правильный.
    Однако, поддержка (не всегда, но как правило) это нечто сложнее, чем call-центр.
    Поэтому со сделкой всё не так просто.

    Для начала – у разных линий совершенно разные КПЭ. Ту линию ,которая напрямую принимает заявки по телефону, возможно, и не имеет смысл отправлять на сделку.

    Однако, как же нам отследить , кто принимает обращения лучше, а кто – хуже? Для этого надо разобраться – хотя бы поверхностно – в Вашей “кухне”. Обычно это самые простые показатели – количество принятых обращений, обратная связь (отзыв, например). Всё остальное не столько КПЭ, сколько метрики. Мало обработал? По каким метрикам можно понять, почему так вышло? Скорее всего – либо банально не отвечал на звонки либо слишком долго возился с каждым обращением.

    Ну и так далее разбираете. Тут нет никакой магии, надо просто подумать и распутать эту гирлянду.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM
Авторы и редакторы портала — консультанты и тренеры компании Cleverics.
Использование материалов данного сайта допускается исключительно с разрешения правообладателя.
Использование данного сайта означает согласие с обязательством соблюдать нашу Политику конфиденциальности и Согласие на обработку персональных данных.