Портал №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 не будет опубликован. Обязательные поля помечены *

  • Рубрики

  •  
  • Авторы

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

    • Метрики потока создания ценности
      Свой первый отчёт с данными о работе процесса в ИТ я сделал где-то в самом конце 90-х годов. Я тогда работал в поддержке, мне было важно понять как быстро мы выполняем заявки,
    • Я понял только то, что ничего не понял
      На тему услуг написано довольно много самых разных статей, т.к. оказание услуг – самый распространенный вид человеческой деятельности. Банковские услуги, гостиничные услуги, юридические услуги, логистические услуги; парикмахер, курьер, айтишник – все это деятельность в сфере услуг. Моя работа тоже относится к этой же сфере, поэтому не могу не поделиться своими наблюдениями, или, как говорится, поговорить о наболевшем.
    • DevOps-путешествие American Airlines
      Несколько лет назад компания American Airlines начала путешествие, которое первоначально было направлено на преобразование DevOps в ИТ, но в дальнейшем набирало обороты и переросло в преобразование доставки продуктов, охватывающее весь бизнес.
    • Чтение признаков: Паттерны диаграммы рассеяния (Lead Time Scatterplot)
      Научившись определять общие закономерности в диаграмме рассеяния времени цикла, вы сможете заметить проблемные области до того, как они разрастутся. Сегодня мы покажем вам, как распознать наиболее распространенные модели диаграммы рассеяния и объясним, что они означают для вашего проекта.
    • Проблемные зоны цифровой трансформации
      Управление на основе гибких методологий подразумевает наличие гибкой команды, занимающейся развитием цифрового продукта. Однако, такие команды не возникают сами собой, их
    • Чтение знаков: Паттерны Канбан CFD
      Чтобы улучшить рабочие процессы, сначала нужно понять, как определить проблемные области. Метод Канбан использует визуальные методы для оценки ваших процессов. Диаграмма совокупных потоков Канбан является особенно мощным инструментом. На них фиксируется количество задач в каждом состоянии процесса через регулярные промежутки времени, как правило, ежедневно или еженедельно.
    • Краткое руководство по DevOps для не ИТ-руководителя бизнеса
      Тщательно продумайте, как выглядит успех. В цифровом мире это скорость, гибкость, контроль и оперативность, а не составление планов и следование им. Именно эти новые ИТ-практики принесут вам эти преимущества. Они уже принесли их многим другим предприятиям, которые встали на этот путь и, в некоторых случаях, разрушили отрасли.
    • 8 тенденций развития IT Service Desk в 2022 году
      Корпоративная служба поддержки ИТ в настоящее время находится в «идеальном шторме» для изменений или, точнее, в «идеальном шторме» для необходимости изменений. Случилось так
    • 6 худших вещей, которые продакт-менеджеры говорят инженерам
      Каждый хороший продакт-менеджер — полиглот. Он говорит на нескольких языках. Конечно, вы можете не говорить бегло на французском, итальянском или мандаринском. Но вы
    • На какой курс пойти, чтобы узнать про практику Х?
      Этот вопрос вы, наши слушатели, задаёте довольно часто. К тому же появились новые курсы категории VAP. Так что было бы удобно иметь под рукой справочник. Ну что же, вот оно:
  •  
  • Вход

  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT