Есть такая полезная задача — разработка систем мотивации. Я долго наблюдал за несчастными HR, которые создавали системы KPI, материальную и нематериальную мотивацию, силились поднять корпоративный дух. Мои наблюдения всегда показывали одно и то же — HR в этой работе чего-то не хватает. Вроде слова правильные говорят, и философия под их расчетами правильная лежит, но созданные ими системы мотивации не выдерживают никакой критики.
Почему-то всегда результатом становятся не связанные друг с другом показатели, большинство из которых не измеряются. Следом запускается проект по автоматизации расчета этих показателей, а к моменту его завершения показатели устаревают, потому что бизнес понимает, что хочет от людей совсем не того, к чему ведут эти показатели.
А если вспомнить о том, что бизнес далеко не всегда может нормально выразить словами, чего хочет от конкретной должности, то становится совсем грустно. И ладно, если именно выразить не может — иногда ведь и не понимает. Точнее, не понимает конкретный представитель этого бизнеса, заказывающий систему мотивации.
Итогом почти всегда является «какая-нибудь» система мотивации, которая хоть что-то считает и дает хоть какое-то представление об эффективности работы людей. Но главная беда — система мотивации не приносит пользы бизнесу, потому что оценивает людей по критериям, ему не выгодным.
Людям такая система мотивации тоже не приносит пользы, т.к. не дает возможности заработать больше денег, принося пользу бизнесу.
В итоге я пришел к выводу, что разработка систем мотивации — больше инженерная задача, чем гуманитарная (да простят меня милые и добрые HR). Как ни крути, система мотивации — это система показателей. Показатели — это измерение, управление границами, согласованность целей и возможностей, четкая взаимосвязь с бизнес-процессом, правильная автоматизация. Все перечисленное — инженерные задачи.
Кто в современном российском бизнесе тот человек, который по сумме компетенций — лучший в перечисленных областях? Программист, кто же еще.
За свою бытность программистом и кем-то типа ИТ-директора я руководил или участвовал в разработке десятка систем мотивации — для программистов, кладовщиков, конструкторов, снабженцев, руководителей. В разработке систем мотивации я участвовал на разных уровнях. Сначала — автоматизировал расчет показателей, которые кто-то придумал. Потом участвовал в составлении показателей, как «представитель ИТ-отдела, который понимает сложность их расчета». Когда понял, что дело не в технике расчета, а где-то выше, попробовал сделать мотивацию для своих подчиненных. Когда она принесла людям прирост в деньгах, а компании — увеличение производительности людей вдвое, меня, в тестовом режиме, отправили делать систему для кладовщиков. Когда, благодаря этой системе, исчезли проблемы с несвоевременной погрузкой/разгрузкой/комплектацией и т.п., меня стали втыкать во все проекты по разработке мотивации. На моем месте, естественно, может быть любой программист.
За время этой работы я сделал ряд наблюдений о том, каким принципам и критериям должны удовлетворять взаимовыгодные системы мотивации. Спешу поделиться.
Первое и главное — система должна быть взаимовыгодной, т.е. помогать достижению целей обеих сторон — работника и компании. Или чуть по-другому: система должна поощрять ту деятельность, которая выгодна бизнесу, и поощрять так, чтобы это было выгодно работнику. Ну и, соответственно, не должна поощрять того, что бизнесу на хрен не нужно, а работнику нравится.
Начать следует с цели компании, именно здесь совершается большинство ошибок. Нужно максимально четко понять, чего вы хотите от людей, выполняющих функцию (вы — потому что вы в такой работе, как бы, на стороне бизнеса).
Того, чего вы от них хотите, не должно быть много. В идеале — один показатель. Если показателей будет много, то получится ССП — сбалансированная система показателей, которая очень быстро разбалансируется.
Я рекомендую делать так. Найдите один, самый важный продукт, производимый функцией, а все его важные характеристики уложите в правила измерения этого продукта.
Главное — продукт и его характеристики должны быть выгодны бизнесу. Вот тут, увы, вам никто особо не поможет с формулировкой продукта. Надо просто поговорить со всеми, кто причастен — в первую очередь, с внутренними потребителями, заказчиками этого продукта. Какие реальные проблемы у них возникают, и из-за какой именно характеристики (качество, сроки, своевременность и т.д.).
Предположим, в систему мотивации внутреннего программиста закладывают два показателя — выработка в часах и оценка качества пользователями. Их можно заменить одним — выработкой по задачам, оценка качества решения которых выше, например, 4 баллов. Если вас беспокоит еще и соблюдение сроков — добавляйте условие "..., выполненных в срок".
Решил задачу, получил оценку выше 4 баллов, уложился в срок — выработка засчитана. Не выполнил одно из условий — не засчитана (или засчитана с дисконтом). Это и будет продуктом.
Человек в этом случае лучше понимает, что есть продукт его работы. Ему не нужно создавать два продукта параллельно — выработку и оценку.
У меня был пример с таким распараллеливанием. Был у нас директор, которому я не нравился. Я, в общем-то, никому обычно не нравился, т.к. слишком много задавал вопросов, отклонял задач и проектов, и максимально доходчиво объяснял, почему решение какой-то задачи не принесет выгоды бизнесу. Ну, была у меня мысль, что именно этим должен заниматься ИТ-директор.
Так вот, при каждой смене директора все недовольные выстраивались в очередь, чтобы на меня пожаловаться — старый-то директор уже привык, и, видя результаты моей работы, понимал причины недовольства. Новый вникать не захотел, и впендюрил мне показатель в квартальную премию — оценка качества моей работы руководителями. Вроде, должно было не меньше 4.5 в среднем быть.
Ошибки две: квартальная оценка и отдельный показатель. При том, что у меня в системе и так была оценка на уровне каждой задачи, и реальные хейтеры не стеснялись ставить 2. Разумеется, на мою работу этот показатель никак не влиял. Бизнесу он тоже ничего полезного не принес. Просто в конце квартала я пришел к каждому руководителю, и с широкой улыбкой на лице попросил оценить мою работу. Разумеется, снабдив обещанием «уделять вашему отделу больше внимания». Премию получил в полном объеме.
Что интересно — при таком подходе зачастую отпадают лишние обязанности, или хотя бы они становятся видны. Это тот случай, когда вы меняете систему мотивации уже существующей, устоявшейся функции, с ворохом накопившейся неэффективности.
Например, вы выбрали продукт для функции, а люди говорят вам — а мы еще вот такую штуку делаем каждый день, уже два года. На такие штуки нужно очень пристально посмотреть незамыленным взглядом — действительно ли они вам нужны?
Примеров масса. Вот есть снабженцы, которые ведут в сетевом каталоге большой экселевский файл под названием «дефицитка». Это тупо перечень позиций номенклатуры, которые нужны для производства или продажи, но их проморгали. Выгружают из системы, проставляют сроки поставок, пишут какие-то комментарии. Тратят уйму времени. Все данные и так есть в системе, в постоянном доступе. Но так повелось, еще со времен отсутствия автоматизации.
Делаем мотивацию, в которой ничего нет про ведение этого файла. Раньше был оклад, внутрь которого масса такого говнеца помещалась, и платился он «вот за всё это». А теперь — сделка с гарантирующим окладом, за скользящий процент обеспеченности. Места для большой дефицитки просто не остается. Не, если кто хочет — пусть продолжает делать, только за свой счет. Где-то через пару недель большой экселевский файл исчез.
Так вот, каждую обязанность стоит подвергнуть тесту «на хрен она нужна». Если не нужна — прекрасно, смело выкидываем. Если люди против — еще лучше. Вы просто перестаете за это платить.
Если это что-то полезное, относящееся к продукту — отлично, вносим как характеристику.
Еще вариант, когда точно решить не можете — изолировать эту обязанность, и посмотреть что будет. Например, в случае с программистами можно изолировать тех.поддержку пользователей — посадить отдельного человека на эту работу. Важно, чтобы выполнение этой обязанности всеми подряд не могло служить отговоркой («мы не сделали выработку, потому что все вместе помогали этой дуре»). При изоляции влияния не будет, и вы сможете понять как объем этой странной обязанности, так и ее пользу для бизнеса.
Например, размазанная на всех тех.поддержка, вроде бы, занимала очень много времени. Точно никто не знал, сколько, и у кого, но ощущение у всех было, что «целый день звонят, как они уже задолбали, только сядешь, вникнешь — опять звонок». А когда тех.поддержку изолировали, оказалось, что она занимает максимум 4 часа в день у одного человека. При этом он никого из коллег не дергает, сам со всем справляется.
Итак, вы сформулировали продукт — чего вы хотите от функции.
Теперь нужно решить, сколько этого продукта вы хотите. Принципиально варианта два:
- Как можно больше (потолка нет)
- Не больше, чем нужно (потолок есть).
Для продавца потолка нет. Для снабженца — обычно есть. Для инженера-конструктора — нет. Для менеджера по персоналу — есть.
От наличия потолка зависит формула системы мотивации: сдельная или за достижение/поддержание уровня.
Например, платить снабженцу за объем закупа — неправильно, он вам переполнит склад какими-нибудь метизами, которые привозят через час после заказа в любом объеме. Платить за поддержание буфера в зеленой зоне — правильно, даже если в отчетном периоде человек ничего для этого не сделал, ввиду отсутствия потребления буфера — его вины в том нет.
Платить продавцу за объем заявок — тоже не всегда правильно (кроме случаев, когда спрос сильно ниже предложения). Продавцу лучше платить за продажи, а еще лучше — за приход денег, потому что внутрь продукта «продажа» уже заложены нужные бизнесу характеристики. Например, состоявшаяся продажа и оплата означают, что продукт был произведен, все материалы закуплены, услуги оказаны, деньги пришли на расчетный счет. Ну, это всем понятный пример.
Есть еще вариант для продвинутых — определение продукта через продажи или прибыль для тех, кто не занимается продажами и прибылью.
Например, платить снабженцу процент от прибыли с продаж того, что он купил. Или платить инженеру-конструктору процент от продаж того, что он сконструировал (типа авторский процент).
Этот вариант плох тем, что не очевиден становится бизнес-процесс — что конкретно должен делать человек каждый день, чтобы зарабатывать больше. Это показатель, измеряющий вклад в конечный результат, а не исполнение процесса.
Если бизнес-процесс некачественный, то люди начнут саботировать его изменения — будут бояться, что ваши изменения отрицательно повлияют на результат, и соответственно на их доход.
Но этот вариант также и хорош — тем, что вы вовлекаете людей в создание/оптимизацию бизнес-процесса, приводящего к нужному результату, потому что требования к результату у вас с ними теперь одинаковые.
Пользоваться таким вариантом или нет — зависит от ситуации и людей, для которых вы делаете систему мотивации. Если есть толковые, инициативные, и есть реальное влияние их или ваше на бизнес-процесс — можно попробовать.
Итак, если потолка нет — определите, сколько вы платите за единицу продукта. Обычно это процент с продаж/прибыли, или некая ставка — почасовая, например. Дальше дело техники.
Если потолок есть, то формула проще — вы платите за процент достижения потолка. Например, за выполнение плана продаж, или среднескользящий процент наполненности буфера, или за отработку всех поступивших задач. Процент — в единицах продукта, который вы определили для функции.
В процессе разработки системы мотивации очень рекомендую пользоваться, как минимум, триадой изменений (про триаду будет отдельная статья).
Наверняка окажется, что бизнес-процесс не позволяет производить, или выделить и измерить продукт, который вы назвали главным. Наверняка автоматизированная система, которую вы используете, не позволит вам рассчитывать показатели мотивации, особенно в ежедневном режиме.
Поэтому и рекомендую триаду — сразу менять и систему мотивации, и бизнес-процесс, и автоматизацию.
Особенно это актуально в случае, если вы будете запускать новую систему мотивации в тестовом режиме, параллельно с действующей, в течение определенного периода. Я, к слову, всегда так делаю — и люди посмотрят на альтернативу по доходам, и систему можно обкатать, недочеты устранить.
Также тестовый период важен для сбора статистики, особенно если вы измеряете продукт, который раньше не измеряли. Вам нужно определить расценку за него, а для этого вы должны понимать, сколько единиц продукта человек производит в месяц.
Расценка при этом примерно равна отношению дохода человека к объему произведенного продукта. Возможно, с небольшим снижением, чтобы был стимул делать больше.
На этом все — автоматизируете, тестируете, запускаете, следите и корректируете.
Посмотрим на результат со стороны работника. Главное, что дает работнику такая система мотивации — это определенность. Он четко понимает, за что платят деньги, а за что нет. И сколько платят. И что нужно сделать, чтобы заработать больше.
Есть, конечно, работники, для которых такая система будет не выгодной — те, кто привык прятаться в общей массе, когда личный результат не измерим. Также те, кто пришел просто посидеть. Это отличные ребята, но статья не про них и не для них.
Автор: nmivan
