Как выбрать между ручным, проектным и процессным управлением

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

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

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

Какие есть варианты действий у руководителя в ситуации начинающегося раздрая?

Несистемный ответ на вызов: ручное управление. Руководитель вникает в возникающие между службами конфликты, принимает волевые решения, добивается результата.

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

Тут обычно приходится ко двору идея управления по показателям. Разумеется, иметь объективную информацию о состоянии компании лучше, чем не иметь. Но вот, предположим, вы получили вожделенные данные, и, допустим, они вас не устроили — делать-то что?

Воспользуемся аналогией: водитель автомобиля смотрит на спидометр, и если он показывает не ту скорость, которая его устраивает, то у него есть педали — тормоз, газ. Показатели — это тот же спидометр, но где педали, на которые можно жать в управлении компанией?

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

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

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

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

Удивительно, но эта проблема была полностью осознана относительно недавно. Одним из первых, кто заговорил о ней во весь голос, был Гэри Раммлер, в 1991 году в соавторстве со своим партнером Аланом Брэки издавший книгу с говорящим названием «Как управлять белым полем на организационной диаграмме» («How to Manage the White Space on the Organization Chart»).

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

Начнем с первого. В чем суть проектного управления?

Фактически руководитель компании делегирует руководителю проекта самые главные свои полномочия — возможность принимать решения и требовать их исполнения, не считаясь с должностями и статусом. Это делегирование ограничено только рамками проекта и положениями, зафиксированными в уставе проекта.

Как это выглядит на практике? Один руководитель проекта, когда ему приходилось сталкиваться с саботажем со стороны исполнителя или руководителя подразделения, произносил одну и ту же фразу: «Вы сами сделаете то, что от вас требуется, или хотите, чтобы вас об этом попросил лично генеральный директор? Я могу это устроить». Работало замечательно.

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

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

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

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

У процесса последовательность тоже может от раза к разу не совпадать — возможны варианты, условия, развилки, бизнес-правила. Важна предсказуемость: сколько бы ни было развилок, все они нам известны наперед, и известны условия, по которым процесс пойдет по той или другой траектории. Если это условие выполняется, мы имеем дело с процессом.

Для наглядности сведем различия между ручным, проектным и процессным управлением в таблицу:

Ручное управление

Проектное управление

Процессное управление

Передача ответственности между подразделениями

Через служебные записки и распоряжения

Обеспечивает менеджер проекта

Автоматически в соответствии с утвержденной схемой процесса

Начальные затраты

Проектирование отсутствует, начальные затраты нулевые

Существенные затраты на инициацию проекта

Большие затраты на проектирование процесса

Текущие затраты

Большие затраты из-за использования критического ресурса - руководителя

Существенные затраты из-за использования дорогого ресурса – менеджера проекта

Минимальные затраты – все делается по шаблону

Предсказуемость

Результат слабо предсказуем, так как зависит от субъективных факторов

План-график, основанный на экспертной оценке исполнителей и менеджера проекта

Сквозной мониторинг, основанный на нормативах и статистике продолжительности задач и подпроцессов

Контроль

О фактическом состоянии дел можно судить только по докладам исполнителей

Контроль план-графика и фактических результатов работ ведется раздельно (в разных системах), соответствие не гарантировано

Отметка о выполнении задачи в рамках процесса невозможна без предоставления фактически полученных результатов, разрыв исключен

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

Какие следствия вытекают из этого утверждения:

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

  • Глубина организационной иерархии. В чисто функциональной иерархии, если вам что-то нужно от соседнего подразделения, вы пишете служебную записку наверх, начальству, и она пересылается до нужного уровня. Например, если вам нужна помощь соседнего отдела — на уровень начальника департамента, если соседнего департамента — на уровень первого лица. Чем глубже иерархия, тем более извилистым получается путь, тем выше потери.
  • Степень вовлеченности подразделений в совместную деятельность (горизонтальный охват бизнес-процесса). Заказчика не интересует внутренняя структура компании, качество с его точки зрения — это прийти и уйти довольным с минимальными потерями времени и нервов (качество продукции и цена, конечно, при этом подразумеваются). Значит, как минимум, в рамках выполнения заказа клиента должны слаженно отработать отдел продаж, логистика, финансы и производство (если есть). Но если в рамках бизнес-процесса продаж подразделениям приходится договариваться хочешь-не хочешь (иначе не будет ни заказов, ни компании), то работа с рекламациями, также требующая взаимодействия и взаимопонимания между несколькими подразделениями, часто оказывается «в загоне». Негативные последствия для бизнеса обычно не заставляют себя ждать.
  • Разобщенность компании – географическая, языковая, культурная. Понятно, что территориально-распределенной компании сложнее выстраивать коммуникации. Но разделительные линии могут проходить и в рамках одного офиса. Например, «мы» – это инженеры, конструктора, производственники и «они» – финансисты, бухгалтеры и прочие маркетологи.

2) Проектное и процессное управление не являются заменой функционального управления или компенсацией функциональной некомпетентности.

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

Увлеченность проектами и процессами не должна перерастать в принижение значимости функциональной компетенции. У вас есть классные менеджеры проектов? Отлично! А работать кто будет?

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

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

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

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

Также плохая идея – менять организационную структуру, следуя за изменениями бизнес-процессов. Если компания достигла зрелости в процессном и/или проектном управлении, это позволяет ей реагировать на изменения во внешних условиях изменением процессов и проектов и таким образом избавиться от лихорадки реорганизаций.

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

Фото: pixabay.com

Эта публикация была размещена на предыдущей версии сайта и перенесена на нынешнюю версию. После переноса некоторые элементы публикации могут отражаться некорректно. Если вы заметили погрешности верстки, сообщите, пожалуйста, по адресу correct@e-xecutive.ru
Комментарии

Основное решение - формирование организационной культуры, направленной на достижение целей предприятия, самоорганизации и самоуправления.

Партнер, Москва
Статья хорошая, особенно, если сначала изучить первую часть ''Как разделение труда снижает производительность''. Автор статьи привел две причины увеличения энтропиии... хаоса в организации: 1. Появление нового энергичного топ-менеджера 2. Собственники решили передать управление наемному менеджменту. На мой взгляд, до момента, когда собственники решаться передать исполнительную власть наемному менеджменту... еще надо дожить в прямом и переносном смысле. Именно в это время организацию колбасит и трясет... бифуркация возрастает. В общем, давольно полно и четко, это описано у И. К. Адизеса, как переход от этапа ''Давай-Давай'' к этапу ''Юность'' (Зрелость). Если говорить о принципах построения, то на этапе Зрелость реализуется не просто функционально-процессная модель. Компания переходит на новый уровень эволюции, новый уровень реальности, - Организация реализует потоковую модель и превращается в ''Организацию-конвейер''
Профессор, Чебоксары

Ответ очевиден :-) - объединить их! Вопрос - как это сделать, на какой аналитической платформе?

Менеджер, Саратов

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

Чтобы понять откуда и зачем появляется процессное управление, нужно осознать простую эволюционную картинку развития любой системы. Итак, имеем зарождение системы - некое хаотическое образование, в которой то тут, то сям проявляются силовые возмущения. С течением времени эти силы (неважно каким образом и по каким причинам) группируются в единое ядро, и вокруг этого ядра начинает все централизоваться. Т.е. здесь мы уже имеем не хаос, но некую систему с центром в ядре. Но на следующем этапе, когда во вращательное движение вокруг ядра вовлекается слишком большое количество участников, ядро перестает справляться со своими ''обязанностями''. Оно не выдерживает нагрузки, и уже не может удержать всех - ядро, как и вся система начинает распадаться на части, каждая их которых стремиться ''отпочковаться'' и образовать новую систему. Если находится нечто, что укрепит ядро, то процесс вновь возвращается к предыдущему варианту работы. Если же этого не происходит, то система разваливается, возвращаясь к хаосу, но уже на новом уровне развития (с несколькими ядрами, каждый из которых может как превратиться в полноценное ядро, так и умереть-распасться)...

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

Проектное же управление - это следующий этап развития процессного. Т.е. мы определили некий набор БП, взаимодействия которых ведет к четкому результату. Обозвали этот набор ''проектом'', и теперь распространяем его в качестве решения на дивизионной (или какой иной) основе. Примером проектного управления являются крупные торговые сети.

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

Менеджер, Москва

Самое смешное заключается в том, что лично я не вижу большой разницы между перечисленными видами управления, поскольку:
а) Проект - это уникальный процесс (ИСО 9000:2005). Самому приходилось собирать разные проекты из отдельных работ-процессов. Каждый процесс регламентирован, но в проект они попадают в виде различных экземпляров и в разном составе.
б) В большинстве организаций руководитель отвечает и за рутинные/операционные процессы, и за проекты развития. Соответственно есть бюджеты операционные, и есть проектные.
в) Ручное управление - всегда было, есть и будет применяться в критической обстановке.
Так что, - не вижу противоречий между видами управления и необходимости искусственно разделять их. Это все равно, что спорить, какая часть машины главнее: Руль, Мотор или Колеса. :)))

Директор по развитию, Москва
Виктор Абруков пишет: Ответ очевиден :-) - объединить их!
Лучше интегрировать. ;) Сотрудники должны прекрасно понимать - где заканчивается одно и начинается другое. Хотя бы для того, что бы понимать преимущества каждого типа, и правильно ставить задачу перед руководителями. Ручное управление - его суть в сильной харизме управленца. Это управление, которое уникально как отпечаток пальца. Задача все же сделать его стандартом, так как с уникальностью всегда какие нибудь проблемы. То заболел, то в тюрьму посадили...
Партнер, Москва
Виталий Елиферов пишет: Так что, - не вижу противоречий между видами управления и необходимости искусственно разделять их. Это все равно, что спорить, какая часть машины главнее: Руль, Мотор или Колеса. :)))
Согласен с Виталеем, даже с той точки зрения, что проектный бизнес и бизнес-ковейер отличается. Строительство, проектирование и т.д. и т.п. чистый проектный бизнес, который состоит из процессов и, некоторые из них очень прописаны, и даже не персоналом, а проектно-сметной документацией, строительными нормами и правилами... внешними стейкхолдерами А вот сетевой бизнес в том числе продовольственный ритейл, построен на Теории потоков и, поэтому стоит различать, так как, в Теории потоков есть специфические смыслы, концепты, термины для проблем, на пример, затор. ТОС - построена на Теории потоков, хотя, конечно, сама Теория потоков богаче на смыслы и концепты. Правда есть и более сложные реальности бизнес-процессов и структур: 1. Организации, как целенаправленные социальные системы 2. Организации, как целеустремленные социальные системы
Менеджер, Москва
Юрий Родионов пишет: А вот сетевой бизнес в том числе продовольственный ритейл, построен на Теории потоков и, поэтому стоит различать, так как, в Теории потоков есть специфические смыслы, концепты, термины для проблем, на пример, затор. ТОС - построена на Теории потоков, хотя, конечно, сама Теория потоков богаче на смыслы и концепты.
Так построена операционная часть ритейла, а кроме нее существенный объем в работе ритейла занимают проекты открытия/закрытия торговых точек, маркетинговые и промо-акции, ввода новых категорий товаров и т.д. Так что и там приходится совмещать (плавали''c знаем :-)) )
Нач. отдела, зам. руководителя, Москва
Виталий Елиферов пишет: Так что, - не вижу противоречий между видами управления и необходимости искусственно разделять их. Это все равно, что спорить, какая часть машины главнее: Руль, Мотор или Колеса. :)))
Не понял, разве где-то в статье утверждается примат одного метода управления над другим (''руля'' над ''колесами'')?! Как раз наоборот - я обратил внимание на ограниченность многих консультантов как по проектному, так и по процессному управлению, для которых то или другое - данность, аксиома. Статья является попыткой дать более сбалансированную картину и показать применимость, плюсы и минусы всех подходов. Насколько попытка удачна - судить, конечно, читателям, но не надо приписывать автору того, чего он не говорил. Затем: что значит ''искусственно разделять''? Вообще-то любая наука - это именно ''искусственное разделение''. (Вспоминаем знаменитого ''сферического коня в вакууме''.) Разделять, чтобы анализировать - необходимо. Другое дело, что за анализом должен следовать синтез - умение пользоваться всем арсеналом подходов, не зацикливаясь на каком-то одном. Надеюсь, такой зацикленности в статье нет. Более того, я являюсь противником той точки зрения, что для процессного или проектного управления нужны какие-то свои менеджеры, отдельная структура управления. Это просто дополнительные аспекты, в которых должен разбираться любой грамотный менеджер. Другое дело, что крупной организации не помешает выделенный центр проектной и/или процессной компетенции - но именно компетенции, а не власти!
Директор по развитию, Москва
Анатолий Белайчук пишет: Другое дело, что крупной организации не помешает выделенный центр проектной и/или процессной компетенции - но именно компетенции, а не власти!
Согласен. А как это должно выглядеть на практике? Типа комитет/рабочая группа/команда проекта?
Оставлять комментарии могут только зарегистрированные пользователи
Статью прочитали
Обсуждение статей
Все комментарии
Дискуссии
Все дискуссии
HR-новости
Как управлять коллективом?

В Ижевске состоялась конференция «Региональная модель управления человеческими ресурсами».

Кто хочет знать зарплату коллег

Служба Исследований hh.ru выяснила, кто из соискателей знает размер зарплаты своих коллег.

Травмы на работе - угроза ВВП

Почти 3 миллиона человек в мире ежегодно умирают на своих рабочих местах.

Arena: анонимный поиск работы

Запущен сервис для анонимного поиска работы в сфере разработки.