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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Контроль

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Фото: pixabay.com

Расскажите коллегам:
Эта публикация была размещена на предыдущей версии сайта и перенесена на нынешнюю версию. После переноса некоторые элементы публикации могут отражаться некорректно. Если вы заметили погрешности верстки, сообщите, пожалуйста, по адресу correct@e-xecutive.ru
Комментарии
. . . . Директор по развитию, Москва
Анатолий Белайчук пишет: Просить единую методику - это все равно, что просить единый метод решения дифференциальных уравнений.
у кого просить?? Я все таки как то представляю это в форме СРО. Пусть даже отраслевые СРО.
Анатолий Белайчук пишет: Нет и не будет единой, пригодной для всех организаций и ситуаций методики.
Если вас приглашают в организацию поставить работу по созданию и усовершенствованию процессной модели или модели управления, Вы разве не используете единый подход, разработанный Вами и уже опробованный и зарекомендовавший себя? В этом случае тоже можно говорить о единой методике.
Виталий Елиферов +4100 Виталий Елиферов Менеджер, Москва
Анатолий Белайчук пишет: По мнению автора, иерархия имеет тенденцию порождать некачественное делегирование.
Не-а!!! ''ПЛОХАЯ иерархия порождает некачественное делегирование'' Продолжу аналогиями: ''ПЛОХОЕ моделирование - порождает отвращение к ''процессному подходу'' ''ПЛОХОЕ управление - порождает недоверие к ''верхним людям'' и неисполнение их указаний'' Где-то так! :-))
Нач. отдела, зам. руководителя, Москва
Михаил Кузнецов пишет: Если вас приглашают в организацию поставить работу по созданию и усовершенствованию процессной модели или модели управления, Вы разве не используете единый подход, разработанный Вами и уже опробованный и зарекомендовавший себя? В этом случае тоже можно говорить о единой методике.
Если я за такую работу возьмусь, то буду выбирать подход с учетом уровеня процессной зрелости организации, ее культуры, ценностей, стратегии, а также масштаба и отрасли.
Виталий Елиферов +4100 Виталий Елиферов Менеджер, Москва
Михаил Кузнецов пишет: у кого просить?? Я все таки как то представляю это в форме СРО. Пусть даже отраслевые СРО.
Пока мне известен только один удачный пример ''отраслевого СРО'' - модель еТОМ в Телекомах. Других примеров я не знаю. Отраслевые модели APQC (а их более 15) плохи.
Владимир Токарев +15105 Владимир Токарев Генеральный директор, Нижний Новгород
Анатолий Белайчук пишет: По мнению автора, иерархия имеет тенденцию порождать некачественное делегирование
Согласен, что может быть несколько мнений по одному вопросу. Мое мнение ближе к точке зрения Виталия Елиферова.
Анатолий Белайчук пишет: На сегодняшний день существует всего два подхода к решению кросс-функциональных проблем
Мне представляется, что есть еще, возможно, несколько. Третий - внутренний маркетинг - http://www.e-xecutive.ru/community/articles/1501752/index.php?ID=1501752
. . . . Директор по развитию, Москва
Анатолий Белайчук пишет: Если я за такую работу возьмусь, то буду выбирать подход с учетом уровеня процессной зрелости организации, ее культуры, ценностей, стратегии, а также масштаба и отрасли.
Кто бы сомневался. Но это и есть внешний центр компетенций. Компетенции именно в области процессного моделирования. Ваш подход не противоречит идеологии СРО.
. . . . Директор по развитию, Москва
Владимир Токарев пишет: Мне представляется, что есть еще, возможно, несколько. Третий - внутренний маркетинг - http://www.e-
Вам же уже памятник поставили. Если мало - вот еще один...
Анатолий Панин Анатолий Панин Нач. отдела, зам. руководителя, Москва

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

Возникали две проблемы:

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

Других проблем никогда не было. Эти проблемы правда ранее решили, но вдруг... Или Ваше решение будет лучше.

Хотелось бы узнать у автора его решение.

Researcher, Москва
Анатолий Белайчук пишет: Управление процессом (только я бы предпочел говорить о бизнес-процессах - или вы настаиваете на производственных?
Вы меня совсем запутали. Что по вашему физически означает термин ''бизнес процессы''? Это некоторый рисунок на бумаге? Или нечто закодированное в программной системе и никак не связано с реальным производственным процессом? Производственный процесс (?), например, изготовить гайку, в бизнес-процессе (?) выпуска авто?? Я конечно с производством авто не знаком, но мне как то чудно независимое существование чего-то что называется ''бизнес-процесс'' и чего-то что реально в ''металле '' производит продукцию... ?? У нас (у наших клиентов) термин бизнес-процесс это реальное производство банковских услуг клиентам банка. Когда клиент банка приходит в банк за кредитом, то операционист запускает экземпляр бизнес-процесса в BPMEngine - машине исполняющей этот экземпляр бизнес-процесса. Машина в свою очередь вызывает ''сервисы'' для исполнения. Например ввод данных клента и т.д. Т.е. бизнес-процесс это не рисунок, а набор реальных человеко-машинных сервисов, обслуживания клиентов банка под управлением BPMEngine. Неужто производство и продажа банковских услуг организационно сильно отличается других производств?
Нач. отдела, зам. руководителя, Москва
Анатолий Панин пишет: на практике у нас ни разу не возникало вопроса: ''Как выбрать между ручным, проектным и процессным управлением''. Практически всегда применяем все три, включая ручное, когда стоимость всей кухни вокруг какой либо небольшой работы соизмерима с трудозатратами на саму работу.
Мое мнение по этому вопросу полностью совпадает с Вашим. Недоразумение возникает из-за неудачного названия, в котором есть намек на противопоставление. В самом тексте, надеюсь, противопоставления нет.
Анатолий Панин пишет: 1. Что делать когда все параллельные проекты и процессы по независящим ни от кого обстоятельствам накладываются друг на друга, и превращаются в большую кучу, когда генеральному приходится решать все в ручном режиме, порою просто ''глядя на потолок''.
Меня эта проблема тоже интересует, и в четвертой части я планирую до нее добраться.
Оставлять комментарии могут только зарегистрированные пользователи
Статью прочитали
Обсуждение статей
Все комментарии
Дискуссии
Все дискуссии
HR-новости
Компании стали чаще привлекать сотрудников 45+, женщин и студентов после частичной мобилизации

Однако большого всплеска запросов от этих категорий не наблюдается – только 30% стали активнее искать работу. 

Россияне назвали топ-3 родительских навыка, больше всего востребованных в работе

Ими стали: взаимопонимание, терпение и обучающие навыки.