Нужна новая система расчета зарплаты руководителя отдела
а также показатели результативности, плановые значения, оптимальные соотношения постоянной и премиальной частей зарплаты
На сайте ведутся работы
сегодня 10925 Подписчиков
По итогам просмотра видео и предварительной переписки:
Виртуальный кейс - решаем проблему заказчика (или задачу, но гораздо быстрей при том же уровне качества), все довольны, все зарабатывают.
Дано:
компания имеет стажеров в штате, найден клиент, готовый попробовать автоматизацию некоего нового БП (никаких данных с которыми нужно взаимодействовать строго определенных способом - нет).
Есть ли принципиальные отличия между установившейся схемой (УС) разработки решения для автоматизации и новой технологической схемой (ТС, кстати, хорошо бы уже придумать название :)?
Под УС следует понимать такую:
1. есть специалисты по android development
2. есть специалисты по БД MySQL, Postgres
3. есть бизнес-аналитик
4. есть фулл-стэк разработчики по web development
5. есть UI-специалисты
6. есть тех.лид - отвечающий за работу 1-5, документацию
7. есть рук-ль проекта (PM) - отвечающий за отношения с заказчиком и работающий вместе с тех.лидом
8. есть проверенное ПО (вкл. библиотеки) для создания кода и тестирования кода, есть документация к этому ПО, есть поддержка такого ПО, комъюнити пользователей.
9. есть проверенная архитектура развертывания и работы готового продукта - собственные или виртуальные веб-серверы, серверы БД, балансеры запросов, сервисы бэкапа (Amazon, Google Cloud, Heroku etc)
10. есть специалисты по пп.9-10
11. PM взаимодействует с заказчиком, транслирует согласованное ТЗ техлиду, техлид организовывает работу, согласованные функции продукта созданы и запущены в производство.
Далее, если нужны следующие функции - следующие итерации по п.11.
По УС, грубо, работают многие известные мне разработчики полного цикла.
Вопрос: "Есть Есть ли принципиальные отличия между установившейся схемой (УС) разработки решения для автоматизации и новой технологической схемой (ТС)? ... И будет ли обязательная поддержка разработчиков со стороны разработчиков "Сычев и Ко" (например, что-то не понятно или возникли неликвидируемые собственными силами ошибки)?
Рассматривается модель небольшой компании в области разработки ПО, где число разработчиков - 12 человек.
Вариант а)
Разработчики проживают в Москве, работают на постоянной основе в офисе в Москве.
Вариант б)
Разработчики проживают в регионе, работают на "удаленке".
Вариант а)
/указано начисление в месяц квалифицированному специалисту по Москве на ноябрь 2017/
Белый ФОТ
специалисты по android development
специалисты по БД MySQL, Postgres
бизнес-аналитик - 120000 руб.
есть фулл-стэк разработчики по web development
UI-специалисты
специалисты по пп.9-10, примем:
тех.лид (тимлид) - 180000 руб.
рук-ль проекта (PM) - 120000 руб.
Товарищи подсказали, что неплохо было бы добавить архитектора и тестировщиков отдельно - но в данной схеме предлагаю принять, что
- роль архитектора выполняется коллективом тимлид+старшие;
- тесты пишут все, под чутким оком главного тестировщика;
- фулл-стэк спецы при наличии отдельно выделенных android and UI/UX специалистов - достаточно закрывают имеющиеся потребности широкого профиля.
Стоимость сопровождения приложения:
- собственные ошибки за свой счет;
- поддержка версий библиотек, улучшения/добавления - отдельно.
Затраты на специалистов - 1 470 000 руб. в мес.
Затраты на их содержание и администрирование берем - 20% (относительно зарплаты разработчиков) = 294 000 руб/мес.
Все Затраты считаем равными 1 470 000 + 294 000 = 1 764 000 руб/мес.
Всю выручку будем считать Доходами (себестоимость примем около нуля).
Доходы-Затраты=Прибыль
Чтобы фраза "все довольны, все зарабатывают" не была ложной:
Таким образом:
Вариант а) - все сидят рядом в Москве
ФОТ специалистов - 1 470 000 руб/мес
Выручка от проектов - 4 410 000 руб/мес
5 проектов
Вариант б) - аутсорсинг перечисленных исполнителей в регионах.
Прим: поскольку реального опыта с такой конфигурацией у меня нет и пока не представляю всех этих специалистов на аутсорсе, грубо беру, что каждая зп в Москве выше аналогичной в регионе на 60%, админо-офисно-операционные расходы в три раза меньше.
ФОТ специалистов - 1 470 000 / 1.6 = 918 000 руб/мес
(100 000 руб/мес - соотв. затраты на админ-е, вместо 294 тыс.руб - положим так, поскольку все по своим норкам сидят)
Выручка от проектов - 2 545 000 руб/мес
3-4 проекта - видимо, все на аутсорсе трудней администрировать.
P.S.
Для исследования использовались данные:
jooble.ru
hh.ru
Кадры в digital: в исследовании (август 2014–декабрь 2015) учитывались только сотрудники, работающие на направлении digital-маркетинга и заказной веб- и мобильной разработки (не продуктовой; и не на обслуживании собственного продукта компании), тратящие более 50% рабочего времени на компанию на постоянной основе.
ttps://tagline.ru/staff-salaries-rates-education-hiring/
Обсуждение в Facebook: сколько стоит час разработки под iOS/Android | AppTractor
Подсчет себестоимости часа разработки программного обеспечения / Хабрахабр
https://habrahabr.ru/post/256537/.
Фонда оплаты труда: как определить величину ФОТ - Сайт по бизнесу TRIZ-RI
http://www.triz-ri.ru/motive/?id=6875&name=fond_oplatyi_truda
Здравствуйте, Коллега!
Появились уточняющие вопросы.
Ваша схема теоретическая или реальная?
Откуда берется поток таких дорогих заказов? Если случается перерыв в заказах, например, на 6 мес., специалисты расходятся?
Нужен еще "продажник", который делает презентации, уговаривает, подписывает договора, отслеживает оплату и т.п.
Также нужно проводить обучение пользователей, осуществлять тех. поддержку (сбор ошибок и новых пожеланий), обновлять версии.
С уважением,
По итогам просмотра видео и предварительной переписки:
Виртуальный кейс - решаем проблему заказчика (или задачу, но гораздо быстрей при том же уровне качества), все довольны, все зарабатывают.
Дано:
компания имеет стажеров в штате, найден клиент, готовый попробовать автоматизацию некоего нового БП (никаких данных с которыми нужно взаимодействовать строго определенных способом - нет).
специалисты по android development
специалисты по БД MySQL, Postgres
бизнес-аналитик - 120000 руб.
есть фулл-стэк разработчики по web development
UI-специалисты
специалисты по пп.9-10, примем:
тех.лид (тимлид) - 180000 руб.
рук-ль проекта (PM) - 120000 руб.
Товарищи подсказали, что неплохо было бы добавить архитектора и тестировщиков отдельно - но в данной схеме предлагаю принять, что
- роль архитектора выполняется коллективом тимлид+старшие;
- тесты пишут все, под чутким оком главного тестировщика;
- фулл-стэк спецы при наличии отдельно выделенных android and UI/UX специалистов - достаточно закрывают имеющиеся потребности широкого профиля.
Стоимость сопровождения приложения:
- собственные ошибки за свой счет;
- поддержка версий библиотек, улучшения/добавления - отдельно.
Уважаемый, Денис!
На мой взгляд, расценки бывают как ниже приведенных, так и выше (но это не значит, что их можно получить). Более важно, сможет ли лояльный сотрудник подождать на низкой ЗП дорогого заказа. Если у него кредит, то не сможет. "Невидимая рука рынка" не позволит))
В общем, и так понятно, что Сычевская технология значительно дешевле. Была бы полезной возможность "парковать франшизу" на случай приостановки активной деятельности (меняем офис, уехали в Тайланд и т.п.)
Хотелось бы сказать, что с ростом количества инсталляций усложняется сопровождение и тех. поддержка. Нужен не только регистр клиентов с их версиями и конфигурациями. Также нужно продолжать поддерживать все установленные версии и модули. Однажды нам подняли цены на подписку на устаревшую библиотеку, хотя мы ожидали скидку на нее. Причина: стало затратно поставщику продолжать ее поддерживать.
Если раньше было, допустим, 5 новых проектов в год, а станет 50, при той же системе учета начнется бардак.
О тех.поддержке: клиент звонит, когда захочет и с любым вопросом. Допустим, у клиента упал сервер (винда), а админа нет или он занят. И клиент звонит разработчику: ваша программа не запускается (а мы не майкрософт). Пока сотрудник тех.поддержки закроет эту заявку, пройдет как минимум 1 час. А если сбой серьезный и срочный, подключится разработчик или несколько и они провозятся до конца текущего дня. Так можно обслужить только одного "сбойного" клиента в день. А если количество клиентов возрастет на порядок, то при той же системе реагирования на сбои появятся очереди. А если ждать клиент не может, то скандалы.
Со временем, конечно, будет сделана база знаний с типовыми проблемами и нанят дополнительный персонал в тех.поддержку. Но со временем.
С уважением,
Сразу начнем с сути дела. Существует некий язык записи сути задачи. Если его применять, то сложные (креативные) задачи решать становится удобнее.
Как и любая модель, эта модель тоже жизнь собой не заменяет, однако авторы статьи попробовали и убедились в том, что действительно удобно. Хотя поначалу кажется непривычным… Впрочем, авторы, уважая время Коллег, постеснялись бы писать о привычном, знакомом, общеизвестном.
Рассмотрим серию примеров. Пока намеренно несложных. (Более сложные мы в дальнейшем тоже рассмотрим).
Запись первого вебинара (01.11.2017 г.) Александра и Сергея Сычевых, на котором был продемонстрирован сервис автоматического создания нативных мобильных приложений, сайтов и инфраструктуры для них... из файла Excel обычным человеком (не программистом).
Запись второго вебинара (03.11.2017 г.) Александра и Сергея Сычёвых. Решение технических противоречий в области IT с помощью ТРИЗ. Идеальная архитектура данных.
Эта парадигма создавалась из утилитарного стремления к идеалу, как в управленческом, так и в тризовском смысле. Формулировки идеальности (которые соответствуют по духу и замыслу тем, что сформулировал Генрих Альтшуллер, создавая ТРИЗ-технологии, и которые продвигали эту разработку) следующие:
1) Идеально - это когда программу сможет в отсутствие Автора не только сопровождать, но и развивать программист с меньшей квалификацией, чем Автор программы.
2) Идеально - когда добавление новой функциональности в программу не потребует внесения изменений и/или добавлений в программный код (более того, в совершенно идеальной программе увеличение функциональности приводит к сокращению кода); причём всё это без ущерба для любых параметров (например, быстродействия и т.д.).
И чтобы программы писались настолько быстро и сопровождались настолько просто, что их создание и сопровождение можно было бы поручить детям. А взрослые и умные специалисты пусть бы занялись чем-нибудь великим.
Для решения некоторых задач программирования в качестве "инструмента", облегчающего разработчику абстрагирование от конкретики, предлагается использовать "абсолютно тупого героя", которому поручается некая деятельность. Поскольку этот герой непроходимо туп (мы даже пишем его с маленькой буквы, чтобы и тени величия в нем не наблюдалось), то задача поручить ему деятельность, которая, тем не менее, должна быть выполнена — нетривиальна.
Тем не менее, надо описать решение так, чтобы тупой (несколько тупых) смогли качественно и незатратно порученную задачу выполнить.
Остальное понятно из контекста разбираемых примеров:
Действительно, создать качественную программу "из объектов", двигаясь "снизу вверх" (от подсистем к системе; от реализации к проекту), можно только при условии предельной простоты такой программы.
Однако, похоже, существует инерция мышления, оставшаяся с тех времен, когда все писали на низком уровне, и мысли о реализации неизбежно занимали наибольший промежуток времени. И многие программисты (конечно, не все) часто думают "снизу вверх". Больше над реализацией, чем над проектом.
Но, например, хороший архитектор никогда не проектирует дом "из квартир", а думает о нем сразу "в целом", "вписывает" в контекст окружающей среды, пользуется знаниями о готовых "стилях" (или создает свой стиль, зная о других). Хороший авиаконструктор не проектирует новый самолет "из его элементов", но пытается понять, как машина "летает в целом", или отталкивается от "принципов полета этого класса машин" и т.д., и т.п.
Мышление "снизу вверх" сродни попытке сложить организм из атомов углерода и водорода. Теоретически так сделать можно, но очень уж "многофакторно" и затратно как по времени, так и по ресурсам. И все равно, несмотря на затраты и при квалифицированной работе, получится урод + "теория неизбежности ошибок" вместо качественного продукта. За исключением, может быть, тех случаев, когда "организмом" (перепутав термины) назвали что-то предельно простое (например, 1 звено СН).
Описание бизнес-процессов - это средство, а не цель. А целью является не столько фиксация текущего опыта, сколько усовершенствование. Ведь, если сам опыт плох, то фиксация его приведет к тиражированию неудач.
По неведомым автору причинам эта ошибка допускается сплошь и рядом.
Публичная лекция о Теории Решения Изобретательских Задач (ТРИЗ/TRIZ), прочитанная С.В. Сычевым 28 мая 2017 года в рамках научно-просветительского проекта "Наука Pro".
Фрагмент выступления Сергея Сычёва на ежегодном TRIZ-RI ФОРУМе
"Открытые бизнес-методики и технологии",
Москва, 27 сентября 2011 г.
Один раз решили научить тупого молоть уголь и рисовать угольной крошкой по трафаретам на поверхностях и чуть не наломали дров. Сначала научили тупого рисовать углем "бабушку" на "окошке". Для этого, велели ему:
Кто придумал такую тупую инструкцию вспомнить уже невозможно — так, что материться глупо — надо работать. Поэтому с помощью воплей, дубины, «соцпакета» и 10-ти тупых администраторов кое-как упомянутый художественный результат достигался.
Причем 10 тупых администраторов периодически посещали семинары по мотивации тупых, где их учили более правильным "соцпакетам", в результате применения которых тупой должен был бы "раскрыться" и стать Личностью. А уж Личность смогла бы рисовать не только бабушек, но и птичек.
Однако, в связи с развитием рыночных отношений, задание усложнилось.
Два великих человека радикально высказались об оптимизации: "Единственный способ оптимизировать затратный проект – это его закрыть" (Питер Друкер) и "Идеальная система - та, которой нет, а функции ее выполняются" (Генрих Альтшуллер).
Этот материал посвящен (основанным на ТРИЗ) приемам сокращения работ при сохранении и улучшении их результатов. В этой части работы вслед за классиками сформулируем: "Лучшая работа – та, которую делать не надо, но результат ее получается".
Видеозаметка С.В. Сычева об оценке качества идей и эффективности решений на примере it-разработок: уровни сложности заданий - уровни достигнутых результатов.
"Было бы хорошо сделать консультационную фирму похожей на фабрику по производству отличной мебели.
Спрашивается, зачем?
Затем чтобы потом делать отменные фирмы, как удобные диваны..."
Данная закономерность была сформулирована автором в 1993 году в Иркутске. Ряд фактов уже тогда позволил построить модель, которую, тем не менее, нужно было проверить… Последующие 13 лет позволили сделать ряд обобщений, подтвердивших изначальную гипотезу.
Материал публикуется с некоторыми сокращениями и в то же время – с небольшими дополнениями.
Фрагмент выступления 08 апреля 2014 года на конференции "Открытые бизнес-методики и технологии", г. Ростов-на-Дону
Вы не поверите, но цель настоящей статьи – совсем не критика, ведь устранить несуразности, описанные ниже, не составит труда, а затраты копеечные. Авторов материала по должности нередко приглашают вычитывать разнообразные "концепции заведений", "системы менеджмента качества", "технологии клиентоориентированного обслуживания" и т.п. Но иногда приходится говорить: "Протрите, пожалуйста, столик, а только потом положите концепцию".
В статье приводятся, прежде всего, ошибки коммуникации с Гостем и простые решения, их устраняющие. Мы намеренно опускаем ошибки сервировки, подачи на стол и нарушение застольного этикета со стороны официантов.
Азбука консалтинга гласит: "Область постановки задач" (то есть, как они формулируются) достаточно часто не совпадает с "областью их действительного решения" (то есть, что случилось на самом деле). Например, желание "поднять командный дух", "сплотить коллектив", "ввести мотивацию от результатов всей компании" и т.п. – это нередко борьба со следствиями, а не с причинами.
Недавно наш знакомый консультант Mister Any получил следующий запрос: "Для подкрепления командного духа мне хочется ввести в отделе продаж доплату за выполнение плана всего отдела. Какой размер оптимален по отношению к общей зарплате сотрудника и к чему одна должна быть привязана? Рассчитываю на Вашу помощь". Подпись: Mr. Heart".
24 сентября 1998 г. умер великий человек. Генрих Саулович Альтшуллер, создатель и первый разработчик ТРИЗ - теории решения изобретательских задач, приемов развития творческого воображения, ЖСТЛ - жизненной стратегии творческой личности.
Уже сейчас ясно: это наука следующего тысячелетия. И нам будет трудно объяснить внукам, почему власть и электорат, начальники и ученые, спец. органы и педагоги так боялись новой науки в веке уходящем... Наверное потому, что ТРИЗ и ЖСТЛ меняют мышление, а значит и жизнь. Генрих Саулович считал, что человек должен прожить ее Достойно - на пределе своих возможностей. И он позволил себе так жить. Возможно, наши внуки окажутся сильнее нас...
И.Л. Викентьев
"Привязку" Клиентов к конкретным менеджерам обычно оправдывают долгой историей их общения в процессе сотрудничества, формирующей, помимо деловых, и личные отношения. А значит, формирующей и более глубокое понимание конкретным менеджером специфики работы с данной компанией.
Однако такая "привязка", вопреки стереотипу о комфортной работе со старым знакомым, неудобна для Клиента. Клиенту приходится ждать "своего сотрудника" и испытывать массу накладок, когда "старого знакомого" нет, хотя любой мог бы его обслужить. А если Клиент действительно полюбил работать с конкретным менеджером, то следует задать себе вопрос: "Почему Клиент хочет "личных отношений" с конкретным хорошим менеджером, даже в ущерб своим удобствам (приходится ожидать, перезванивать, просить, "чтобы передали" и т.п.)?"
Уровень зарплат на рынке и размер конкретного бизнеса не связаны друг с другом.
Есть определенные профессии, и есть их цена на рынке труда. Есть задания, которые поручены, и есть стоимость их выполнения. А также есть вопрос, который задают все: "Сколько платят такому специалисту в нашем городе?"
Конечно, хороший работник может и должен получать больше, а плохой — меньше. Однако, зарплата аналогичных работников в разных фирмах, в принципе, не может отличаться на порядки. Она может отличаться на 20–30%, но не в разы, тем более, не в десятки раз. Хотя выручка в крупном супермаркете и в "магазине на углу" может отличаться в сотни раз.
В материале приведен список основной литературы по ТРИЗ.
В разные годы издавались и другие книги (как правило, меньшим тиражом) других авторов. Но мы рекомендуем начинать знакомство именно с классики ТРИЗ - книг Г.С. Альтшуллера. Как правило, найти эти книги можно в крупных библиотеках.
Данная закономерность была сформулирована автором в 1993 году в Иркутске. Ряд фактов уже тогда давали возможность построить модель, которую, тем не менее, нужно было проверять в течение долгого времени. Последующие 13 лет позволили сделать ряд обобщений, подтвердивших изначальную гипотезу. И в 2006 году автор счёл возможным первую версию закономерности опубликовать открыто.
Летом 2013 года публикуется версия 2.0 - более полная, развернутая и содержащая одно существенное методическое отличие от первой версии.
Автор будет признателен Коллегам, которые найдут "узкие места" данной работы и направят автору критические замечания и/или примеры, как подтверждающие, так и опровергающие положения изложенные в материале.
Данная статья - пример решения проблемы подобного рода.
Трудности при определении эталонных планов продаж в разных магазинах одной торговой сети могут, кроме прочего, возникать из-за различной проходимости...
Эталоны, соответственно, установили не для каждого конкретного магазина, а для каждого типа магазина - то есть эталон будет одинаковым для всех магазинов попадающих в определенную группу и правила задания эталона определяются для группы. Казалось бы разница несущественна, но это только на первый взгляд...
Мы сделали для рабочих больше, чем профсоюзы. Мы не только дали им зарплату большую, чем требовали профсоюзы на своих стачках, но и повысили выработку, сократив затраты труда и существенно снизив эксплуатацию. Рабочие в США с момента внедрения системы научного менеджмента перестали называться "пролетариями", они стали делать сбережения, покупать жилье и платить за хорошее обучение своих детей.
Таким образом, вопреки марксизму было показано, что повышение производительности (в том числе, скачкообразное) при капитализме не приводит к обнищанию рабочих. Наоборот, приводит к их обогащению".
Мысль 1. Никогда не создавайте нескольких расценок за одну и ту же работу (равно и разных правил оценки одной и той же работы): ни во времени, ни в пространстве, ни между людьми.
Если Вы создадите их во времени (например, как описано в статье: за работу в будни - одни расценки, за работу в выходные дни - другие или иные вариации), работники сократят производительность в обычное время и перебросят объёмы на выходные. И Ваш бизнес-процесс будет дестабилизирован. Причём во множестве случаев работники смогут это сделать настолько "плавно", что заметить не удастся.
Мысль 2 (более глубокая)...
Есть устойчивые вещи, которые редко подвергаются анализу (типа: "А как же иначе?). Отсюда такие характерные ошибки мотивации сотрудников, как:
"Больная" для многих предпринимателей тема - участие работника в прибылях.
К счастью, есть решения, позволяющие не допустить связанных с этим ошибок в бизнесе.
Фрагмент выступления Сергея Сычёва, скрытно снятый слушателем на мобильный телефон.
Сергей Сычёв, "Предпринимательская этика", видеофрагмент части I "Этика и бизнес-процессы", апрель 2014., г. Ростов-на-Дону
О Ф.У. Тейлоре написано много. Между тем некорректная работа современных "писателей" (и не только российских) с первоисточниками, а также порой их обычное невежество превысили границы любых приличий. Ранее в своей работе "Мифы о системе научного менеджмента Ф.У. Тейлора" на этот факт уже обратили внимание специалисты А. Демьяненко и Л. Дятлова.
Ладно бы слабые люди просто хотели оттопырить свой "вклад в теорию менеджмента" и кидались бы на "слонов" - о том классиками давно написаны басни. Но приходится сталкиваться (и нередко) с ситуациями, когда недобросовестный критик мало того, что исказит первоисточник, так еще, по точному выражению И.Л. Викентьева, "вступит в полемику и "в пылу спора" припишет оппоненту глупость, которую сам придумал, а затем "разоблачит" его".
Мы хотим, по мере сил, этому препятствовать. Поэтому в Части I. "Предисловие к интервью" рассмотрены несколько частых, но ложных утверждений о научном менеджменте и о системе Ф.У.Тейлора, а также их опровержения.
Выступление Сергея Сычёва на конференции "Как навести порядок в бизнесе",
Москва, январь 2011 г.
Нередко, считая оборачиваемость средств в товарах, затрудняются определить точную сумму, связанную в складских остатках, за тот или иной период (знаменатель формулы). Ибо остатки товара меняются каждый день. И тогда берут ее среднее значение.
Эта классическая ошибка связана с инерцией мышления, когда средства в остатках почему-то отождествляются с потоком поступлений. Однако, даже через руки бедняка в течение всей жизни мог пройти миллион, при том что в каждый конкретный месяц он еле-еле сводил концы с концами и всегда оперировал мелкими суммами.
В статье – на наглядных примерах – показывается, где кроется неочевидная ошибка, и как ее избежать. Приводится корректная формула оборачиваемости денежных средств, связанных в товаре.
Жил-был молодой специалист и работал он в разных фирмах, если точнее, то в трех, в каждой в среднем по одному году. И везде все было одинаково: фирма как будто бы солидная, но периодически в ней происходили "аварии", крупные и мелкие, с Клиентами и партнерами, а порой случались и внутренние "поломки": с сотрудниками и отделами.
И тогда он с друзьями открыл свое дело. Сначала все было хорошо, даже замечательно, но через год фирма выросла, и стало в ней так же, как и в тех трех других, ОДИНАКОВО. Может и не так одинаково, но очень похоже…
И тогда бывший молодой специалист, а теперь уже совладелец бизнеса, посетил Семинары Системы "ТРИЗ-ШАНС" (раньше он посещал только Форум).
После посещения семинаров стало не просто понятно, что делать, но и как делать...В объявлениях о приёме на работу нередко пишут, что нужны те, кто "умеет работать в команде", как будто это дефицит. Пожалуй, следует писать иное: "Требуется эгоист, способный растолкать локтями тех, кто мешает ему заработать".
Но перейдём от сравнений к методике.
Когда мы измеряем результат работы сразу группы людей, не измеряя результатов каждого участника группы, то такой учёт результатов назовём "бригадным". Или командным результатом.
"Бригадный" учёт результатов труда - вредный, иногда вынужденный и может быть оправдан лишь в некоторых ситуациях. Рассмотрим подробнее....
Недостаток 1 (из 9-ти).
Неучет того факта, что сумма сделки и трудоемкость выполнения работ не связаны между собой. Соответственно,
1.1. Крупный разовый (иногда нежданный) "оборотистый" заказ не влечет за собой дополнительной трудоемкости, а зарплату увеличивает и в результате расслабляет сотрудников.
И наоборот. Когда основная работа по обслуживанию долгожданного Клиента только начинается, а новых поступлений не предвидится, сотрудники "правомерно" интересуются: почему при больших стараниях и трудозатратах, чем в прошлый "прибыльный" месяц, их зарплата "падает".
1.2. У сотрудников невольно вырабатывается неприязнь к дешевым товарам и услугам, стремление избегать работы с ними и соответствующее отношение к Клиентам, которые их покупают. Так, в иных магазинах у стенда с кофеварками/кофемолками (условно) продавца можно и не дождаться (в отличие, например, от стенда с проекционными ТВ).
Как результат, премия "непрозрачна". Связь оплаты с результатами труда пропадает...
Если Вы бываете в Европе по делам бизнеса или с частными целями, найдите время заехать к нам в Прагу. На консультацию, на стажировку, на деловой завтрак. За свежими идеями, за новыми методиками, за иной обстановкой и за иными возможностями.
В Праге Вас встретят наши лучшие эксперты. Мы предложим Вам качественные программы бизнес-обучения по-европейски. В том числе, сделанные "под Вас". В том формате, в каком удобно Вам.
Часто бывает так: людей на работу взяли, а дело не движется. Звонков мало, заявок еще меньше, клиентская база тает… И не только в отделе продаж.
А Вы возьмите к себе "на работу" наших специалистов.
Каждый из нас имеет более чем 20-летний опыт практического внедрения системы управления предприятием, администрирования бизнес-процессов в отделах: активных продаж, закупки (снабжения), продвижения, складском хозяйстве, бухгалтерии, IT и пр.
С нашим приходом на предприятие уже через короткое время процессы управления организацией начинают работать как хорошо отлаженный механизм. А штатные сотрудники привыкают выполнять свои функции.
"ТРИЗ" - Теория Решения Изобретательских Задач – самая сильная, на сегодняшний день, система создания новых идей и изобретений известна во многих странах: Германии, Великобритании, США, Швеции, Франции, Японии, Корее, Израиле, Вьетнаме, Испании, Финляндии, Канаде и др.
Книги автора ТРИЗ Генриха Альтшуллера [15.10.1926 - 24.09.1998] переведены на десятки иностранных языков. Большинство успешных компаний активно используют её для совершенствования своих товаров и услуг.
Кроме разработок по любой из тем, находящихся в этом разделе, мы предлагаем очные и on-line (оперативные) консультации.
По мере развития компании обостряется необходимость умного сокращения усилий и затрат для достижения той же результативности (или даже повышения результативности при сокращении усилий и затрат)...
Подобно велосипеду, профессионально сделанная и заложенная в основу корпоративной культуры система "фирменных стандартов" изобретается один раз и надолго.
Речь вовсе НЕ о "должностных обязанностях" или "должностных инструкциях", которых и без того великое множество в Интернете. Речь о предельно конкретных (а потому легко проверяемых), действиях сотрудников с оптимальным разделением функций между ними.
Иногда кажется, что "мы и сами пропишем" внутри компании своими силами…. Но тот, кому делегируется эта работа, просто "ходит" за каждым сотрудником и фиксирует всё, что делается в течение дня, недели, месяца. А потом устает и бросает...
Поэтому лучше поручить эту работу нам - в силу почти 20-летнего опыта мы делаем это быстро, прозрачно и очень качественно.