Пока вы читаете этот пост, где-то в мире плачет один пиарщик. Шутка. Плачет контент-менеджер. Снова шутка. Я неслучайно упомянул статью в сочетании с должностью того, кто в больших-пребольших компаниях отвечает за подготовку текста. К сожалению, всё чаще в KPI начинают входить просмотры контента, лайки в Facebook, шеринг по социальным сетям, количество подписчиков групп и т.д. Да что говорить, если у кого-то в KPI входит количество строк кода, написанных за месяц.
Так вот, это несерьёзно. Метрика должна становиться KPI (ещё раз напомню — ключевым показателем деятельности) только тогда, когда она способна значительно повлиять на бизнес-процесс или бизнес в целом. Например, невыполнение плана продаж или снижение средней стоимости заказа приведёт к недополучению дохода и в относительной перспективе — к финансовым трудностям. А вот количество лайков в Facebook приведёт максимум к испорченному настроению SMM-щика, который долго фотошопил логотип на ухо пятничного котика. Конечно, есть категории бизнеса, для которого эти показатели являются решающими, но эти категории можно перечислить по пальцам одной руки.
При этом все показы, переходы и лайки нужно обязательно измерять — но это просто аналитические количественные показатели. И, если очень надо, для целей KPI их нужно брать в совокупности. Общее правило простое: если не можете соотнести показатель (ретвиты, фолловеры, просмотры и лайки или что-то ещё) с реальным доходом, не превращайте его в KPI. А теперь об истории вопроса и частных правилах.
У каждой болезни есть своя история
Честно признаться, нам в RegionSoft часто встречаются компании, в которых система KPI есть, но что-то идёт не так. Например, заполнение данных превращается в формальность, данные берутся с потолка или, наоборот, в компании возникает тотальный контроль и KPI превращаются в единственный смысл работы каждого сотрудника. Чтобы понять, откуда начинаются проблемы, стоит заглянуть в историю вопроса. При всей серьёзности темы история оказывается достаточно любопытной.
К середине XX века объём промышленного производства и внедрённые технологии требовали нового измерения производительности. Неслучайно, что первые «модели KPI» появились не в научных теоретических изданиях, а стали инициативой бизнеса. Первые метрики производительности в 50-е годы ввёл General Electric, а чуть позже во Франции была разработана Tableau de bord (приборная панель, dashboard, дашборд), которая до сих пор повсеместно используется во французских компаниях. Как раз Tableau de bord впервые упомянула финансовые и нефинансовые показатели, различающиеся для разных уровней управления. И именно в ней показатели впервые были разделены на целевые (видение стратегии) и функциональные (контролируемые, расчётные, увязанные с целями).
Основателем системы KPI принято считать профессора, экономиста и одного из корифеев менеджмента Питера Друкера. Именно ему принадлежат слова «Стратегия без метрик — просто желание. Метрики, которые не соответствуют стратегическим целям, — пустая трата времени». Друкер же предложил набор метрик и показателей, которые могли бы использоваться в бизнесе. Однако почти до конца 90-х система KPI не получала широкого распространения. К концу 90-х — началу 2000-х за рубежом сложились предпосылки для широкого использования KPI.
- Появились подходящие технологии: офисный пакет Microsoft, CRM, системы бизнес-аналитики. Они позволили считать KPI прямо внутри системы, на основе внесённых данных. Всё просто: один раз задаёте логику, и ежемесячно получаете итоги, мониторите, строите отчёты. О том, как мы это сделали в своей RegionSoft CRM — ниже.
- Бизнес стал сложным, появились многокритериальные оценки — эти вызовы требовали новой системы мотивации сотрудников, с учётом нескольких критериев.
- Появились новые типы бизнеса, резко возросла роль коммерческого блока в компании. Продвижение, продажи, аналитика и исследование рынка стали требовать оценки эффективности. Одной производительности труда стало недостаточно.
- Неплохой толчок развитию дали труды Роберта Каплана и Дэвида Нортона. Они разработали сбалансированную систему показателей, которая включает в себя финансовые и нефинансовые факторы. За короткое время система получила распространение более, чем в 50% американских компаний, а затем завоевала и остальной мир. Кстати, до сих пор среди теоретиков менеджмента ведутся споры, отличается ли сбалансированная система показателей от Tableau de bord или является очередной реализацией принципа «кради как художник».
Все показатели внутри бизнеса можно разделить на насколько типов.
- Стратегические показатели — индикаторы, основанные на агрегированных значениях. К ним относятся, например, доля рынка, стоимость компании. Они не подходят для KPI сотрудников, но вполне способны быть ключевыми показателями по кварталу или году для оценки эффективности топ-менеджеров.
- Аналитические — показатели для оценки тенденций. Они сложные, но у них понятная логика; пользователи имеют доступ к данным и возможность делать сравнение за периоды. Это объём продаж, валовая выручка, объём дебиторской задолженности и проч. Чаще всего они и являются KPI.
- Оперативные — контроль в режиме реального времени и упреждение отклонений от нормы. Сюда можно отнести розничные продажи за день или неделю в рамках выполнения месячного плана, ежедневный трафик на сайт, показатели контекстной рекламы, количество звонков и проч. По сути это аналитические показатели, но в коротком периоде, то есть отображение скорости достижения KPI. Мы в RegionSoft CRM реализовали мониторинг таких показателей с помощью прогресс-баров, доступных в основном окне CRM сотрудникам и их руководителю.
Попробуем рассказать, как же выстроить систему KPI так, чтобы она была эффективной, мощной и отвечала реальным целям бизнеса, а не мелким, а иногда и мелочным интересам отдельных сотрудников.
Большое исследование KPI — цифры говорят о многом
В сентябре 2015 года в Малайзии (Куала-Лумпур) прошёл очередной форум по вопросам роста производительности и KPI, в преддверии которого исследователи провели масштабный опрос. На вопросы было предложено ответить 73 000 человек. Результаты получились очень интересными.
Так, систему управления эффективностью в том или ином виде используют 49% на оперативном уровне и 39% на стратегическом. 42% используют сбалансированную систему показателей (та самая, которая родом из США — мы о ней говорили выше). 12% не используют систему управления эффективностью. После введения KPI 68% респондентов отметили позитивное влияние, 15% затруднились оценить, 14% уверены, что никакого влияния KPI на бизнес не оказали и только 3% заметили негативный эффект.
Причины (мотивы) введения KPI были оценены респондентами так:
> 43% — улучшение состояния бизнеса, объективное повышение уровня достижений
> 18% — фокусировка на том, что требует особого внимания
> 17% — прозрачность, детализированная численная оценка желаемого результата
> 13% — ощущение результатов управления компанией посредством формирования ответственности и подотчётности
> 6% — коммуникация, трансляция ключевых сообщений (о состоянии бизнеса) внешним и внутренним заинтересованным лицам
> 3% — обучение, формирование лучшего понимания бизнеса
При развитии системы управления эффективностью бизнес сталкивается с несколькими сложными вещами. Так, ожидаемо самый сложный аспект — выбор тех показателей, которые должны стать ключевыми. 32% опрошенных считают это реальной трудностью. У 28% вызывает проблемы сбор данных, у 19% — установление целевых значений KPI, 14% — анализ показателей, 5% — документирование и всего 3% — визуализация данных KPI.
После того, как результаты собраны и показатели на руках,
> 32% затрудняются, как построить и отладить культуру управления эффективностью
> 22% считают сложным внедрение инициатив по улучшению системы KPI
> 18% испытывают трудности в принятии решений о корректирующих действиях
> 16% ощущают проблемы при анализе полученных данных
> по 6% не понимают, как делать отчёты и как строить обучение на основе результатов
Дальше-больше, при установлении соответствия между планами KPI сотрудников и стратегических целей компании 16% признали полное несоответствие, 23% — полное соответствие и 56% согласились, что планы соответствуют частично.
Что касается автоматизации, то аналитика не обошла и её. 74% профессионалов для сбора данных и расчёта KPI используют таблицы Microsoft Excel, 10% — различные облачные решения, 9% используют десктопные системы, установленные на собственном сервере (к таким относится наша RegionSoft CRM), 7% не знают, что используется в их компании. Кстати, от себя замечу, что проблема как раз в том, что большинство менеджеров и руководителей не ожидают, что в CRM можно рассчитывать показатели эффективности KPI. А между тем, это как раз логично: данные, логика расчёта и итог в одном месте.
Лишь 18% специалистов используют KPI для прогнозирования и моделирования, 33% используют рассчитанные показатели в процессе принятия решений. 55% имеют специальные подразделения, которые занимаются KPI, 45% — не имеют.
KPI: как не надо делать
Чтобы подобраться к проблемам, связанным с KPI, рассмотрим реальный кейс, который болен настолько, насколько вообще можно.
Кстати, если вы знаете, как создать KPI мечты, владеете Pascal Script или просто хотите продавать RegionSoft CRM в своём регионе на основе удалённой работы в компании, пишите и звоните всеми доступными способами на почту contact@regionsoft.ru У нас мощная CRM без багов и с фичами, прикольные условия, хорошая команда, адекватное руководство и активная PR-поддержка продукта. Подробнее — под постом.
В одной довольно крупной российской компании (>400 чел.) ввели так называемые матрицы — сложные многокомпонентные системы KPI, на основании которых сотрудникам формировалась часть ежемесячной заработной платы. Итоговые коэффициенты могли как увеличивать, так и уменьшать сумму выплат. Они рассчитывались группой оценки и мотивации персонала на основе коэффициентов, которые в таблицах-матрицах проставляли руководители (от -3 до +3) и относительных величин (выполнение плана, количество обслуженных клиентов и проч.) Коэффициенты с оценками были абсолютно субъективными: выдающиеся задачи, обычные задачи, проваленные задачи, общая корпоративная лояльность (примерно как оценка за поведение у школьника). Стоит ли говорить, что эти самые матрицы были прекрасным орудием давления, мести, подлости и прочих конторских интриг.
Иллюстрация к приведённой системе KPI — лучше не придумаешь
А всё потому что эти KPI изначально несли в себе несколько ошибок. С них и начнём.
- Система KPI не должна строиться как система наказаний или орудие возмездия. Это должна быть совокупность показателей, отражающих цели бизнеса, динамику развития и вклад каждого сотрудника в достижение намеченного. Если руководство позволяет группе сотрудников (например, начальникам отделов), манипулировать показателями, оно должно быть готово к негативным сценариям, самый нейтральный из которых — недовольство персонала. А самое фатальное — фальсификация, когда KPI подгоняются под нужные значения. Тот же эффект возникает, если руководитель бредит KPI, и сотрудники вынуждены «рисовать», чтобы выжить в компании.
- В KPI не должны входить показатели, не подлежащие измерению. К таковым можно отнести оценку качества обслуживания на основе аттестации старшими менеджерами, удовлетворённость клиентов, лояльность сотрудника компании и проч. Совет тут один — меньше субъективности, больше реальных качественных расчётных значений.
- KPI должны быть такими, чтобы сотрудник мог непосредственно влиять на их достижение и выполнение плана. Это очень распространённая коллизия, когда сотрудник отвечает за то, на что он влиять никак не может. Например, есть коммерческая служба, в ней: продажники, маркетолог, пиарщик, аналитик и программист, который делает выборки и отчёты по заказу аналитика. У всех в KPI стоит выполнение плана продаж. Хотя, на самом деле, аналитик и программист никак не могут повлиять на продажи, они ведут работу на результатах этих самых продаж. Поэтому в их KPI лучше внести изменения. Если вовремя не исправить коллизию, в коллективе назреет недовольство, будут постоянные обвинения друг друга в проблемах с выполнением плана и т.д.
- KPI не стоит превращать в самоцель. Работая на достижение нескольких показателей, сотрудники упускают другие задачи, появляются неприятные перекосы в развитии бизнеса. Проиллюстрирую этот пункт замечательной дискуссией.
Пару лет назад в Linkedin мне попалась краткая и ёмкая статья Бернарда Марра «Осторожно: когда KPI становится ядом». В ней мне понравились две аналогии: 1) KPI перестаёт быть полезным, когда метрики цели превращаются в саму цель. 2) KPI — факелы в большой тёмной комнате. Одним мы можем осветить только ограниченное пространство, в остальных углах — мгла.
Но первый комментарий расставил точки ещё более метко.
Sam Kishaish:
I like the torch analogy. A single KPI will only illuminate a part of the room. If you put all your torches in the same corner, they'll cast long shadows in other corners, but you still wont see much of the room. And, most importantly, if you chase KPIs instead of using them to illuminate, you'll get burned, like moths to the flame. To quote an old movie, «Don't go into the light!»
Перевод: Классная аналогия с факелом. Один KPI будет освещать только часть комнаты. Если вы сложите остальные факелы в тот же угол, они будут отбрасывать длинные тени в другие углы, но вы всё равно не увидите большую часть комнаты. И, самое главное, если вы будете гоняться за KPI, а не использовать их как осветительный прибор, вы сгорите, как мотыльки в пламени. Цитируя старый фильм, «Не идите на свет!»
На самом деле, негатив, который касается KPI, у каждого свой и сильно зависит от форм реализации системы и участия в ней подразделений. Поэтому разберём, что же нужно обязательно учитывать при разработке KPI и работе с системой управления эффективностью.
KPI: как надо делать
Система KPI – это мотивационная система, направленная на повышение эффективности работы сотрудников или подразделений, для которых настроены соответствующие критерии оценки их эффективности. Система KPI совмещает в себе две основные задачи – целевое и финансовое планирование в совокупности с план-фактным анализом. Другими словами, система KPI позволяет оценить степень достижения запланированных результатов. То есть она должна мотивировать, помогать планировать и оценивать.
KPI должна быть метрика, которая имеет возможность непосредственно влиять на доходы и затраты компании, или потенциально создавать предпосылки для значимых событий (например, участие в тендерах). И все эти метрики должны соответствовать ряду правил.
Самый дорогой и самый ценный актив компании — сотрудники. Система KPI должна сочетать в себе следование стратегическим целям компании и мотивацию сотрудников. То есть во главе угла всё равно стоит человек, который работает и своей деятельностью приносит доход, иную выгоду. Он должен понимать, в каких точках он влияет на бизнес-процесс и как он должен выстраивать свою работу, чтобы приносить больше пользы и получать больший доход. KPI — ориентир, который помогает сотруднику встроить себя в процесс. Панель KPI должна быть гибкой, настраиваемой, потому что как раз этот процесс нельзя унифицировать. Не раз на Хабре писали о пользе и вреде KPI, особенно в компаниях-разработчиках. Очевидно, что у программистов, продажников и работников финансовой службы KPI должны быть разные и релевантные именно результату сотрудника (а не мнимому исчислимому показателю типа количества строк кода). Соответственно, важно внимательно поработать над системой показателей, выделить действительно значимые и настроить веса. KPI следует рассматривать не просто как оценку, а как показатель в динамике — только тогда система окажется работающей, сможет служить для планирования и прогнозирования. Нужно тщательно продумать механизм подсчёта KPI. Так, например, можно выбрать кумулятивный показатель с весами коэффициентов (сумма долей вклада каждого показателя, умноженных на показатель), можно мультипликативный KPI, когда показатели перемножаются.Тут лучше посмотреть на конкретном примере. Допустим, у сотрудников три KPI: объём продаж и дебиторка. Менеджер А продал на 250 000, закрыл дебиторку на 60 000. Менеджер Б — 200 000 и 25 000.
Итак, если у нас есть правила: объём продаж до 100 000 — 0, от 100 000 до 200 000 — 0,5, от 200 000 до 300 000 — 0,7, свыше 300 000 — 1, дебиторка до 10 000 — 0, до 20 000 — 0,5, до 60 000 — 0,7, от 60 001 — 1. KPI исходит от оклада — 30 000 рублей.
При мультипликативной модели, общая выплата:
Менеджер А: 30 000 + 30 000 * (0,7*0,7) = 30 000 + 14 700 = 44 700
Менеджер Б: 30 000 + 30 000 * (0,7*0,5) = 30 000 + 10 500 = 40 500
При кумулятивной, общая выплата:
Менеджер А: 30 000 * (0,7+0,7) = 42 000
Менеджер Б: 30 000 * (0,7+0,5) = 36 000
Если смотреть по достижениям менеджеров субъективно, то первый кажется эффективнее второго, а кумулятивная модель подчёркивает разницу в эффективности более ощутимо, чем мультипликативная. Веса нужно присваивать также с осторожностью. Бывает, что не самый важный показатель при небольшом весе даёт коэффициент 0,1 или 0,2, а это в мультипликативной модели резко снижает объём премии. Вариантов начисления существует множество — ниже мы расскажем, какую модель можно построить в RegionSoft CRM и там самым автоматизировать ежемесячный подсчёт KPI.
KPI в своей совокупности должны отображать прогресс команды и бизнеса относительно поставленных целей, а значит, всегда должен быть план. Метрики показывают причастность каждого из команды к достижению цели, а значит, что они должны быть понятны сотрудникам. Лучше всего задокументировать систему KPI и ознакомить сотрудников, разъяснить спорные моменты. KPI — это ключевые показатели, то есть отображающие те процессы, которые оказывают влияние на развитие бизнеса. Выберите 2-3 показателя. Сфокусируйтесь на главном и на том, что действительно важно для бизнеса. Как показывает опыт, соблазн измерять и оценивать всё в рамках KPI преследует руководителей — не поддавайтесь, вы потом сами же в показателях утонете. Измерять нужно всё, но в ключевые показатели следует выносить только самое важное. Если произошли структурные или продуктовые изменения, меняйте KPI. Система показателей должна отображать только актуальные цели. Для крупных компаний или компаний, чувствительных к внешней экономической конъюнктуре, следует также учитывать системные изменения. Например, во время экономического кризиса наблюдается спад спроса у туристических компаний и становится невозможно выполнять докризисные KPI. Естественно, нужно рассчитать новые целевые значения. Обсуждайте систему KPI с командой, отслеживайте лучшие практики. Вы уже видели в приведённой статистике, что чуть больше, чем в половине компаний, темой KPI занимается обособленное подразделение. Это правильная практика, однако стоит включать в рабочую группу руководителей всех подразделений, поскольку именно они понимают всю специфику работы своего направления. Не разваливайте бизнес конкуренцией показателей. Не секрет, что в небольших и средних компаниях есть сотрудники, которые выполняют сразу несколько функций — в таком случае необходимо учитывать приоритетные направления их работы. Например, отдел занимается партнёрскими, агентскими и прямыми продажами. При этом прямые продажи «стоят» в KPI дороже, чем партнёрские. Рано или поздно это приведёт к сокращению последних, а это потеря важного канала продаж. Точно так же установление KPI по количеству закрытых баг-кейсов может привести к снижению скорости работы над основной функциональностью программы.
Моя мечта — однажды я найду все правильные KPI
Как мы KPI в RegionSoft CRM реализовали
В RegionSoft CRM параметры KPI могут быть настроены индивидуально для каждого сотрудника, группы, отдела или компании в целом, в зависимости от обязанностей и целей, которые должны быть достигнуты. Например, для секретаря актуально целевое планирование, не зависящее от объёма принесенных денег (количество отправленных факсов, принятых звонков и т.д.). В то время как для менеджера по продажам актуально именно финансовое планирование: сумма выставленных счетов, количество сделок, отгрузок товара и т.д. Дополнительная возможность системы KPI – расчет вознаграждения сотрудников, основанный на системе оценки достижения целей через ключевые показатели эффективности.
Система KPI состоит из нескольких модулей, каждый из которых тонко настраивается.
Ключевые показатели. В качестве базы для расчёта показателей могут браться инциденты (количество), документы (суммы по ним и количество), любые количественные сведения, которые собираются с помощью встроенного скрипта на PascalScript (это пользовательские показатели; как создать скрипт, подробно изложено в нашей wiki-справке по системе KPI).
Очевидно, что каждый документ, сделка и любой инцидент имеют для бизнеса разновеликую ценность, и в системе KPI это необходимо учитывать. Для этого в RegionSoft CRM предусмотрена возможность проставлять весовые коэффициенты, повышающие или понижающие ценность показателя. В процессе работы количество достигнутых целей накапливается, система группирует цели и применяет коэффициенты, определяя общую ценность действий сотрудника. Расчет итогового значения происходит по следующей формуле:
?(Ci?Ki)
где:
C – количество целевых инцидентов. Следует отметить, что по каждой цели поиск событий производится отдельно и не влияет на результаты по другим целям;
K – коэффициент для цели (коэффициент может отсутствовать, тогда учитывается количество инцидентов, то есть K = 1).
Показатель по документам также заводится в системе, но рассчитывается просто как результирующая сумма (количество документов, сумма денег по ним). При этом в процессе заведения коэффициента в CRM, можно уточнить условие выборки (например, учитывать только проведённые накладные).
Пользовательские скрипты позволяют создавать сценарии, реализующие произвольную логику расчёта результирующего значения. Также можно создавать дочерние показатели, основанные на первоначальном расчёте. Скрипты создавать достаточно просто, по ним существует подробная инструкция — достаточно базовых знаний программирования.
Планы и профили. Профили планирования настраиваются в RegionSoft CRM и помогают проводить последующий план-фактный анализ и отображать выполнение показателей на основании собранных в CRM данных. Механизм профилей устроен так, что на основании одного показателя может быть настроено несколько профилей и наоборот – один профиль может содержать любой набор показателей. План может задаваться на: день, неделю, месяц, квартал, год.
В зависимости от настроенных прав доступа (а в RegionSoft CRM они настраиваются как в целом, так и по отдельным модулям и даже клиентам), можно видеть прогресс-бары выполнения показателей сотрудниками. Так, например, сам сотрудник видит только свои личные показатели, а начальник отдела — показатели всех своих менеджеров и отдела в целом.
Показатели могут быть индивидуальными или групповыми, т.е. можно осуществлять контроль как за показателями конкретного сотрудника, так и за показателями отдела или всей компанией в совокупности.
Шаблоны правил премирования и расчёт зарплаты. С помощью системы KPI можно организовать расчет вознаграждения сотрудников, который будет основан на результатах выполнения нормативов в разрезе ключевых показателей. Для организации расчета необходимо определить набор правил вознаграждения, а затем применить эти правила к сотрудникам. Принципы монетизации настраиваются в RegionSoft CRM как шаблоны правил в удобном графическом интерфейсе: задаются наименование, описание, показатель, значение показателя, премия или выражение для расчёта премии.
Вознаграждения настраиваются для каждого пользователя индивидуально. В интерфейсе настройки вознаграждения пользователя необходимо указать размер оклада и выбрать список шаблонов для расчета премии. Один и тот же шаблон премирования в настройке пользователя можно указать только один раз.
Расчет вознаграждения пользователя выполняется с помощью следующего выражения:
S+?BiS+?Bi
где: S — размер оклада пользователя;
B — размер премии, рассчитанный при помощи шаблона.
При необходимости дополнительной корректировки размера вознаграждения можно использовать программный сценарий, позволяющий реализовать сколь угодно сложную логику. Скрипт выполняется после того, как будут рассчитаны значения всех показателей и шаблонов. Значения всех показателей и шаблонов доступны в теле скрипта и могут быть получены и изменены через их переменные.
Мы знаем обо всех проблемах, связанных с настройкой и расчётом системы KPI, именно поэтому в RegionSoft CRM встроен «Мастер настройки KPI», который проводит пользователя по шагам и помогает настроить систему ключевых показателей. В дальнейшем можно пересмотреть систему, внести изменения или даже написать вручную скрипты, которые учтут самые тонкие пожелания по составу KPI.
Система показателей KPI должна быть такой, чтобы их выполнение было легко поручить, а сотрудникам — легко прочитать формулы и компоненты и понять их. Визуализация и интерактивность дают соревновательный эффект, прозрачность делает систему справедливой, а сами KPI помогают управлять бизнесом по целям. А значит, владельцам получать желаемую прибыль, а сотрудникам — заслуженное вознаграждение.
Нам нужны серьёзные, надёжные ребята в регионах России и странах СНГ, которые готовы работать с нами удалённо:
- продавать CRM клиентам из своего региона;
- дорабатывать CRM под чутким руководством, продавать CRM с доработкой и получать ещё больше;
- продавать CRM и обучать пользователей.
Как правило, продажа не требует поднимать из рабочего кресла тяжёлые и не очень части тела — нужно проводить онлайн-презентации и телефонные переговоры. Если вы готовы сколотить команду мечты из продажника и разработчика, мы рассмотрим даже эти безумные пары.
От нас:
- обучение (покажем систему, расскажем, как продавать, где подводные камни и шишки)
- гайды и советы (вы можете предлагать свои, мы не диктуем и не жмём)
- постоянный контакт и поддержка (моральная тоже)
- перспектива роста в филиал (при нашей поддержке)
- централизованная PR-поддержка (вам не нужно будет об этом думать).
От вас: желание, честность, профессионализм, доступность (всегда на связи) и прозрачность отношений. Мы любим всех, кроме нечестных, непунктуальных и безответственных людей.
Пишите, звоните, всё обсуждаемо. RegionSoft Developer Studio
Комментарии (51)
Manitou
30.08.2016 12:13+3> Допустим, у сотрудников три KPI: объём продаж и дебиторка.
И, видимо, третий, который и определяет итоговый размер вознаграждения, как обычно. За статью спасибо, хотя о «пользе» KPI на этом ресурсе уже дискутировали не раз (например, здесь). Тем не менее, когда читаю подобные статьи, задаюсь вопросом, раз уж компания выбрала KPI в качестве системы оценки эффективности и оперативной оценки, по какому-то недоразумению, то зачем увязывать линейно значение KPI с размером материального вознаграждения. Тем более, что в большинстве случаев в качестве системы мотивации KPI не годится, совсем.
ncix
30.08.2016 12:28+16Из личной практики:
— Руководству надоело выписывать премии разработчикам от балды, давайте сделаем систему мотивации на базе KPI
— По количеству строчек кода? (Гыгыы)
— Вот вы и займетесь подобором показателей
(прошло 2 месяца)
— Итак у нас есть показатели: количество решенных задач из таска, количество часов на проекте в периоде, количество критичных багов в релизах. Для РП количество релизов. Для тестировщиков — кол-во проверенных и пропущенных багов. Для каждого продукта свой коэффициент…
— А вот формула, линейная с коэффициентами
… день расчета зарплаты:
— По вашей формуле Вася получает премию в 4 раза больше фиксированной зарплаты!!! Что за хрень! А Серега, который пилит второй месяц важнейший для нас проект не получает нифига, потому что его задача на 3 месяца!
— нда… Так, в этот раз платим по-старинке. Формулу доработать! Пусть будет нелинейной
… прошло два месяца
— Вот новая формула.
— Арккосинус???? Квадраты?
— Нужно было сделать нелинейность, чтобы предельные значения гладко приближались к заданным пределам…
— Вот вы и будете объяснять систему мотивации сотрудникам
… прошло два месяца
— Это слишком большая задача, её нужно разбить минимум на три, а лучше на восемь
— А на эту уйдет не час, а четыре. Да, может подтвердить любой наш сотрудник
— А куда записать время, которое я потратил на оценку задач и заполение новых полей в отчете?
— Эт чо! Это не я баг пропустил а разработчик не написал что проверить! Все в переписке есть!
— Че я зря в выходные выходил, почему я получил как все?
… прошло два месяца
— Вот! Наши KPI по 90% сотрудников выполнены на 140 и более процентов! Как насчет доп. премии руководителю отдела?
— Вы охренели? Продукты как были в бете так и остались! Клиенты уже второй год ждут доработок!
— После того как половина народу ушла, очень сложно соблюдать предыдущие договоренности. Но мы ищем! Кризис же, персонала на рынке много. Правда после испытательного срока почему-то многие сами отказываются…
RegionSoft
30.08.2016 15:50+2Отличная история, от души в душу просто. Можно делать отдельный пост, как оно происходило по порядку :-) Да, на самом деле вопрос KPI разработчикам — очень тяжёлый, особенно, если дело касается нестандартных, сложных, ресурсоёмких проектов.
alibertino
30.08.2016 23:15Красноречивая история о попытке подменить реальные метрики для KPI — «какими есть». А так-то должно быть очевидно, что если задачи не типовые, то одну формулу вывести не удастся. А разработка формулы под каждую задачу должна быть обоснована финансово, чаще всего человеческое управление и оценка работы будет дешевле.
igor_suhorukov
02.09.2016 23:30По мне, так как не крутись с KPI для разработки ПО — выйдет ерунда! Только демотивация и тема для зависти и склок.
В такой ситуации проще привязать премии к общим достижениям организации и если система работает и приносит деньги, то платить типа 13 зарплаты всем (пропорционально окладу).
chieftain_yu
05.09.2016 09:01Минус — если есть некто, кто забивает и не помогает, он будет получать ту же премию, хоть и не способствовал успеху — поскольку организация в целом — задачи выполнила.
igor_suhorukov
05.09.2016 10:48Это вопрос зрелости и отношений внутри коллектива. Здоровая команда сразу отторгнет того кто забивает, лучше любых менеджеров и KPI.
А если процветает бюрократия и корпоративные войны которые держат таких людей, тогда вообще как возможен успех и какая система мотивации может работать для здравомыслящих и успешно работающих сотрудников!?)
SeregaSA73
30.08.2016 12:29+7КПИай это просто хренотень которая мешает повседневной работе, сидим и придумываем себе задачи и героически их выполняем.
GreenTiguan
30.08.2016 12:36+1смотря как настроить KPI. Если цели будут выстроены правильно и мотивация продумана, показатели KPI могут быть весьма эффективными.
SeregaSA73
30.08.2016 12:41+3Вот именно если настроить и цели поставить правильно! но в большинстве случаев это показушничество для руководства и отвлечение сил сотрудников от основной работы, в общем у нас на работе это так, да еще и целый отдел сидит зп получает. Сейчас надо на след год придумать себе КПИай, сидим и голову ломаем.
RegionSoft
30.08.2016 15:52+3Увы, это очень распространённая практика, когда сотрудник вынужден подгонять задачи под KPI и ещё какую-нибудь еженедельную отчётность. Если такое происходит, руководитель обязан инициировать пересмотр системы мотивации. Да, я знаю, это утопия…
fishca
30.08.2016 13:03+6Система KPI не должна строиться как система наказаний или орудие возмездия
замечательные слова!
abstractbug
30.08.2016 13:20+3Жаль в связном их не услышали пару лет назад, ввели одну систему, и каждые два месяца вводили новую, пока в итоге не отказались, и не расформировали вообще региональный отдел техподдержки в Ростове-на-Дону (вроде осенью последних сокращают, меня сократили.)
Они ввели систему штрафов, а штрафы делились между теми сотрудниками кто работал выше нормы. правда нет штрафов — нет премий. как бы ты хорошо не работал, хоть за десятерых. А кпи показатели вообще веселые были)) главное что при разработке, никто не спрашивал у сотрудников как это и вообще возможно ли это) В итоге стек очереди до неприличия вырос, и в место пользы — вышло как всегда. Впрочем думаю связной не единственная контора, которая все реализовывает через одно место.RegionSoft
30.08.2016 15:57+2В сотовой связи и сотовом ритейле KPI — отдельная песня, особенно в технической поддержке и справочной службе. Особенно опасно требовать огромного количества обработанных заявок — так можно получить ну очень плохо обработанные заявки и кучу рекламаций, жалоб и скандал.
Так, в одной компании (не сотовики, но ИТ) требовали обслуживать 80 писем в день на иностранном языке. Даже если без обеда, туалета и покурить — это 6 минут на письмо! На неродном языке. В итоге через какое-то время пошли жалобы — выяснилось, что сотрудники отвечали однообразно, из разряда «очень важно для нас». Вот так рвачка за KPI подмочила репутацию компании — негативный фидбэк традиционно пополз по форумам, обзорам, соцсетям и комментариям…
AVX
30.08.2016 13:50+3В любой системе, при любом способе оценки производительности и достижений (включая, когда используют KPI) в первую очередь нужно выдержать простое правило: «правила игры» не должны меняться на ходу. На своей работе мы все ощутили все прелести подхода, когда меняются на ходу и показатели эффективности, и коэффициенты, и приоритеты показателей. Например, когда вначале говорят «учитываем количество отработанных обращений в месяц на сотрудника», и по этому показателю распределяют премию; потом говорят «нет, давайте так — кроме того нужно чтобы из них было как можно меньше инцидентов, а больше запросов»; потом учитывают трудозатраты суммарно по всем обращениям, потом — повторы инцидентов по каждому рабочему месту в неделю-месяц-(год?), потом ещё больше показателей, кроме того весьма сложно формируемых, на которые при этом сами сотрудники не могут повлиять. Я ещё понимаю, когда месяц-другой где-то в пилотном проекте, на ограниченной группе сотрудников это обкатали, и далее «правила» не менялись бы по велению левого мизинца, но когда метрики меняются порой несколько раз в месяц, а все узнают об этом уже через месяц, и часть метрик вовсе настолько мутные, что часть руководителей не понимает что к чему — вот это АД.
RegionSoft
30.08.2016 16:02+3Кстати, вы затронули интереснейшую тему — понимание KPI руководителями. Коэффициенты должны быть понятны, прозрачны и документированы для всех. Если руководитель не может понять, что влияет на оценку, он не может наладить работу подчинённых, поскольку ему не ясны цели бизнеса.
Менять что-либо на лету в таком случае — вообще неразумно и неэтично. Думаю, в этой ситуации вполне применим правовой принцип: pacta sunt servanda, договоры должны соблюдаться.ncix
30.08.2016 16:07+2Не только руководители, но и рядовые сотрудники должны понимать из чего складывается их доход. Иначе это вечный повод для недовольства.
ncix
30.08.2016 16:11+1Давным-давно предлагал руководству платить разработчикам процент с продаж продукта. Более опытные руководители мне тогда сказали, что это работать не будет, т.к. «разработчик не может повлиять на продажи».
Но мысль осталась. Не было ли у кого в практике примеров (отрицательных/положительных) такого подхода?
Analitik_Telecom
30.08.2016 16:29+2У меня был. Софтверная компания, продажи по большой географической зоне. Программистам решили платить % с продаж (не KPI, а именно долю). Так вот, программисты были хорошие, а продажники сменились и стали не очень. И кризис ещё грянул по основным регионам. Продажи упали, но процент всё равно был. Закончилось всё очень сильным корпоративным раздраем и криками об очень плохих продажниках. Когда атмосфера перекалилась, разработчикам просто установили стабильное премирование и надбавку.
stardust_kid
30.08.2016 16:31+2Общепринято опционы предлагать, что в принципе похоже на то, что вы хотите. Главное для меня — разработчика, чтобы этот процент был «сверху» зарплаты, а не «внутри» нее.
ncix
30.08.2016 16:38Опцион это право в будущем выкупить долю в компании по фиксированной (обычно заниженной) цене. Нормально это можно сделать только в АО. Да и то разработчики сильно удивятся, когда окажется что компания почти не генерит чистую прибыль, либо она не распределяется среди владельцев а идет на реинвестирование. А так живут наверное 95% софтверных компаний :).
stardust_kid
30.08.2016 16:52Можно свой велосипед придумать. Опцион на получение годовой прибыли, или типа того.
may-cat
30.08.2016 16:55Насколько я знаю, нечто подобное у booking.com — эффективность функционала измеряется в его влиянии на кол-во заказов в минуту
ncix
30.08.2016 17:05С любым подходом от «общего результата» непонятно как быть с тестировщиками или вспомогательными разработчиками которые пишут автотесты, или поддерживают CI. Их труд может дать результаты через продолжительное время.
may-cat
30.08.2016 17:22KPI — на команду. Команде отдаётся какой-то сервис. А дальше — как хочешь крутись, команда.
ncix
30.08.2016 17:38В реальных компаниях есть подразделения, которые работают на много проектов. Либо отдельные люди шарятся между проектами. И вообще матричную структуру пока никто не отменял.
chieftain_yu
31.08.2016 11:21+2Что видится навскидку — несколько вариантов:
1) Разработчики получают процент от продажной цены.
1а) Получают индивидуальные проценты, от других членов команды не зависящие (условно — Васе, Пете и Мише — по 0,5% продажной цены). Получаются драки разрабов на вхождение в дорогие проекты, при этом дешевые проекты будут наказаниями. Склоки внутри разрабов (слабые).
1б) Процент на команду. Тут начинается разборка внутри уже команды проекта с последующим ухудшением отношений между разрабами (если эта дележка идет демократично) или с ЛПР (если единолично).
В обоих вариантах разработчики а) не влияют на продажную цену, б) не интересуются, прибылен ли проект и в срок ли он сдан (а смысл интересоваться? Процент по любому будет). Продавец мог задешевить проект с целью подсадить заказчика или еще какой, что также не зависит от разрабов.
2) Разработчики получают процент от прибыли. Аналогичная ветка по дележке.
Несколько лучше — разрабам интересно уложиться в бюджет. Но есть и негативная сторона — если продавец изначально «упал» по деньгам (то есть занизил цену) — то уложиться в бюджет может просто не получиться — со всем отсюда плавно вытекающим.
В чистом виде не взлетит в обоих вариантах, на мой взгляд.
Должна быть некая комплексная система, учитывающая и прибыльность проекта, и выдерживание сроков, и удовлетворенность заказчика (вот тут может быть процент от повторной продажи тому же заказчику!), и трудоемкость.
И в любом случае между продавцами и разрабами отношения будут натянутыми — одни «хреново продают», другие «хреново работают».
В любом случае процессы внутри компании — и KPI тех же продавцов — должны быть выстроены так, чтобы не допускать перекосов типа «я продал, теперь ваша очередь выкручиваться».ncix
31.08.2016 11:31Есть один хороший способ избежать массы проблем — ввести на всех уровнях компании табу на обсуждения своих и чужих зарплат. Не запретить приказом а ввести мягко это в корпоративную культуру. Сколько ты денег получаешь — знаешь только ты, твой руководитель да бухгалтерия. Ну возможно еще какие-то вышестоящие руководители, но не одноуровневые с тобой сотрудники.
Выглядит довольно утопично, но я сам много лет работал в такой компании. Правда, такая практика сложилась с самого основания компании, не уверен, что её можно привнести в уже существующую.chieftain_yu
31.08.2016 11:49Сами зарплаты или совокупные доходы при этом обсуждать и не требуется.
В компании или есть некое положение, фиксирующее логику расчета KPI разраба (и тогда плюс-минус все разрабы знают логику и понимают, как формируется их конкретная денежка — но ровно так же понимают и логику формирования премии соседей), или его нет — но тогда цели введения KPI непонятны — для разраба тогда его премия будет манной небесной (в том плане, что зависимость от его действий будет крайне туманной, а значит — премия будет непонятно что стимулирующей).
Если я догадываюсь, что участие в проекте А даст мне вдвое больше премиальных денег, чем участие в проекте Б при равных усилиях и одинаковых сроках ожидаемой выплаты премии, я начну пытаться попасть в него, конкурируя с Васей Пупкиным. И плевать мне на его зарплату.
Плюс вся эта логика (что у кого типа стимулируется, если реально введены KPI) после некоторого варения в коллективе становится более-менее видна. Если продавец входит в УКП, но при этом всячески отмазывается от решения проблем проекта уровня УКП — значит, за успешность выполнения проекта он не премируется. Ну или премируется неадекватно мало, что он предпочитает забивать на это направление деятельности.ncix
31.08.2016 11:57Основная причина денежного недовольства — банальная зависть и убеждения в том что я сам не хуже кого-то другого и должен поэтому получать не меньше. Исключив информацию о чужом кошельке мы по крайней мере зависть уберем.
>>В компании или есть некое положение, фиксирующее логику расчета KPI разраба
Очень просто — там есть некий параметр «мой базаовый доход» — который кроме вас никто не знает. И на него уже вешаются проценты, бонусы и штрафы. В итоге вы на «плохом» проекте можете получать больше Васи на «хорошем». И вам это известно. Точнее, не известно точно сколько :)
Если я догадываюсь, что участие в проекте А даст мне вдвое больше премиальных денег, чем участие в проекте Б при равных усилиях и одинаковых сроках ожидаемой выплаты премии, я начну пытаться попасть в него, конкурируя с Васей Пупкиным. И плевать мне на его зарплату.
Это можно считать положительным эффектом. Можно проводить внутренние конкурсы в новые команды, отбирать лучших. Будет стимул развиваться чтобы перейти в более прибыльный проект. Вам придется доказать что вы лучше подходите в проект чем Вася. Мне кажется это здоровая конкуренция.
chieftain_yu
31.08.2016 12:06Так я-то собираюсь не сравнивать, у кого толще пачка купюр — у меня или у Васи. А максимизировать свой доход при минимизации усилий! :)
А по поводу конкуренции — если это предусмотрено логикой процессов в компании — да не вопрос.
А вот если нет — тут могут быть серьезные засады.
Звезда поиграла в одном проекте, потом его покинула и зазвездилась в другом. А первый при этом начинает тонуть…
Если же перехода между проектами нет — то могут быть эффекты неравномерной загрузки сотрудников, что тоже не айс.
Или — приходит к нам новый заказчик, крайне перспективный, которого потом годами можно ублажать.
И чтобы прорваться через тендер мы выставили «инвестиционную» цену — чтобы выиграть и подсадить на свой продукт. Проект планово убыточный. Но ориентирован на завоевание заказчика (значит, надо сделать хорошо).
Но при этом логика расчета KPI может привести к тому, что звезды как раз на проект не попадут, а попадут штрафники, проект уедет по срокам и качеству, заказчик обидится…
Систему надо смотреть, систему целиком, а не отдельно взятый аспект. :)ncix
31.08.2016 12:15Безусловно, «багов» в любой такой системе будет достаточно, но на то и нужны руководители чтобы директивно в ручном режиме разруливать проблемы, а потом отвечать, если что-то пошло не так. За это им и платят неплохо :)
chieftain_yu
31.08.2016 12:56Это в теории. :)
В ряде мест начальники нужны для того чтобы проблемы — прятать.
PavelMSTU
30.08.2016 17:19+4Как только вводятся KPI для разработчиков, то ушлые программисты перестают работать и начинают играть.
Спустя N месяцев (где N от 2 до 24) 80% разрабов переходят в множество ушлых, а 20% меняют место работы.mcgreedy
31.08.2016 12:40+1В этом и состоит весь секрет.
Если в процессе «игры» разработчик будет выполнять требуемые задачи в установленные сроки — то задача решена верно. Если нет — то это косяк менеджмента.
KPI, как сказано в статье не должен быть механизмом кары, он должен быть фокусом на важных задачах.
Опять же полное отсутствие контроля, может привести к отсутствию работы.
ncix
30.08.2016 17:56+3На самом деле существует всего два способа мотивации: морковка спереди и морковка сзади. Все остальное — детали реализации.
Mistique666
31.08.2016 12:58+2За админство скажу и саппорт.
KPI на количество заявок — провален — быстро вступят в сговор с сотрудниками и всегда все будет отлично на бумаге)
KPI на выполнение заявок в рамках SLA — чуть более корректен, потому что SLA хоть как то инциденты учитывает по сложности.
KPI на простой, где 0 часов простоя это 100% — плохо. У вас будет запланированый простой на тех обслуживание, либо случится таки авария, которую вы решите за 4 часа не прогнув бизнес, но вам попытаются этим попенять и вы прилетите на деньги.
ЗЫ
у нас отношение в стране даже k KPI типично российское. Яркий пример ГИБДД. вы ДОЛЖНЫ за смену поймать столько то пьяных! а есали их нет?! Ну вот что делать?
У буржуев другой подход: есть аварийность на ввереном участке. Как хочешь регулируй, но смертность, аварийность должны быть в KPI. И вот тут кто как умеет) Хотите — будьте самыми злыми в городе. А может просто достаточно стоять с мигалками НА дороге, а не в кустах?)
satas
ИМХО, к разработке неприменима система KPI. Продажи, маркетинг — да, но только не разработка.
RegionSoft
На самом деле, чаще всего KPI используются как раз для коммерческой службы и в частности для продаж — это верный и надёжный способ оценить работника. В тестировании и администрировании тоже распространено, поскольку количественные измерения более чёткие: баги, инциденты и их статусы.
В разработке если и вводить, то с огромной осторожностью, мотивированно и уж точно не по количеству строк кода.
DMGarikk
ога… в администрировании самое оно
Мало заявок у администратора — плохо работает — надо уволить… зашибись
Konachan700
Я так работал. ServiceDesk первой и второй линии. KPI на количество инцидентов и запросов на изменение\добавление в сутки, в неделю, в месяц, да. Приходилось просто выдумывать запросы от случайных сотрудников и набивать в багтрекер, а потом закрывать как выполненные. ИБД в чистом виде, эталон просто.
Плохо, когда бездумно тащат вещи из одной отрасли в другую. В продажах KPI полезны и нужны, но когда их внедряют где попало и абы как, работа превращается в цирк с конями: «пофиг на работу, надо нагонять показатели, а то премию не дадут».
RegionSoft
Совершенно безобразная история! В таком случае нужно не создавать KPI в вакууме, а делать поправку на интенсивность потока обращений. Кстати, в продажах та же боль: бывает, что план не меняется и не учитывается фактор сезонности, а это гарантированно провальный коэффициент.
igor_suhorukov
В моей практики было что ServiceDesk закрывал массово неразрешенные запросы с проблемами сети и Oracle DB — потому что это подрядная организация и похоже получает деньги за количество закрытых тикетов. Чтобы решить проблему самостоятельно у меня не было доступа и привелегий, а «прослойка» закрывала тикеты с прикрепленными скриншотами и логами в статусе «Can't reproduce». Вот вам и KPI!
paranoya_prod
Админа надо контролировать не количеством заявок, а простоями бизнес-процессов (потерей денег), в которые входят люди и ПО. Чем больше простоев, тем хуже админу. То есть, если доступность падает меньше заданных процентов, то зарплата админа стремительно уменьшается. С премированием немного сложней и зависит от статуса админа в компании.
mcgreedy
Тут скорее нужен другой коэффициент — время безаварийной работы — время когда нет заявок с грифом системная ошибка.
И скорость устранения для заявок с меткой — операционная.
Boberto
Я в суппорте работаю. С банковским софтом. Меня возюкали носом по KPI и говорили, что мало активности с моей стороны, вон, Вася в семь раз больше мейлов в день отправляет. Только не учли, что Вася, Женя и Петя разбирают запросы вроде «пришлите доки» и «прочитайте нам эту доку вслух» а мне передают все «репорт не генерится каждую 53ю неделю года, если снег уже растаял» и всякий упоротый неадекват, потому, что я опытный гуру. предложил инвертировать запросы между мной и остальными — ребята уговорили начальство оставить как есть. Только премии то по KPI.
Вобщем всё это для тех, кто с конвеера яблоки по коробкам сортирует.
Analitik_Telecom
Или для тех, чьё руководство башкой думать не хочет…
AVX
«Вобщем всё это для тех, кто с конвеера яблоки по коробкам сортирует.» — можно я эту фразу запомню, запишу, и высеку на камне? Ну и потом использовать каждый день, конечно :)
Это касается не только KPI, но и в большей части т.н. «процессного подхода» (без которого, кстати, не пройти сертификацию по ИСО 9001, или какой там номер...)
Кто-то подсмотрел идеологию с зарубежных заводов (конвейер же!) и решил применять везде без разбора. Ну и понеслось…
Кто-то сказал, и мне понравилось: эмбиэй головного мозга.
chieftain_yu
Для этого Вас следовало вывести во вторую или даже третью линию поддержки и оценивать по другим параметрам, а не смешивать все линии в кучу.
С моей точки зрения — ошибка выстраивания службы поддержки.
Boberto
Ошибка выстраивания службы поддержки? Да Вы даже не представляете!!!
Было три отдела, разрабы человек 50, внедрение где-то 40 и поддержка наверное 30. Внедрение — процесс сложный, тягомотный, сертификации и всё такое, люди со специфичным складом ума и образом жизни — проводить по два месяца за раз во всяких Киргизстанах… Сам прдукт непростой (навскидку 1200 модулей и невероятные пазлы совместимости по версиям). Руководство решило, что у поддержки и внедрения похожие задачи и можно оптимизировать(в реале не пересекается — как пример: установить линух снуля или возродить завирсённую винду). Там родилась идея, что если два отдела объединить и обозвать новым термином, то произойдёт мгновенный обмен знаниями и из 30 суппортёров + 40 внедренцев получится 70 суппортёров И(да, именно _И_) 70 внедренцев. По крайней мере перформанс от нас именно такой ожидается. Серьёзная международная корпорация, софт для фин-структур пишем.
cbone
У нас внедрение на уровне простоя сервисов. есть ответственный за сервис, к примеру электронная почта. есть система мониторинга, которая следит за работоспособностью этого сервиса. от аптайма зависит зарплата ответственного. и так по каждому сервису, в зависимости от критичности для бизнеса.
по саппорту пользователей — обработку каждого тикета должен оценить пользователь. и не важно, что заявок мало, главное их качество выполнения.