Главное не результат, главное процесс

BPM-блог Анатолия Белайчука

Как разделение труда снижает производительность

Во всем виноват Адам Смит! Ведь это он изобрел разделение труда. Впрочем, есть мнение, что он его не изобрел, а лишь описал. Пусть так — в конце концов, дело не в личности, а в явлении.

Жизнь наша устроена так, что стоит найти решение какой-то проблемы, как это решение через некоторое время само становится проблемой. Вот и разделение труда, позволив повысить производительность труда в одних случаях, создало проблемы с производительностью труда в других.

С одной стороны, специализация — благо: если хочешь делать что-то хорошо, то надо этому учиться, тренироваться, специализироваться. Это очевидно. И вот мы выбираем будущую профессию, идем кто в колледж, кто в университет, и становимся квалифицированными экономистами, технологами, слесарями, рекламщиками или программистами.

По окончании учебы мы приходим в компании, рассаживаемся по департаментам и отделам… и тут обнаруживается, что для сотрудника, попавшего в иерархию, интересы его собственные и ближайшего окружения — коллег из его отдела — заслоняют интересы компании в целом. Мы отлично подготовленные специалисты, в своей области мы способны демонстрировать выдающуюся производительность, но эта производительность сотрудника или подразделения, как оказалось, вовсе не гарантирует эффективность компании. Да дистанция и между «способны демонстрировать» и «фактически демонстрируем» может оказаться совсем не малой.

Во времена Адама Смита и позже, во времена Тэйлора, эта проблема остро не стояла, поскольку тогда речь шла в основном о разделении труда производственных рабочих. Пока у вас каждый работник занимается одной своей операцией и последовательность этих операций детерминирована, организация эффективной совместной работы представляется относительно несложной задачей. Вам надо провести нормирование рабочего времени на каждую операцию и, отталкиваясь от требуемого темпа выпуска готовой продукции, рассчитать ритм конвейера и количество работников на каждом этапе. Так появилась наука проектирования производственных процессов.

Первые сложности возникают, когда мы переходим от выпуска швейных иголок, рассмотренных Смитом, и легендарной модели T, «цвет которой может быть любым при условии, что этот цвет черный», к чему-то более разнообразному. Возникает неопределенность тем большая, чем шире номенклатура готовой продукции и чем через большее число переделов (читай — производственных цехов) должно пройти первичное сырье, чтобы превратиться в готовую продукцию. Западные люди привлекают на помощь компьютер и разрабатывают системы MRP, MRP-II, ERP, APS… Японцы идут своим путем и изобретают Just In Time и «аналоговый компьютер» канбан. Так или иначе, каким-то из этих методов (а скорее — их сочетанием) проблема решается.

Все становится еще хуже, когда мы переключаемся с технологических процессов, протекающих в производственных цехах, на бизнес-процессы, протекающих в офисе. Тут обнаруживаются дополнительные сложности: многозадачность, нешаблонность и кросс-функциональность.

Под многозадачностью понимается необходимость многократно в течение дня (а то и часа) переключаться с одной работы на другую. Работники производственного конвейера жалуются на монотонность работы, работа же в офисе сегодня представляет собой другую крайность: чем грамотнее, опытнее, ответственнее сотрудник, тем больше его «грузят» — тем в большем числе процессов его стремятся задействовать.

Естественных защитных реакций две: во-первых, попытаться минимизировать число переключений. Например, бухгалтерия подписывает счета только после 16 часов, потому что обрабатывать их сразу значит переключаться, а это влечет за собой «снижение производительности». Это классический пример «локальной оптимизации» (на всякий случай, слово ругательное): производительность бухгалтерии при таком подходе повысится, но эффективность компании в глазах клиента, очевидно, уменьшится.

Вторая реакция — постараться сделать так, чтобы никто не догадался, насколько производительно я на самом деле способен работать. В самом деле, выкладываться и работать в полную силу работнику зачастую глупо: «кто везет, на того и грузят». Непосредственный руководитель, будучи, как правило, опытным профессионалом, способен отличить работягу от лодыря, но ему может оказаться проще и выгоднее не прессовать своих подчиненных, а идти у них на поводу и добиваться увеличения штата, обосновывая это тем, что его сотрудники задыхаются от непомерного объема работы. Ведь если его коллеги — начальники других отделов — пойдут по этому пути, а он затеет борьбу за повышение эффективности, то в результате, как минимум, потратит свои нервы и здоровье, а скорее всего, еще и проиграет им в карьерной гонке — ведь чем больше у начальника подчиненных, тем больше его вес и значимость.

Теперь что касается нешаблонности. Замерить и отнормировать производительность производственного рабочего, занятого на рутинной работе — нет проблем. Но как померять объем работы, выполненной, например, программистом — числом строк кода? Такой способ многократно заклеймен как порочный, но штука в том, что ничего лучшего, по большому счету, не придумано. И со всеми работниками умственного труда эта проблема: «он думает»! Чего он там думает и надумает ли что в итоге — непонятно, а зарплату за каждый отработанный час заплати!

Сто лет назад некий профессор Рингельман обнаружил эффект, который позднее назвали его именем. Профессор сначала мерял, с какой силой способен тянуть канат один человек, а потом давал тот же канат команде из двоих, троих и так далее. В результате выяснилось следующее: когда человек тянет лямку один, и его индивидуальные показатели четко видны, он прилагает максимум сил. Если же точно известно, что можно расслабиться и никто этого не сможет определить, то человек неизбежно, сознательно или бессознательно, именно это и делает — расслабляется. Причем чем больше коллектив, тем расслабляется сильнее — согласно проведенным опытам, 8 человек тянут уже вполсилы.

В эту же тему Закон Паркинсона, гласящий, что работа заполняет все отпущенное на нее время, и проведенные в MIT замечательные эксперименты Дэна Ариэля, показавшие, что большинство людей не может удержаться, чтобы не сжульничать хоть чуть-чуть там, где они точно знают, что их невозможно поймать и где их жульничество если и нанесет вред, то чему-то далекому и абстрактному, а не их окружению.

Итак, если даже в однородной команде по перетягиванию уже возникают проблемы, то чего же ожидать там, где требуются слаженные действия нескольких подразделений? Предчувствия вас не обманывают: рассмотренные выше проблемы производительности просто меркнут на фоне проблем кросс-функциональных, то есть связанных с передачей работы между подразделениями по горизонтали организационной иерархии.

Всякий раз, когда от функционально-иерархической организации требуется результат, который требует совместной работы нескольких подразделений, ее лихорадит. Классический пример: бизнес «Проектирование под заказ». Это когда для того, чтобы выдать потенциальному заказчику коммерческое предложение (т.е. назвать цену и сроки), требуется заинтересованное участие как минимум: 1) менеджера продаж, который держит канал коммуникаций с клиентом, 2) конструкторов-инженеров, которые должны определиться как и из чего мы это будем делать, 3) снабженцев, которые должны сказать сколько это «из чего» будет стоить, 4) производственников, которые должны сказать в какие сроки мы способны это произвести и 5) экономистов, которые должны сосчитать, во что нам это обойдется.

Кондово-иерархическая организация решать подобные задачи в приемлемые сроки и с приемлемым качеством не способна. Потому что с какой стати производство должно подчиняться отделу продаж? У тех и у других свои начальники, свои ресурсы, свои бюджеты, свои показатели эффективности… что вы сказали, клиенты? Не-а, не слышали.

И это еще не самая сложная задача, так как в проектировании под заказ последовательность действий от одного клиентского запроса до другого не меняется. А бывает, что последовательность непредсказуема, так как работа по природе своей творческая: геологические изыскания, дело адвокатской конторы в суде и тому подобное.

Возвращаясь к исходному тезису: обратите внимание, все эти проблемы мы получили вдовесок к разделению труда — у индивидуального цехового мастера нет и не может быть ничего подобного.

То есть с одной стороны, за счет разделения труда мы подняли номинальную производительность. Но одновременно возникли проблемы размытых показателей, коллективной ответственности и разобщенности между подразделениями, из-за которых производительность труда неизбежно снижается. Чем больше масштаб организации, тем больше масштаб этих паразитных издержек. Причем не только в абсолютном, но и в относительном исчислении — эффект здесь нелинейный. Таким образом, нежелательные побочные эффекты разделения труда жестко ограничивают масштаб, задавая порог, при достижении которого производительность не только не растет, но начинает снижаться.

Как оценить этот порог? Для начала определимся с метрикой. С учетом того, что производственный процесс проще держать под контролем — в нем нет многозадачности, понятны критерии производительности и это более-менее одно подразделение — подходящим показателем масштаба организации выглядит число «белых воротничков» — руководителей всех уровней, инженерно-технических и офисных работников.

Пороговый масштаб, при достижении которого надо издержки разделения труда становятся неприемлемыми, конечно же, зависит от субъективных факторов — личности первого лица, культуры компании, ее возраста… Поэтому его нельзя определить однозначно, но думается, что для большинства организаций предел, за которым надо всерьез думать о компенсации органических дефектов функционально-иерархического управления, лежит в диапазоне от 20 до 100 сотрудников, за среднее можно взять число 50 (напомним, учитываются только «белые воротнички»).

Что именно надо делать, какие существуют способы компенсации дефектов функционального управления – об этом мы поговорим в следующей заметке. Разумеется, речь не пойдет об отказе от разделения труда. Двигаться надо не назад, а вперед: как, получив преимущество, компенсировать возникающие издержки. (Продолжение следует.)

Похожие статьи:

31.01.15 | Статьи | ,    

Комментарии

А что вы думаете?

Captcha

Copyright © 2008-2016 Анатолий Белайчук. Спасибо Wordpress и Yahoo.  Контент  Комментарии