Комментарии 11
На мой взгляд, ваше объяснение выталкивающих и вытягивающих систем слишком путаное.
Есть технологический процесс от сырья/исходного продукта до готового продукта/ услуги.
Выталкивающий процесс - когда на всех стадиях работа делается тогда и в том количестве, в котором для этого есть сырье, ресурсы, мощности оборудования, и результат "выталкивается" на следующий уровень. При этом потребности заказчика не учитываются - если произведено больше, чем нужно заказчику - создаются запасы, если меньше - дефицит на следующей стадии.
Вытягивающий процесс - когда сигнал о том, сколько, чего и когда произвести, поступает от заказчика - рынка, подразделения по продажам, а в техпроцессе - от стадии следующего передела. В этом случае в каждый момент "вытягивается" необходимое количество работы и отправляется на следующий этап, запасы минимизируются, оборудование используется более оптимально.
В случае парихмахерской, где нет сырья и полуфабрикатов, вытягивание - это внимательное изучение запросов клиента и подстройка количества кресел, работающих мастеров, обучения мастеров так, стобы максимально удовлетворить максимум клиентов и без очередей. Выталкивание - когда "у нас есть 3 кресла, 3 мастера и перечень из 3 услуг, не нравится - ищите другую цирюльню".
Да, слишком примитивное и условное разделение. В жизни, даже в той же парикмахерской (в отличие от кассира в магазине или в окошке госуслуг) всё гораздо сложнее. А про производство ПО и говорить нечего.
Ну и вообще, когда меня чему-то учат, начиная со слов "как говоритЬся", то рука тянется к.... ну вы поняли. :)
В целом да, KPI привязанный к денежной мотивации(демотивации) будет взломан :) в самом инструменте плохого ничего нет, инструмент контроля процессов - не людей, а процессов (где по разработанным триггерам будет понятно, что или с процессом что-то не так, или с методикой измерения). Лепить сюда бабки - ну такое, хотя некоторые бизнесы очень любят. Немного применимо к рутине вроде коллцентра/саппорта, но и тут часто приводит к снижению качества работы (регулярно встречаю когда саппорт всеми правдами и неправдами стремится закрыть обращение как можно скорее).
В творческой работе (проектной деятельности) бабки логичнее вязать (если вязать) на достижение поставленных целей, KPI может помочь держать некоторые процессы на контроле и принимать меры заранее. Если команда сервисная - тогда можно отталкиваться от SLA (это не только скорость закрытия тикетов или доступность сайта, а вообще соглашение с заказчиком об услуге) и его соблюдении. И тут тоже может помочь KPI.
для ИТ наилучший KPI - минимальное количество обращений к тебе, это значит что ты стараешься работать на перспективу, предусмотреть возможные проблемы. Но, к сожалению, менеждеры это плохо понимают! у тебя нет заявок - значит ты бездельник и тебя можно уволить...
немношк зависит от направления, одно дело сервисное подразделение (саппорт, админы), другое - проектное (разработка, внедренцы). видел попытку сделать KPI сервисного подразделения как раз на минимум обращений, но провалилось - поскольку очень много зависит не от них.
слышал ещё про смешное - когда пытались сделать соревновательный kpi. разработка теряла в бабках если тестировщики находили баг, а тестировщики - если баг доходил до прода:) насколько я знаю, тоже провалилось
в одной техподдержке один менеджер решил снизить количество заявок, считая, что чем их меньше, тем лучше работает саппорт. И саппорт лучше работать не стал, качество услуги не выросло, зато выросло недовольство пользователей. Так что не все так просто с одиночными показателями.
У саппорта уменьшение количества заявок не скажет об эффективности - скорее о сокрытии проблем. У программистов вообще по-другому будет.
" ... Для торговли применял редко, так как для них это не работает, там одна операция – продать!.."
Упустили элемент "На рихешь" из вытягивающей носороговой системы в прямой спичевой торговле на полях)
Менеджер, придумывающий новые KPI для исполнения персоналом, похож на неугомонного изобретателя вечного двигателя, который не верит в закон сохранения энергии точно так же, как сам менеджер не верит в закон Гудхарта. Он всегда уверен, что "ну вот в этот-то раз уже всё получится!".
Про измерение различными показателями (например, KPI) уже давно написано классиком менеджмента Питером Друкером.
Однако все чаще встречается желание инвесторов измерить эффективность команды разработки.
Привязать затраты на разработку к результату с измеримыми характеристиками.
Примерно года два изучаю вопрос – как определить эффективность команды разработки и каждого участникам команды. Все измерения имеют ограничения и, по сути, получаем искусственный показатель эффективности. В таком случае не вижу никакой ценности в этом показателе. В общем, получается бег по кругу.
Предложу вам пару неочевидных выводов из вашей статьи.
Толкающая система - это эволюционный этап вытягивающей. Все kpi вытягивающей системы должны отражать отклонение показателей от того уровня, когда вытягивающая система превращается в толкающую. Все kpi толкающей системы не нужны. У неё один показатель эффективности - наличие прибыли.
Примеры, 1) переход в производстве от работы на склад к работе Точно-в-срок. 2) если в поселке одна парикмахерская, перед новогодними корпоративом, парикмахер обработав одного посетителя, выдергивает "со склада" (из очереди, по записи) следующего. Причем "по записи" - это ещё толкающая система, более эффективный этап развития парикмахерской, чем обслуживать клиентов по очереди.
По KPI