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

Оценка эффективности сотрудника ИТ-службы

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

Уважаемые коллеги!

Вопрос следующего свойства:

По книге "ITSM. Руководство по измерению" успешно внедряем индикаторы для процессов Inc mng и rf (Service request) mng, выбрали 2 индикатора TPI и TCR, как сбалансированные.

Вопрос в следующем:

  • Как однозначно оценить "эффективность сотрудника"? Т.к. если сотрудник 1 решил за месяц 200 обращений — у него TCR 0.78 и TPI 0.80, а второй решил 10 обращений и у него оба индикатора равны 1 (Идеальный). В описании измерений процессов не нашёл информации как сие реализовать, чтоб было честно с точки зрения сотрудника 1. 

Свой вариант:

  • Ввести "нормирование" количества обращений, выполненых за период, но данный вариант не предусматривает другие важные задачи (Проекты, Задачи менеджера процессов...) Т.е. мы не можем однозначно сказать, что сотрудник 2 не справился, т.к. у него всего 10 обращений, без анализа полной деятельности. 

Помогите разобраться, как соединить результаты по индикаторам и "общую эффективность"? Буду крайне признателен если найдутся примеры реальных кейсов.

Спасибо!

«Flow Metrics: управление потоковым производством на основе данных»
Учебный курс про метрики на реальных примерах

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

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

    Важным влияющим фактором будет характер работы: это сотрудник первой линии, это инженер сопровождения, это разработчик, это технический эксперт, решающий особенно сложные задачи? Достаточно грубым, но действенным способом является сравнение "производительности" сотрудников с их коллегами, если все они решают одинаковые рутинные задачи. Но, такие задачи должны быть действительно однородными в плане сложности/трудоемкости, поток задач — объемным, а участвующих в соцсоревновании более двух. Потребуется некоторый учет времени, т.к. если мы говорим об эффективности в терминах "задач в единицу времени", то это время нужно измерять, чтобы выбрасывать из него, например, работы выполненные в рамках проектных работ/изменений.

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

  • Сергей

    С моей точки зрения, как такового 1 показателя тут мало. Я  бы оценил еще сколько трудозатрат было затрачено данными работниками при решении указнных обращений. Сложность обращений, разложенную на типовые операции, временные интервалы  в которых проходило решение обращений.  А так просто может получиться что второй работник — лентяй и перебросил все на первого, а сам решает обращения, которые выеденного яйца не стоят. Отсюда и 100 %. И согласен с предыдущим автором действенным способом является сравнение "производительности" сотрудников с их коллегами, если все они решают одинаковые рутинные задачи.  У них сравнение идет по ряду показателей, часть которых является особенностью наше работы. И зависят от линий поддержки. 

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

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

    Реальный кейс описан тут: http://normirovanie-truda.ru/avtomatizaciya-processov-normirovaniya/

  • Иван Ситников

    Реальный кейс.

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

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

    3. Оценка выставляется от среднего уровня трудозатрат, где средний = 4, выше = 5, ниже = 3


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

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

  • Рубрики

  •  
  • Авторы

  •  
  • Самое свежее

    • 3 стратегии, которые помогут вашей команде принять метрику потока
      Вам необходимо эффективно управлять рабочими процессами, чтобы иметь возможность постоянно предоставлять ценность своим клиентам. Именно здесь в игру вступают метрики потока. Метрики потока являются основной движущей силой оптимизации процессов.
    • Новая модель предоставления ИТ-услуг: почему вам нужно ориентироваться на продукт
      Традиционно ИТ-организации делят все предоставляемые ими услуги на три уровня: инфраструктура (инфраструктура как услуга), платформа (платформа как услуга) и приложения
    • Как DevOps-командам следует использовать метрики DORA
      С момента выхода в 2018 году книги «Accelerate: Наука о бережливом программном обеспечении и DevOps», показатели DORA, которые она представила, стали популярным
    • Лучше делать хоть что-то, чем не делать ничего
      На конференциях по всяким Agile и DevOps мы часто слышим слово «unlearn» — забудьте то, что вы знали ранее! Измените свои представления о мире! Всё устроено
    • VI форум «Управление данными — 2021»: наведите порядок в данных!
      23 сентября 2021 года издательство «Открытые системы» в шестой раз проведет в Москве масштабный форум «Управление данными — 2021», объединяющий всех, кто определяет стратегию работы с данными, воплощает ее в жизнь и управляет предприятием на основе объективных достоверных данных. Участники форума обсудят не только инновационные стратегии и бизнес-модели работы с корпоративными данными, но и конкретные архитектурные и технологические решения.
    • Простые уловки, как ускорить процесс разработки программного обеспечения
      С некоторыми вещами люди из бизнеса вынуждены соглашаться, и одна из них заключается в том, что никто не хочет сердить свою команду разработчиков. Часто они являются краеугольным
    • Почему каждая инициатива DevOps должна начинаться с оценки возможностей
      Внедрение практики DevOps идет полным ходом. Организации сосредоточены на том, как внедрить возможности DevOps в командах и как масштабировать DevOps в масштабах предприятия. Но важным аспектом любого пути масштабной трансформации является оценка возможностей команды или организации на этом пути.
    • Что такое процесс и что такое практика в ITIL®4
      Продолжаем публиковать короткие видеоролики, посвященные актуальным вопросам управления ИТ. Сегодня поговорим о том, что такое процесс и что такое практика в ITIL4. Это не переименование процессов в практики, это два отдельных понятия. Рассказывает Игорь Фадеев, ITIL 4 Managing Professional и ITIL 4 Strategic Leader, аккредитованный тренер по ITIL4.
    • Аудит. Что может быть скучнее?!
      На прошедшей неделе участвовал в аудите (в качестве объекта аудита). Большинство людей, проходивших аудит, подозреваю, разделяет это ощущение: «Бюрократия, формальности и т.п.»
    • Как технический долг вредит вашей команде программистов — и вашей безопасности приложений
      Техническая долг может серьезно повлиять на здоровье организации - и на психическое здоровье ваших разработчиков. Более половины из 200+ членов инженерных команд, опрошенных в рамках отчета Stepsize "Состояние технического долга в 2021 году", считают, что технический долг негативно влияет на моральное состояние их команд.
  •  
  • Вход

  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT