Примеры kpi для отдела it – Какой KPI применяется к системным администраторам/системным техникам/тех.поддержке? | Дропшиппинг

Содержание

Показатели эффективности (KPI) для сотрудников ИТ / Habr

Эта статья родилась из вопроса мего друга — ИТ директора компании Балтмикс (крупнейший производитель техники в России, основной поставщик техники для сети Эльдорадо) о измерении эффективности работы своих сотрудников.
Не без моих усилий был создан клуб ИТ директоров Калининградской области. Собственно, письмо было отправлено членам клуба.

Далее его письмо:

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

Сисадмины
Адм.баз данных
Техподдержка (сервисдеск)
Инженеры
Программисты
Аналитики: эксперты по ERP-системе, каждый в своем бизнес-направлении: производство, логистика, финансы…

С п.1-4 более-менее всё понятно и измеримо. А как оценивать работу п.5, а особенно 6?

Мой ответ:

Как и обещал, отвечаю 🙂 как всегда с небольшим опозданием.

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

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

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

Что я делал для создания KPI:

Нашел, относительно чего можно оценивать эффективность
Понял, как можно оценивать
Сделал прозрачную систему оценки эффективности в числах

Как я предполагаю, мало кого заинтересует мой непосредственный опыт. Т.к. я управляю процессами разработки и создания программных продуктов и специализируюсь в этом. И далее также планирую развивать себя как специалиста в этой области. Это моя сильная сторона. Я расскажу общие принципы, которыми я пользовался для оценки деятельности своих специалистов.

Как найти точку опоры для KPI

Я определил цель работы каждого подразделения и сотрудника в двух аспектах:

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

Не менее важно определить результаты деятельности специалистов. Для этого достаточно ответить на два вопроса:

Что должно получиться в результате его работы?
Каким должен быть процесс? (если процесс бесконечен, например, поддержка)

Так же важно понимать временной интервал контроля. Для себя я его определил как неделю — 40 часов.

Что является объектом контроля

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

Контроль в числах

Как я уже писал, общей формулы у меня нет и я сомневаюсь в возможности её составить. Но точно можно и необходимо вывести её для любой позиции, в том числе в нашей сфере — ИТ. Я предложу только предметы для оценки. Теперь по пунктам вопроса.

Системные администраторы

Безопасность

может быть оценена внешним, независимым, агенством

Часы бесперебойной работы

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

Администраторы баз данных

Скорость получения данных (отклика)

Это относительная цифра, необходимо считать её в зависимости от задачи. У меня это 0.2с

Скорость обновления данных — актуальность данных

Аналогично

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

Это количество часов, которое потребуется администратору для восстановления системы. Я всегда рассматриваю несколько сценариев: от потери одного диска в рейде до потери сервера.

Бесперебойная работа — надёжность и безопасность

аналогично сис.админу

Тех поддержка, Скорость ответа, Количество решенных задач, к не решенным, Количество задач, которые удалось решить, не прибегая к помощи других отделов, Удовлетворенность пользователей

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

Программисты

Безопасность

не буду повторяться

Скорость работы приложений

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

Отказоустойчивость

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

Соответствие прототипу и тз

Честно говоря не нашёл численных методов оценки этой немаловажной характеристики. Мне повезло с тестером, он отлично чувствует и пинает программистов, если что-то не так.

Количество эффективных часов

Это часы адекватно оцененные при планировании деятельности
Сколько таких часов у программиста в неделю, месяц, год

Эффективные часы — это время, которое уходит только на решение задачи. Когда ничто не отвлекает, никто не мешает. Далее, соотнося эти часы с длиной итерации (в моём случае это с 40-часовой рабочей неделей), можно легко найти причины неэффективности работы и повлиять на них.

Аналитики

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

Окончание

Я знаю и понимаю компании в, которых подобный учёт не ведется. Мой подход сформировался при жестких ограничениях со стороны основного заказчика — инвестора. Я действительно считаю часы эффективной работы своих сотрудников и контролирую процессы разработки. У меня есть свой «прогресс бар» движения проектов, а так же то, что я отмечаю отдельно. Я добился минимизации затрат, на счет «ворон» сотрудниками. То есть максимальной эффективности и осознанности при работе в проекте.

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

7.1. Ключевые показатели эффективности ИТ-подразделения

Для различных видов бизнеса служат разные показатели, как правило, они называются ключевыми показателями эффективности (Key Performance Indicators, KPI). Одно из требований к показателям – измеримость. Для оценки эффективности информационных технологий служат различные показатели, причем применение тех или иных показателей связано с уровнем зрелости предприятия в области использования информационных технологий, а также с уровнем зрелости самого ИТ-подразделения.

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

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

На нулевом и первом уровнях, когда основная финансовая составляющая ИТ-подразделения – это зарплата сотрудников, то эффективность ИТ-подразделения можно оценивать по соотношению числа ИТ-сотрудников и общего количества работников компании. Ориентир: один ИТ-специалист на 40–60 человек, в зависимости от размера предприятия. Более детальные цифры приведены в разделе,

На втором и третьем уровне зрелости ИТ-подразделения по CobiT, когда затраты на ИТ начинают в большей степени определяться инвестициями в информационные технологии, возможно переориентироваться на показатель – стоимость ИТ: затраты связанные с ИТ-персоналом, плюс затраты на информационные технологии в процентах от оборота компании. В таком случае для компании, чей бизнес интерес не лежит в области информационных технологий, этот процент лежит в диапазоне от 2,7 до 6,5, но также необходимо не забывать о масштабе предприятия. Для высокотехнологичных бизнесов сумма бывает больше. Более подробная информация представлена в.

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

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

Изначально, в разделе»» мы рассматривали пример, где уровень зрелости ИТ-подразделения – третий. Рассмотрим KPI ИТ-подразделения при ранее введенных условиях и ограничениях. На данном этапе зрелости в ИТ-подразделении уже разработаны и применяются все внутренние в внешние регулирующие документы; четко описано и формализовано «Соглашение об уровне предоставления услуги (Service Level Agreement, SLA)» с Заказчиком; описаны и закреплены все функции ИТ-подразделения за конкретными ИТ-сотрудниками (подготовлена матрица ответственности), внедрены и успешно функционируют инструменты сбора и обработки Заявок пользователей ИТ-сервисов. К такому ИТ-подразделению могут быть применены следующие KPI показатели:

1) Нарушения SLA – сокращение до минимума времени недоступности информационных сервисов и возможных экономических потерь предприятия в результате их простоя. Максимальный и минимальный уровни простоя по каждому ИТ-сервису определены соглашением об уровне качества (SLA). Целевое значение показателя – 0;

2) Количество инцидентов по инфраструктуре и связи – показатель призван фиксировать количество инцидентов по инфраструктуре и связи. Целевое значение показателя – 0;

3) Общая неработоспособность рабочих мест пользователей по инцидентам по инфраструктуре и связи – в связи с зарегистрированными инцидентами, производится подсчет часов простоя рабочих мест пользователей. Целевое значение показателя – 0;

4) Количество инцидентов по АСУТП – показатель призван фиксировать количество инцидентов по АСУТП. Целевое значение показателя – 0;

5) Общая неработоспособность рабочих мест пользователей по инцидентам АСУТП – в связи с зарегистрированными инцидентами, производится подсчет часов простоя рабочих мест пользователей. Целевое значение показателя – 0;

6) Рост количества открытых заявок не более запланированного – показатель определяет верхнюю границу роста количества открытых заявок в отчетном периоде по каждому направлению деятельности ИТ-подразделения (функции). Показатель рассчитывается в процентах к количеству открытых заявок на начало отчетного периода;

7) Рост количества выполненных заявок выше запланированного – показатель определяет нижнюю границу количественного выполнения Заявок пользователей ИТ-сервисов. Данный показатель применяется совместно с показателем «Рост количества открытых заявок не более запланированного», сокращая количество открытых Заявок предыдущих периодов. Показатель рассчитывается в процентах к количеству поступивших заявок за период;

8) Рост количества открытых Изменений не более запланированного – показатель определяет верхнюю границу роста количества открытых Изменений в отчетном периоде по каждому направлению деятельности ИТ-подразделения (функции). Показатель рассчитывается в процентах к количеству открытых Изменений на начало отчетного периода;

9) Рост количества выполненных Изменений выше запланированного показателя определяет нижнюю границу количественного выполнения Изменений по ИТ-сервисам. Данный показатель применяется совместно с «Рост количества открытых Изменений не более запланированного», сокращая количество открытых Изменений предыдущих периодов. Показатель рассчитывается в процентах к количеству поступивших Изменений за период;

10) Количество просроченных заявок за период по предприятию – если Заявка была принята в работу и не реализована к намеченному сроку, причем к ней не был применен механизм перенесения сроков (по согласованию с Заказчиком), то какие заявки считаются просроченными. Данный показатель ограничивает сверху количество просроченных заявок для ИТ-специалистов. Показатель может быль применен как к отдельному направлению ИТ-услуг, так и к службе в целом.

11) Повышение качества обслуживания запросов внутри организации (снижение времени реагирования и/ или исправления неисправностей) – минимальное время реакции на неисправность закреплено в SLA. Данный показатель направлен на снижение времени реакции. Рассчитывается как процент улучшения показателя по сравнению с предыдущим отчетным периодом;

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

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

14) Оценка степени удовлетворенности пользователей услугами ИТ на основании результатов анкетирования – показатель отражает текущий уровень удовлетворенности пользователей ИТ-услуг. Более детально рассмотрим как необходимо выполнять анкетирование в разделе»»;

15) Оценка степени удовлетворенности руководителей предприятия качеством ИТ – услуг: данный показатель отражает свою суть в названии. Оценка выставляется и согласовывается на Комитете ИТ и утверждается председателем Комитета. Обычно оценка имеет следующий диапазон значений:

а) Хорошо – результат деятельности превосходит запланированный по всем или части показателей эффективности;

б) удовлетворительно – результат деятельности подразделения сопоставим с ожиданиями: выполнены все плановые показатели в 100 % объеме;

в) неудовлетворительно – результат деятельности подразделения не удовлетворяет ожиданиям;

16) Бюджет БДДС и БДР по статье «Расходы на информационные технологии» и «Связь» не превышен по отношению к бизнес-плану за квартал – снижение (без ущерба для эффективности) стоимости владения ИТ.

Конечно же, каждый показатель KPI, применяемый для оценки эффективности имеет свой вес, что и делает оценку – сбалансированной.

Вывод: Для оценки эффективности ИТ-подразделений служат различные показатели, причем применение тех или иных показателей тесно связано с уровнем зрелости ИТ-подразделения.

Данный текст является ознакомительным фрагментом.

Читать книгу целиком

Поделитесь на страничке

Следующая глава >

KPI по ИТ :: ИТ-стратегии

На этой странице рассмотрены KPI по ИТ. Это один из 20 основных элементов ИТ, которые целесообразно учитывать при планировании ИТ на 1 год и более, в том числе в рамках разработки ИТ-стратегии.

Элементы ИТ, рассматриваемые на этом сайте:

KPI по ИТ (Key Performance Indicators) — это ключевые показатели работы ИТ. Обычно под «KPI по ИТ» понимают оценку работы ИТ в целом, но есть и KPI как по отдельным направлениям работы ИТ (например, по службе поддержки ИТ), так и по поддержке ИТ (например, по специалистам по поддержке 1С).

Для разработки KPI по ИТ на 1-3 года вперед целесообразно рассмотреть:

требования бизнеса к ИТ
цели ИТ
имеющиеся показатели оценки ИТ (в вашей компании, у конкурентов и партнеров)

Ожидаемые выгоды для бизнеса и ИТ от улучшения KPI по ИТ:

Возможно улучшение работы по ИТ по всем направлениям, прописанным в KPI, часто это внедрение информационных систем и улучшение поддержки уже имеющихся информационных систем и инфраструктуры ИТ:

Обозначения:

существенные улучшения

частичные улучшения

Хотя нередки случаи, когда сотрудники ИТ начинают работать только по направлениям, записанным в KPI» и «забивая» на все остальное.

Размеры компаний, которым целесообразно улучшать KPI по ИТ

KPI по ИТ уместны для больших ИТ-служб, скорее от 10-15 человек, когда работа каждого конкретного сотрудника не особенно видна всем остальным сотрудникам:

Кому лучше улучшать KPI по ИТ

ИТ-директору, совместно с гендиректором и консультантами по ИТ.

Разделы ИТ-стратегии, где рассматривается KPI по ИТ

KPI по ИТ рассматривают в отдельном разделе, или в разделе «Управление ИТ»:

Варианты ИТ-стратегий, в которых разрабатывается KPI по ИТ

KPI по ИТ требуют немало времени на разработку (2-4 календарных месяца), поэтому их разрабатывают в «подробной» ИТ-стратегии, ну, может, и в «средней»:

Обозначения: «√»: входит в вариант; «+-»: частично входит; «$»: может входить в вариант, но за отдельную стоимоcть

Методики, предлагаемые для улучшения KPI по ИТ

Для разработки KPI по ИТ, на этом сайте предложена методика «KPI по ИТ»:

Обозначения:

существенные улучшения

частичные улучшения

Отрасли, для которых целесообразно улучшать KPI по ИТ

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

Ресурсы, требуемые на разработку KPI по ИТ

Ресурсы сильно зависят от размеров компаний, для средних по размеру компаний их можно оценить в 20-40 человеко-дней работ, а то и более:

Основные этапы улучшения KPI по ИТ

Определение требований бизнеса к ИТ;
Определение требований ИТ к ИТ;
Определение шкал для оценки достижения каждого из требований;
Разработка KPI на ближайший год.

Подходы к улучшению KPI по ИТ

Подходы к улучшению KPI по ИТ разработаны на базе методик стратегического планирования ИТ, практическом опыте руководства ИТ и консалтинга, опросов ИТ-директоров российских компаний, ряде публикаций по ИТ-стратегиям и улучшению управления ИТ:
см. более подробно источники методик

Методики улучшения управления ИТ, согласования ИТ и бизнеса, разработки ИТ-стратегий, а также элементы ИТ, которые надо учитывать при планировании развития ИТ на 1-3 года рассмотрены в книге Александра Михайлова «ИТ стратегия: лучшие международные и российские практики», 412 страниц:

более подробно о книге.

Статьи по этой теме:

KPI по ИТ разрабатывается в следующих типовых услугах по консалтингу и обучению:

Обозначения: «√»: входит в вариант; «+-»: частично входит; «$»

б) в рамках разработки «средней» ИТ-стратегии на 50 и более страниц (2-3 календарных месяца, от 50 человеко-дней) в рамках услуги «Совместная с консультантами разработка ИТ-стратегии на 50-150 страниц, для средних компаний».

в) в рамках разработки «подробной» ИТ-стратегии в рамках услуги «Консалтинг по разработке ИТ-стратегии на 150-300 страниц», для крупных компаний.

г) в рамках услуги «Оптимизация ИТ«, уместно для крупных и средних компаний.
В рамках консалтинга по KPI по ИТ можно выбрать любые из 9 методик, рассмотренных на этом сайте, а также выбрать для улучшения любые из 20 элементов, рассмотренных на этом сайте

д) разработка KPI по ИТ, исходя из приоритетов бизнеса, выполняется в рамках услуги «Совместная с гендиректором оптимизация ИТ под требования бизнеса», в рамках согласования требований бизнеса к ИТ, целей ИТ и их связей с проектами по ИТ.

е) KPI по ИТ определяется в рамках услуги «Планирование цифровой трансформации бизнеса».

ж) в рамках услуги «Персональный советник по ИТ» может быть выполнен контроль выполнения KPI по ИТ.

Другая информация по KPI по ИТ и смежным темам:

Предложения для ИТ-директоров российских компаний

(а также гендиректоров, ИТ-менеджеров и бизнес-менеджеров)

Показатели эффективности (KPI) для сотрудников ИТ

Не без моих усилий был создан клуб ИТ директоров Калининградской области. Собственно, письмо было отправлено членам клуба.

Мой ответ:

Как и обещал, отвечаю 🙂 как всегда с небольшим опозданием.

Что я делал для создания KPI:

Нашел, относительно чего можно оценивать эффективность
Понял, как можно оценивать
Сделал прозрачную систему оценки эффективности в числах

Как найти точку опоры для KPI

Я определил цель работы каждого подразделения и сотрудника в двух аспектах:

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

Что должно получиться в результате его работы?
Каким должен быть процесс? (если процесс бесконечен, например, поддержка)

Так же важно понимать временной интервал контроля. Для себя я его определил как неделю — 40 часов.

Что является объектом контроля

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

Контроль в числах

Системные администраторы

Безопасность

может быть оценена внешним, независимым, агенством

Часы бесперебойной работы

Администраторы баз данных

Скорость получения данных (отклика)

Это относительная цифра, необходимо считать её в зависимости от задачи. У меня это 0.2с

Скорость обновления данных — актуальность данных

Аналогично

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

Бесперебойная работа — надёжность и безопасность

аналогично сис.админу

Тех поддержка, Скорость ответа, Количество решенных задач, к не решенным, Количество задач, которые удалось решить, не прибегая к помощи других отделов, Удовлетворенность пользователей

Программисты

Безопасность

не буду повторяться

Скорость работы приложений

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

Отказоустойчивость

Соответствие прототипу и тз

Количество эффективных часов

Это часы адекватно оцененные при планировании деятельности
Сколько таких часов у программиста в неделю, месяц, год

Аналитики

Окончание

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

PS: хочу сделать свой блог в стиле «Я CIO»

KPI технической поддержки Миран / Дата-центр «Миран» corporate blog / Habr

» — А у вас случайно нет такого знакомого с красным лицом, тремя глазами и ожерельем из черепов? — спросил он.
— Который между костров танцует? А? Еще высокий такой? И кривыми саблями машет?
— Может быть и есть, — сказал он вежливо, — не могу понять о ком именно вы говорите. Знаете, очень общие черты. Кто угодно может оказаться.»
Виктор Пелевин, «Чапаев и пустота»

Привет, Хабр! Меня зовут Александр Соловьев, я руковожу технической поддержкой в дата-центре Миран.

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

Мероприятие было организовано сообществом специалистов техподдержки “SUPNET” которое, судя по последней публикации на их официальной страничке, от сентября 2018, “ушло в нирвану”.

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

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

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

Итак, KPI у нас делятся на три группы:

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

Показатели эффективности

Начну с эффективности.

Cредняя зарплата инженера техподдержки;
FRT — среднее время первого отклика на заявку;
ART — среднее время выполнения заявки;
MTTR — среднее время ремонта.

Средняя зарплата инженера

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

FRT / ART

Оба показателя “растут” из SLA (Service Level Agreement). Следуя SLA, при превышении FRT / ART у клиента появляется право на перерасчет размера оплаты услуг подвергшихся деградации. На мой взгляд, эти индексы по смыслу похожи на среднюю температуру по больнице). В практическом плане пользы от индексов не много, единственное что они позволяет менеджменту компании понять что заявленные в SLA показатели примерно выполняются. Гораздо полезнее процент нарушений времени реакции / выполнения заявки, эти индикаторы позволяют быстро и наглядно оценить динамику обработки заявок технической поддержкой.

MTTR

Широко известный в узких кругах индикатор (он же, IRT — incident Resolution Time), среднее время ремонта, в нашем случае польза от индикатора невелика поскольку предоставляемые нашей компанией услуги по характеру очень разнятся. Может в дальнейшем будем считать MTTR отдельно для каждого продукта. Однако, поскольку это действительно известный индикатор мы его считаем.

Показатели результативности

Перейдем к результативности.

EKi — индекс уровня знаний сотрудника;
CSi — индекс удовлетворенности клиента обслуживанием;
FRTR — процент нарушения времени реакции на обращение;
ARTR — процент нарушения времени выполнения заявок.

CSi

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

Значение индекса зависит от трех параметров:

Время реакции на обращение, t₁;
Время решения заявки, t₂;
Качество решения заявки, q.

Формула для расчета CSi следующая:

Диапазон возможных значений параметров приведен в таблице

Полученные значения интерпретируются согласно следующей таблицы

EKi

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

Расчета индекса производится на основании объективных данных полученных в результате регулярной проверки тренировки знаний инженеров, проводимой по методике имитационного моделирования, а именно решения типовых ситуаций называемых юзкейсами. Кому интересно, подробнее про управление знаниями в техподдержке рассказывал на KnowledgeConf 2019.
В нашей компании EKi рассчитывается как отношение успешно выполненных юзкейсов к общему количеству юзкейсов за период.

где,
U_w — количество успешно решенных инженером юзкейсов за отчетный период;
U_a — общее количество решенных инженером юзкейсов за отчетный период.

Полученные значения интерпретируются согласно следующей таблицы

Уровни 0,85 и 0,95 получены нами экспериментально экспертно, в результате более чем двухлетней практики управления знаниями инженеров технической поддержки.

Процент нарушения времени реакции / времени выполнения

Индексы процент нарушения времени реакции / времени выполнения я упоминал выше. По сути показывают насколько часто техподдержка нарушает SLA в части времени реакции и времени выполнения заявок.

Производственные показатели

Ну напоследок, производственные показатели:

количество обработанных технической поддержкой заявок за отчетный период:
- из них звонков;
- из них сообщения от системы мониторинга;
- из них отклонено;
- из них клиентские;
количество заявок связанных с эксплуатацией продукта в отчетном периоде:
- из них инцидентов;
- из них обращений;
- суммарное время “отказа в обслуживании” для всех клиентов по продукту за отчетный период.

Есть правило определяющее соотношение KPI для оценки эффективности работы в целом. Согласно этого правила индикаторы должны распределятся в пропорции 10/80/10 = показатели эффективности / производственные показатели / показатели результативности.

По этой причине производственных показателей много и я остановлюсь только на самых важных с моей точки зрения.

Количество обращений в техническую поддержку

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

Поскольку обращения обращениям рознь, разумно дифференцировать общий поток обращений по совокупности источников обращений и “сущности” обращений. В нашем случае это системы мониторинга, входящие вызовы по телефону, ошибочные обращения и наконец клиентские обращения.

Количество заявок связанных с эксплуатацией продукта

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

Заключение

Когда было уже поздно что существенно менять Как обычно, после написания статьи гуглил KPI технической поддержки, нагуглил несколько интересных статей, в вот пара из них:
Осмыслил прочитанное и ничего в своей статье менять не стал, потому что так мне кажется честнее и естественней. При желании, читатель может проверить сам насколько наша техподдержка “в тренде”.

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

1. FCR — количество заявок решенных в рамках первого обращения за поддержкой;
2. FTFR — процент заявок решенных в рамках первого обращения за поддержкой.

KPI для любимых разработчиков от Юрия Лозинского

SostSource начинает серию статей на тему: как определять KPI (ключевые показатели эффективности) для главных сотрудников IT-компании. Это поможет создать атмосферу принятия ответственности и поддержки инноваций в вашей компании.

Автор статьи: Юрий Лозинский, CEO at DIGITALOUTLOOKS, г. Днепропетровск.

Начнем с причин, или как говорят в IT-отрасли, с «боли».

Идея внедрения KPI для разработчиков используется не для того, чтобы заставить их работать, или как правильно говорить, — «промотивировать».

Разработчики, в общем-то, и без KPI работают замечательно. Или не работают ☺

Основная задача руководителя — построить бизнес-модель компании и иметь инструментарий для what-if анализа. Чтобы понять, как построить систему сбалансированных показателей для IT-компании, коротко рассмотрим устройство бизнеса в общем.

Традиционно у компании есть центры затрат и центры генерации прибыли.

К центрам генерации прибыли относят:

Отдел продаж (прямо)
Отдел маркетинга (косвенно)
Отдел поддержки Клиента (апсейл и кросс-сейл)

К центрам затрат относят:

Производство.

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

Проецируем общие принципы на суровые будни IT компании и получаем:

Центры генерации прибыли:

Продавцы со своими бюджетами на технический присейл и маркетинг

Что касается центров затрат, то в случае IT-компании, производство объединяет разработчиков и всякого рода производственных менеджеров, которые осуществляют так же апсейл и кросс-сейл, частично выполняя функции генерации прибыли:

Разработчики
Руководители проектов
Руководители программ проектов

При этом, генерация прибыли от производства всячески приветствуется и культивируется, но в обязанности не ставится.

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

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

Начнем с разработчиков.

От разработчика я, как управленец ожидаю не чудес сверхпроизводительности в течении итерации(с последующей трёхмесячной реабилитацией в клинике для душевно-больных) , а прежде всего предсказуемости. Это необходимо для планирования и оценки, чтобы отдел продаж имел инструмент оценки объемов работ (назовем его Project evaluation score card) и мог в любой момент ответить на вопрос «Сколько?». Разумеется, с некоторой точностью.

Итак, я спокоен, если понимаю, что могу ожидать от своих разработчиков:

Выполнения работ с некоторым качеством. Качество мы измеряем количеством багов в итерацию
Выполнения работ в некоторые сроки. Отклонение от первоначальных сроков мы измеряем в процентах
Желание двигаться в перед и развиваться.

Если у Вас есть более трёх пунктов, с Вами что-то не так и вы не можете определиться с тем, чего хотите от своего производства.

Итак, выписываем в таблицу и ранжируем наши пожелания. При этом понимаем, что сумма весов каждого из пожеланий должна составлять 100% :

KPI Name	KPI Weight
Deliverables quality	35%
Deliverables ETA (%)	50%
Qualitative goals	15%
Total	100%

Для каждого из пожеланий определяем граничные значения.

Предположим я считаю, что 3 бага за итерацию, это вполне нормально.

Deliverables quality
KPI Name	Target Value
Bugs per iteration (+/-)	3

Отклонение от заявленного срока 5% -это тоже вполне приемлемо.

Deliverables ETA (%)
KPI Name	Target
Time to Delivery Deviation	5.0%

Личные планы развития разработчика должны совпадать с ценностями компании. Человек мог бы подтвердить свою квалификацию сертификацией и постоянно совершенствовать английский.

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

Qualitative goals
Deliverable Statement	Task Weight
Certification	20%
English	80%
	100%

Теперь – самое важное: «коммитмент» ☺

Несмотря на то, что «колхоз – дело добровольное», рекомендую все же ознакомить разработчика с его целями и задачами на ближайший период.

Чтобы объяснить разработчику, почему он должен «закоммититься» на выполнение этих показателей, мы предлагаем самую эффективную мотивацию. Денежную.

После того, как вы с разработчиком достигли понимания, вводите инструмент трекинга показателей и расчета будущей премии:

Deliverables quality
KPI Name	Target Value	Actual	Actual vs Target	KPI Execution
Bugs per iteration (+/-)	3	1	167%	167%

Итак, по итогам прошлого периода, разработчик допускал в среднем 1 баг за итерацию, что ведет к перевыполнению этого показателя: 167%

Deliverables ETA (%)
KPI Name	Target	Min Cutoff	Max Cutoff	Actual	Actual vs Target	KPI Execution
Time to Delivery Deviation	5.0%	70%	125%	6.0%	80%	80%

Немного хуже обстоят дела с попаданием в сроки – актуальные 6% выше запланированного 5% значения. При этом для данного показателя вводится понятие минимальной и максимальной границы.

Если разработчик в превышает оценку более чем на 70%, премии ему по данному показателю не видать.

С другой стороны, чтобы разработчик не завышал оценку, выполнение задач быстрее более чем на 25% к бесконечному линейному росту премии не приведут. Таким образом нет смысла завышать сложность работ, но при этом остается желание сделать работу чуть быстрее.

Qualitative goals
Deliverable Statement	Task Weight	Weighed KPI Execution
Certification	20%	1
English level: +1	80%	1
	100%	100%

С качественными показателями еще проще. Сертификат либо получен, либо нет. Уровень английского либо повышен, либо нет. Ставим 1 или 0.

В конечном итоге, получаем прозрачную модель, мотивирующую разработчика:

1.	Bonus
	Bonus Base	$6,000			-filled by employee (actuals)

	Bonus calculation
	KPI Name	KPI Weight	Target Bonus	Actual KPI Executoin	Actual Bonus
	Deliverables quality	35%	$2,100.00	167%	$3,500
	Deliverables ETA (%)	50%	$3,000.00	80%	$2,400
	Qualitative goals	15%	$900	100%	$900
	Total	100%	$6,000	113%	$6,800

2.	Deliverables quality
	KPI Name	Target Value	Actual	Actual vs Target	KPI Execution
	Bugs per iteration (+/-)	3	1	167%	167%

3.	Deliverables ETA (%)
	KPI Name	Target	Min Cutoff	Max Cutoff	Actual	Actual vs Target	KPI Execution
	Time to Delivery Deviation	5.0%	70%	200%	6.0%	80%	80%

4.	Qualitative goals
	Deliverable Statement	Task Weight	Weighed KPI Execution
	Certification	20%	1
	English	80%	1
		100%	100%

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

Наибольшую гибкость дает трёхмесячный контроль показателей.

Для примера хочу показать менее красивую картинку по выполнению показателей и соответственно, рассчитанную премию:

1.	Bonus
	Bonus Base	$6,000			-filled by employee (actuals)

	Bonus calculation
	KPI Name	KPI Weight	Target Bonus	Actual KPI Executoin	Actual Bonus
	Deliverables quality	35%	$2,100.00	33%	$700
	Deliverables ETA (%)	50%	$3,000.00	0%	$0
	Qualitative goals	15%	$900	80%	$720
	Total	100%	$6,000	24%	$1,420

2.	Deliverables quality
	KPI Name	Target Value	Actual	Actual vs Target	KPI Execution
	Bugs per iteration (+/-)	3	5	33%	33%

3.	Deliverables ETA (%)
	KPI Name	Target	Min Cutoff	Max Cutoff	Actual	Actual vs Target	KPI Execution
	Time to Delivery Deviation	5.0%	70%	200%	10.0%	0%	0%

4.	Qualitative goals
	Deliverable Statement	Task Weight	Weighed KPI Execution
	Certification	20%	0
	English	80%	1
		100%	80%

Хочу особо отметить, что данная модель никак не является заменой плановой аттестации. Скорее хорошим дополнение по существу: садимся, составляем набор KPI которые интересно выполнять разработчику и компании, проставляем значения и идем работать.

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

Если мы хотим точной оценки, то не нужно всех разработчиков — под одну гребенку. Предлагать нужно, конечно, «среднее по больнице», но лишь в качестве отправной точки. А вот конкретно какие будут у каждого показатели прописаны — это предмет «торга» на аттестации.

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

KPI для оценки работы службы поддержки клиентов.

В любой компании рано или поздно возникает вопрос мотивации сотрудников и задача по разработке схемы KPI (ключевых показателей эффективности), выполнение которых, обычно, приводит к премированию.

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

за выполнение / перевыполнение собственного плана;
связанную с планом отдела.

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

Нужны ли KPI сотрудникам техподдержки и IT-служб?

Существует мнение, что сотрудникам Help Desk не нужно придумывать КПИ. Кого-то это демотивирует, кто-то не верит в эффективность таких подходов. Мы придерживаемся принципов мотивации сотрудников на конечный результат, а не на условное время нахождения в офисе. И, конечно, схема работы по KPI гораздо более прозрачна и объективна.
Почему же важно разработать систему ключевых показателей эффективности? Во-первых, при таком подходе создается принцип соучастия и осознание того, что каждый влияет в целом на результаты компании. Во-вторых, работа по КПИ, как оценка в школе: используя достижение тех или иных метрик можно объективно оценивать динамику, а также видеть “успеваемость” специалиста и обоснованно принимать решение, например, о его повышении (в денежном виде, в виде должности или еще как-то).

Из минусов использования Key Performance Indicators можно отметить необходимость временных затрат на сбор и анализ показателей. Однако, любая современная система Help Desk значительно упрощает и эту процедуру.
Еще одной отрицательной стороной внедрения KPI является переключение инженеров только на выполнение показателей, которые на прямую влияют на расчет бонусов. При этом без внимания, зачастую, остаются другие важные активности и проекты, не влияющие на достижение поставленных метрик. Для того, чтобы этого избежать необходимо разработать комплексную схему целей и возможность ее реального достижения сотрудником.

Оценить преимущества облачного Help Desk!

15 000+ подписчиков. Присоединиться к рассылке

6 основных метрик работы тех.специалистов

В любой службе поддержки на верхнем уровне можно выделить 3 ключевые роли:

диспетчер;
специалист 2-й линии;
руководитель службы Help Desk.

В этой статье мы предлагаем рассмотреть 6 основных KPI для исполнителей заявок, то есть для сотрудников 2-й линии службы поддержки, которые помогут начать выстраивать комплексную модель ключевых показателей и мотивации (ключевые KPI для 1-й линии или службы help desk читайте в другой нашей статье):

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

Количество выполненных обращений в срок.

Одна из самых простых метрик. Внимание уделить стоит 2 аспектам:

отслеживание минимально допустимый порог по выполненным тикетам, например, не менее 10 в день
контроль % решения в обозначенный клиенту срок (SLA).

Количество решенных заявок по приоритетам.

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

Процент выполненных запросов с первого раза.

Решение тикетов “на поток” не должно являться самоцелью инженера 2-й линии поддержки.
Ключевым фактором качественной работы является выполнение запроса клиента с первого раза.
Зачастую, негатив от формального решения проблемы гораздо выше, даже чем от соблюдения временных обязательств.

Средняя оценка выполненных обращений клиентом.

Отличная, субъективная характеристика деятельности Вашего специалиста с обратной стороны.
Количество решенных заявок, соблюдение сроков — важные параметры для контроля.
Однако некая агрегированная оценка качества выполненных работ со стороны клиента (учитывает и общение, и соответствие ожиданиям, и множество других факторов), пожалуй, ключевой показатель, который, несомненно, должен занять должное место среди КПИ специалистов 2-й линии поддержки.

Процент списания трудозатрат по решенным инцидентам.

Если Ваша компания и процессы поддержки достаточно зрелые, необходимо переходить к учету и контролю показателей, которые влияют на бизнес. Так, автоматизация процесса учета трудозатрат позволяет не просто объективно контролировать загруженность Ваших работников, но и, например, принимать решение о пересмотре стоимости тех.поддержки для клиентов (при превышении затрат на поддержку по контракту, выраженному через списанные часы или переведенные в рубли).
Для того, чтобы максимально утилизировать исполнительские ресурсы важно добиться того, чтобы процент списания трудозатрат был близок к 100%. При этом непосредственно у сотрудников 2-й линии Help Desk следует контролировать, чтобы основное время было списано именно на решение вопросов пользователей.

Стоимость выполненных заявок.

В рамках сервисной поддержки (ИТ аутсорсинг, обслуживание бизнес-центров или оргтехники и т.д.) обычно выделяют 2 типа контрактов:

абонентское обслуживание;
выполнение разовых работ по своей стоимости.

Если в рамках абонентского обслуживания для исполнителей важно контролировать выше обозначенные параметры, то для разовых задач можно разработать мотивацию, схожую с мотивацией специалистов по продажам.
Среди клиентов нашей Help Desk системы достаточное количество компаний используют, функциональность «Прайс-лист», которая позволяет вести каталог работ и услуг и определять их стоимость. В рамках каждой заявки фиксируются позиции из прайс-листа и автоматически вычисляется итоговая стоимость выполнения. Доход каждого инженера, в таком числе, включает % от стоимости выполненных тикетов.

KPI для сотрудников Help Desk — панацея?!

Подводя итог, можно уверенно отметить, что почти любая взвешенная схема показателей и связанная с ней бонусная часть, значительно более объективный инструмент. Это справедливо как для мотивации персонала, так и для повышения эффективности деятельности сотрудников. Однако, важно помнить, что сама по себе практика работы по целям не может гарантировать успехов на пути оказания качественных услуг. Как всегда, ключевыми остаются сами люди и их руководство. При этом не стоит забывать, что значительно проще контролировать ваших подчиненных по разработанным ключевым показателям эффективности с помощью зрелой и удобной Help Desk системы.

Другие полезные статьи по данной теме:

Okdesk — удобная Help Desk система для контроля KPI и SLA. Опыт 5000 компаний!