Продолжаю развивать тему о том, что еще полезного может сделать 1Сник для бизнеса.
Есть такая полезная задача — разработка систем мотивации. Я долго наблюдал за несчастными HR, которые создавали системы KPI, материальную и нематериальную мотивацию, силились поднять корпоративный дух. Мои наблюдения всегда показывали одно и то же — HR в этой работе чего-то не хватает. Вроде слова правильные говорят, и философия под их расчетами правильная лежит, но созданные ими системы мотивации не выдерживают никакой критики.
Почему-то всегда результатом становятся не связанные друг с другом показатели, большинство из которых не измеряются. Следом запускается проект по автоматизации расчета этих показателей, а к моменту его завершения показатели устаревают, потому что бизнес понимает, что хочет совсем не того, на чем показатели основаны.
Итогом почти всегда является «какая-нибудь» система мотивации, которая хоть что-то считает и дает хоть какое-то представление об эффективности работы людей. Но главная беда — система мотивации не приносит пользы бизнесу, потому что оценивает людей по критериям, не выгодным бизнесу.
Людям такая система мотивации тоже не приносит пользы, т.к. не дает возможности заработать больше денег, принося пользу бизнесу.
В итоге я пришел к выводу, что разработка систем мотивации — больше инженерная задача, чем гуманитарная (да простят меня милые и добрые HR). Как ни крути, система мотивации — это система показателей. Показатели — это измерение, управление границами, согласованность целей и возможностей, четкая взаимосвязь с бизнес-процессом, правильная автоматизация. Все перечисленное — инженерные задачи.
Кто в современном российском бизнесе тот человек, который по сумме компетенций — лучший в перечисленных областях? 1Сник, кто же еще.
За свою бытность 1Сником и ИТ-директором я руководил или участвовал в разработке десятка систем мотивации — для программистов, кладовщиков, конструкторов, снабженцев, руководителей. За это время я сделал ряд наблюдений о том, каким принципам и критериям должны удовлетворять взаимовыгодные системы мотивации.
Спешу поделиться.
Первое и главное — система должна быть взаимовыгодной, т.е. помогать достижению целей обеих сторон — работника и компании.
Начать следует с цели компании, именно здесь совершается большинство ошибок. Нужно максимально четко понять, чего вы хотите от людей, выполняющих функцию (вы — потому что вы в такой работе на стороне бизнеса).
Того, чего вы от них хотите, не должно быть много. В идеале — один показатель. Если показателей будет много, то получится ССП — сбалансированная система показателей, которая очень быстро разбалансируется.
Я рекомендую делать так. Найдите один, самый важный продукт, производимый функцией, а все его важные характеристики уложите в правила измерения.
Главное — продукт и его характеристики должны быть выгодны вам.
Например, в систему мотивации внутреннего программиста закладывают два показателя — выработка в часах и оценка качества пользователями. Их можно заменить одним — выработкой по задачам, оценка качества решения которых выше, например, 4 баллов.
Если вас беспокоит еще и соблюдение сроков — добавляйте условие «…, выполненных в срок».
Решил задачу, получил оценку выше 4 баллов, уложился в срок — выработка засчитана. Не выполнил одно из условий — не засчитана (или засчитана с дисконтом).
Человек в этом случае лучше понимает, что есть продукт его работы. Ему не нужно создавать два продукта параллельно — выработку и оценку.
Что интересно — при таком подходе зачастую отпадают лишние обязанности, или хотя бы они становятся видны. Это тот случай, когда вы меняете систему мотивации уже существующей, устоявшейся функции, с ворохом накопившейся неэффективности.
Например, вы выбрали продукт для функции, а люди говорят вам — а мы еще вот такую штуку делаем каждый день, уже два года.
На такие штуки нужно очень пристально посмотреть незамыленным взглядом — действительно ли они вам нужны?
Если нет — прекрасно, смело выкидываем. Если люди против — еще лучше. Вы просто перестаете за это платить.
Если это что-то полезное, относящееся к продукту — отлично, вносим как характеристику.
Еще вариант, когда точно решить не можете — изолировать эту обязанность, и посмотреть что будет. Например, в случае с программистами можно изолировать тех.поддержку пользователей — посадить отдельного человека на эту работу. Важно, чтобы выполнение этой обязанности всеми подряд не могло служить отговоркой («мы не сделали выработку, потому что все вместе помогали закрыть месяц»).
Итак, вы сформулировали продукт — чего вы хотите от функции.
Теперь нужно решить, сколько этого продукта вы хотите. Принципиально варианта два:
1. Как можно больше (потолка нет)
2. Не больше, чем нужно (потолок есть).
Для продавца потолка нет. Для снабженца — обычно есть. Для инженера-конструктора — нет. Для менеджера по персоналу — есть.
От наличия потолка зависит формула системы мотивации: сдельная или за достижение/поддержание уровня.
Например, платить снабженцу за объем закупа — неправильно, он вам переполнит склад. Платить за поддержание буфера в зеленой зоне — правильно, даже если в отчетном периоде человек ничего для этого не сделал, ввиду отсутствия потребления буфера.
Есть еще вариант для продвинутых — определение продукта через продажи или прибыль для тех, кто не занимается продажами и прибылью.
Например, платить снабженцу процент от прибыли с продаж того, что он купил. Или платить инженеру-конструктору процент от продаж того, что он сконструировал (авторский процент).
Этот вариант плох тем, что неочевиден становится бизнес-процесс — что конкретно должен делать человек каждый день, чтобы зарабатывать больше. Это показатель, измеряющий вклад в конечный результат, а не исполнение процесса.
Если бизнес-процесс некачественный, то люди начнут саботировать его изменения — будут бояться, что ваши изменения отрицательно повлияют на результат, и соответственно на их доход.
Но этот вариант также и хорош — тем, что вы вовлекаете людей в создание/оптимизацию бизнес-процесса, приводящего к нужному результату, потому что требования к результату у вас с ними теперь одинаковые.
Пользоваться таким вариантом или нет — зависит от ситуации и людей, для которых вы делаете систему мотивации. Если есть толковые, инициативные, и есть реальное влияние их или ваше на бизнес-процесс — можно попробовать.
Итак, если потолка нет — определите, сколько вы платите за единицу продукта. Обычно это процент с продаж/прибыли, или некая ставка — почасовая, например. Дальше дело техники.
Если потолок есть, то формула проще — вы платите за процент достижения потолка. Например, за выполнение плана продаж, или среднескользящий процент наполненности буфера, или за отработку всех поступивших задач. Процент — в единицах продукта, который вы определили для функции.
В процессе разработки системы мотивации очень рекомендую пользоваться, как минимум, триадой изменений (про триаду будет отдельная статья).
Наверняка окажется, что бизнес-процесс не позволяет производить, или выделить и измерить продукт, который вы назвали главным. Наверняка автоматизированная система, которую вы используете, не позволит вам рассчитывать показатели мотивации, особенно в ежедневном режиме.
Поэтому и рекомендую триаду — сразу менять и систему мотивации, и бизнес-процесс, и автоматизацию.
Особенно это актуально в случае, если вы будете запускать новую систему мотивации в тестовом режиме, параллельно с действующей, в течение определенного периода. Я, к слову, всегда так делаю — и люди посмотрят на альтернативу по доходам, и систему можно обкатать, недочеты устранить.
Также тестовый период важен для сбора статистики, особенно если вы измеряете продукт, который раньше не измеряли. Вам нужно определить расценку за него, а для этого вы должны понимать, сколько единиц продукта человек производит в месяц.
Расценка при этом примерно равна отношению дохода человека к объему произведенного продукта. Возможно, с небольшим снижением, чтобы был стимул делать больше.
На этом все — автоматизируете, тестируете, запускаете, следите и корректируете.
Посмотрим на результат со стороны работника. Главное, что дает работнику такая система мотивации — это определенность. Он четко понимает, за что платят деньги, а за что нет. И сколько платят. И что нужно сделать, чтобы заработать больше.
Есть, конечно, работники, для которых такая система будет не выгодной — те, кто привык прятаться в общей массе, когда личный результат не измерим. Также те, кто пришел просто посидеть. Но нам такие не нужны, тут вроде нечего обсуждать.
В разработке системы мотивации должен быть определен продукт, который производит человек, и который нужет.
Например, для менеджера это заказы
Для программиста решенные задачи..
Для охранника это часы охраны объекта.
И так далее…
На основании продукта можно составить показатели.
(1) ваше утверждение в чем-то расходится с текстом статьи?
Не расходится.
Еще есть идеальная картина, это то, как должны обстоять дела.
Вы изобразили в своей работе часть Административной шкалы.
У меня есть алгоритм работы с этой системой.
Строится идеальная картинка
По ней делаются показатели
и определяется продукт
Потом наоборот
По продукту уточняются показатели а потом идеальная картина.
(3)
дадите ссылку на авторитетный источник, где об этом почитать?
а у вас есть опыт такой работы? мне интересно пообщаться про опыт.
«Резкий ответ Деминга на это таков, что, если бы руководство прекратило демотивировать своих работников, тогда ему не понадобилось бы сильно беспокоиться о том, как их мотивировать.» Генри Нив — Организация как система.
(5) раз это о Деминге, то наверняка правда.
Еще что-то добавите?
В данном случае можно припомнить системных администраторов, у которых чем лучше они работают тем меньше заметно их работу 🙂
(7) есть история про конвейер Генри Форда подходящая (насчет правдивости не знаю):
На одном из заводов Генри Форда бригада работников получала деньги за то, что отдыхала. Это была сервисная бригада, которая отвечала за бесперебойную работу конвейера. Проще говоря — ремонтники.
Они получали зарплату только когда сидели в комнате отдыха. Как только зажигалась красная лампа поломки линии сборки, останавливался счетчик, начислявший им деньги.
Во-первых, они всегда оперативно делали ремонт, чтобы быстрее вернуться в комнату отдыха. Во-вторых, они делали ремонт всегда качественно, чтобы им не приходилось покидать комнату в ближайшее время из-за той же неисправности.
Но есть и интереснее схемы, конечно.
Неоднозначная статья, сильно неоднозначная. Вообще, подобные системы люди начинают воспринимать так, как будто руководство желает на них сэкономить или поменьше платить за работу. И достаточно сложно на многих должностях прописать такие KPI, чтобы они именно мотивировали. Ведь достаточно одной «паршивой овцы», которая будет гнать негатив, чтобы бурлил весь коллектив.
Снабженец не участвует ни в ценообразовании, ни в дополнительных затратах на продукт, как он может повлиять на прибыль? Сотрудник должен влиять на процесс достижения своих показателей, иначе это система демотивации.
Или, например, программист, сидит над задачей, которая требует какого либо изучения, а у него план — 10 задач. Он ее бросает, делает план и забивает на остальное 🙂
И еще, подобные системы должны пересматриваться руководством регулярно. Особенно у нас в стране, т.к. внешние условия меняются достаточно часто. К примеру, прыгнул бакс и все тут же не уложились в бюджеты. Что делать, лишать людей части зарплаты или переходить в «ручное» управление?
(6) Можете почитать еще «Драйв. Что на самом деле нас мотивирует» Дэниел Пинк
(9) Снабженец в общем может и не получать задач от продажников, что конкретно закупить. И если он закупит то, что плохо продается — он таки повлияет на прибыль 🙂
Для рабочих специальностей лучшая мотивация — сдельная оплата, к тому-же, кроме чисто мотивации, сдельная оплата решает ряд других проблем.
Система мотивации для ИТР в России зачастую является по сути системой демотивации, и именно поэтому ее внедрение доверяют HR…
(9)
я подобные системы делал вместе с людьми, для которых она делается.
влияет или не влияет — зависит от контекста. Во-первых, он работает с ценой закупа, это сильно в его власти. Цена закупа — больше половины цены продажи. Во-вторых, в той конкретной ситуации снабженец был главным тормозом продаж, ибо порождал дефициты. Клиент стоял с деньгами (его привел продавец), а отгрузить ему было нечего. Бизнес-процесс, автоматизация — все было за снабженца. Кроме мотивации — его зарплата никак не зависела от продаж или прибыли.
это классная тема. Хотел про нее на конференции инфостарта рассказать.
совершенно верно. Более того, лично я рекомендую тестовую эксплуатацию в течение нескольких месяцев, с одновременной перестройкой бизнес-процесса и автоматизацией, чтобы выявить все косяки.
(11)
в смысле — доверяют тем, кого не жалко на амбразуру бросить? (я про HR)
(13) Можно и так сказать, конечно. HR проще разрабатывать систему наказаний, чем непосредственным руководителям наказуемых :))
Я наблюдал на практике 3 случая попытки внедрения KPI, все они делались руками HR, и все по сути свелись к бессмысленному формальному заполнению ненужных бумажек…
(14) согласен, так оно и обстоит.
исправьте опечатку
(11)
Если снабженец закупает что ему вздумается, значит хвост рулит собакой. В такой ситуации соглашусь с такой постановкой KPI.
(12)
Зачастую их делают во 1-х втихую, во 2-х без привлечения «кроликов» 🙂
(12)
так может статейку?
(12)
тестовый период обязателен и он должен идти параллельно, т.е. начислили зарплату по старому, показали сколько было бы по новому. Чтобы люди осознали плюшки и грабли. Часть «паршивых овец» отсеется на этом этапе.
(16) спасибо, исправил
(17)
да, но мы же не «зачастую», мы лучше.
(17)
да, скорее всего надо. Интересный был опыт.
(17)
да, согласен.
(17)
Нет, это просто такой бизнес-процесс :)) Они разные бывают в разных организациях.
(20)
Да я в курсе, в разных работал. Просто, когда закупщики закупают самостоятельно, они бывает забивают на обратную связь «с передовой». Понятно, что им виднее, чем руководителю например магазина, они видят в рамках всей компании. Но, как я уже говорил, они бывает забивают на заявки с первой линии. Тем более, что, как правило неудовлетворенный спрос фиксируется плохо и «на ощущениях».
Что думаете о том, что при таком подходе:
1. возможен переход к формальному исполнению
2. пропадает возможность перемещать людей между смежными задачами (проектная работа — тех.поддержка — внедрение — … )
?
(22) в правильной системе такой переход не состоится. Правильная — это когда вы правильно определили продукт и перечислили критерии, когда он считается качественным. Ну и сказали в своей системе, что платите только за качественный продукт.
Например, на фиксе это может быть оценка качества исполнения заявки заказчиком. Если заказчик не принял исполнение заявки, результат его не устроил, или он поставил оценку 3 из 5, то такой продукт можно не оплачивать исполнителю. Разумеется, об этом надо договориться заранее, чтобы исполнитель знал об условиях и понимал, что за продукт он должен изготовить. Не просто код, обработку или отчет — а код, обработку или отчет, который решит задачу пользователя.
Ну и разумеется, вам, как владельцу системы мотивации, нужно предусмотреть контроль заявок на входе, чтобы программисты не договорились с пользователями о выполнении простой, но никому не нужной работы.
Найдутся, естественно, капризные заказчики, которые всегда будут ставить плохие оценки или не принимать результаты выполнения заявок. Отлично, тогда в системе должен появиться контур, который не позволит тратить много времени на таких заказчиков. Например, формализация требований. Или — невозможность подавать заявки, если есть три с непринятым результатом.
(23) ну в общем все сводится к счетчикам в воротах качества — строим ворота и ставим счетчик попаданий
я бы на ваш последний абзац добавил следующее — «по работам, не прошедшим ворота качества, РП лично определяет причину этого и стремится устранить ее в будущем»
про падение кадровой динамики все равно не ясно — пока больше походит на серийное производство — большой штат тех.поддержки/call центры
(24)
не знаю, что такое «ворота качества», но — да, это про качество продукта.
и не только по некачественным работам, но и по низкой выработке, производительности людей. Это уже про скрам.
Про перемещение людей между видами деятельности — правильная система мотивации позволяет это делать без особых трудностей. Обещаю написать статью про свой опыт построения такой системы для программистов.
ворота качества — это формализованная система измерений результата работы.
либо проходит в ворота шарик — либо нет
если не прошел — значит зря потратили ресурсы на ненадлежащее качество
(26)
т.е. булево? Как ?
(27) конечно
Вы либо выпускаете айфон в продажу — либо нет
Либо засчитываете сотруднику работу — либо нет
В итоге — булево решение
указанную статью не знаю как связать с текущей — не вижу связи
вы имеете в виду то, что должен быть человек, который способен объять всю систему целиком ?
(28)
там в конце написано про количественные и альтернативные признаки качества.
Альтернативный (булево) дает понимание только о том, качественный продукт или нет.
Количественный (цифра) дает понимание о том, насколько качественный или некачественный продукт.
Цифра дает возможность работать над улучшением качества, булево — только над обеспечением приемлемого уровня. Ну т.е. оперируя булевым, вы можете создать годный продукт. Оперируя цифрой, вы можете создать лучший продукт.
Банальный пример, в контексте мотивации — премия за достижение плана. Если там один шаг — премия за перевыполнение — то это булево. И факт выполнения 200 или 300 процентов вы не получите — люди будут останавливаться на 101 %. Так, кстати, было на заводе, упомянутом в статье. Цитирую рабочего: «план на смену у меня 1300, я делаю немножко больше, чтобы премию получить». А наблюдение за его работой показало, что он уходит домой в 15:00, хотя рабочий день до 17:00.
Если шагов несколько, например премия за 120, 150, но с потолком 175, то вероятность перевыполнения значительно выше.
я вас понял
часто делают так
меньше 80% плана — нет премии (булев порог мин.качества)
от 80% до 100% — линейная функция с одним (обычно высоким) угловым k
от 100% и выше плана — с другим (обычно низким) коэффициентом k
верхняя отсечка — свыше определенного перевыполнения — можно не увеличивать премию
булево — это 80%
с коэффициентами — творческий процесс )
ну и корректно определить меру
(29) Очевидно, что если рабочий перевыполнит план на 150% — на следующий месяц план будет на 150% больше :))
(31) да, так оно и происходит.
Но изменение норм, опять же, можно сделать прозрачной частью системы.
Хотя в целом я против планов, как основы мотивации.
против планов, как основы
вот так одной фразой можно зачеркнуть все ранее сказанное