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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Контроль

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Фото: pixabay.com

Расскажите коллегам:
Эта публикация была размещена на предыдущей версии сайта и перенесена на нынешнюю версию. После переноса некоторые элементы публикации могут отражаться некорректно. Если вы заметили погрешности верстки, сообщите, пожалуйста, по адресу correct@e-xecutive.ru
Комментарии
Нач. отдела, зам. руководителя, Москва
Михаил Кузнецов пишет: Согласен. А как это должно выглядеть на практике? Типа комитет/рабочая группа/команда проекта?
Да, как-то так. В литературе можно найти разные варианты, основные: 1) Комитет/рабочая группа, отвечающая за определенный процесс. Включает в себя владельца процесса, менеджера процесса (в общем случае это разные роли), руководителей подразделений-участников процесса. 2) Центр компетенции, являющийся ''библиотекарем'', держателем навыков и стандартов. Тоже скорее комитет, чем подразделение. Команда проекта - это несколько другое: временное формирование под конкретную задачу. Многое конечно зависит от масштаба организации. Умные книжки расписывают по-максимуму для ''больших'', организации поменьше могут обойтись более простыми структурами. Но при любом масштабе надо заботиться о том, чтобы процессная компетенция сохранялась и ее уровень не падал из-за того, что кто-то один уволился, например.
Анатолий Панин Анатолий Панин Нач. отдела, зам. руководителя, Москва
В любой компании есть организационная структура управления и бизнес-процессы. В любой компании есть вертикальные каналы управления, есть горизонтальные. В любой компании есть формальные каналы управления, есть неформальные. Бизнес-процессы можно разделять на проекты и процессы. Однако это разделение не принципиальное. Любой процесс также имеет свое начало и окончание. Последовательность проектов - это тоже процесс. Принципиальна организационная структура: проектная она в компании, или функциональная.
Юрий Родионов пишет: Правда есть и более сложные реальности бизнес-процессов и структур: 1. Организации, как целенаправленные социальные системы 2. Организации, как целеустремленные социальные системы
А это основной принципиальный вопрос, вопрос, на который автор не ответил по ветке предыдущей статьи - вопрос корпоративной культуры. В нашей компании после ее реорганизации проведенной с участием внешних консультантов, проекты и процессы стали частью корпоративной культуры компании. До этого они также было внедрено и ''процессное управление'', и ''проектное управление'', но большого прока от них не было. Постоянно все они, одновременно идущие, смешивались в одну кучу без правых и виноватых: ты дурак, сам дурак. А после их реорганизации в рамках корпоративной культуры все вошло в единое русло, пошло в нужном направлении. Эффект получили огромный.
. . . . Директор по развитию, Москва
Анатолий Белайчук пишет: Многое конечно зависит от масштаба организации. Умные книжки расписывают по-максимуму для ''больших'', организации поменьше могут обойтись более простыми структурами. Но при любом масштабе надо заботиться о том, чтобы процессная компетенция сохранялась и ее уровень не падал из-за того, что кто-то один уволился, например.
А не имеет ли смысл, в таком случае создать независимый процессинговый центр компетенций. На услуги которого мог бы подписаться любой желающий?
Researcher, Москва
Юрий Радионов пишет: Если говорить о принципах построения, то на этапе Зрелость реализуется не просто функционально-процессная модель. Компания переходит на новый уровень эволюции, новый уровень реальности, - Организация реализует потоковую модель и превращается в ''Организацию-конвейер''
Мне кажется что многие вопросы по статье связаны тем, что автор статьи не выделяет и не разделяет четко: 1. Организацию процесса производства. 2. Управление процессом производства. Особенно это важно при внедрении/запуске информационных технологий. У наших клиентов (Банки) сначала разрабатывается бизнес-процесс производства товара/услуги. И здесь во всю работает ''моделирование'', методологии проектирования . На что автор статьи снисходительно сказал, что оно не применяется. Затем выстраивается система управления бизнес-процессом. Мы используем здесь два уровня. Первый - информационное обеспечение оперативного уровня управления. Это либо он-лайн мониторинг некоторых показателей процессов, подпроцессов и работ бизнес-процесса, либо оперативные отчет по запросу. Второй - информационное обеспечение тактического уровня управления бизнес-процессами. Это аналитические отчеты... Как показывает практика этого достаточно для ''вписывания'' в любую систему правления ВСЕМ предприятием (Банком).
Нач. отдела, зам. руководителя, Москва
Михаил Кузнецов пишет: А не имеет ли смысл, в таком случае создать независимый процессинговый центр компетенций. На услуги которого мог бы подписаться любой желающий?
Вы же понимаете, что здесь нет и не может быть одного общего для всех рецепта. Мне лично больше по душе идея отдела бизнес-технологий, аналогичного департаментов банковских технологий. Вот почему в банках это практически стандарт, а ''реальный'' бизнес понимает необходимость технологий производства, а технологии управления у него в загоне? Впрочем часть ответа на этот вопрос я знаю: специфика банков в том, что у них продукт равняется процессу.
. . . . Директор по развитию, Москва
Анатолий Белайчук пишет: Вы же понимаете, что здесь нет и не может быть одного общего для всех рецепта.
Речь идет о единой методике. И способах ее распространения. А продукт, рецепт может быть разным в зависимости от целей компании. Отсутствие методологов в компании вот основная проблема. А бизнес аналитиков и мен по качеству - пруд пруди.
Владимир Токарев +15105 Владимир Токарев Генеральный директор, Нижний Новгород
Виноват, Анатолий, хотел сначала прочитать всю вторую часть (так как первая заинтриговала), но не получилось (споткнулся, как спотыкался в первой части), потому буду далее читать частями.
Анатолий Белайчук пишет: Иерархическая модель взаимоотношений склонна воспроизводить сама себя: генеральный поручает разобраться с проблемой директору по направлению, он своему заму, тот еще ниже, и в результате проблема падает на менеджера среднего уровня, у которого для ее решения нет ни необходимой компетенции, ни авторитета.
Мне представляется, что слово иерархия (и.м.) здесь лишнее - просто описан некачественный процесс делегирования. При чем тут иерархия?
Нач. отдела, зам. руководителя, Москва
Валерий Овсий пишет: Мне кажется что многие вопросы по статье связаны тем, что автор статьи не выделяет и не разделяет четко: 1. Организацию процесса производства. 2. Управление процессом производства.
Автору такое противопоставление представляется неоправданным. Управление процессом (только я бы предпочел говорить о бизнес-процессах - или вы настаиваете на производственных? Это несколько разные вещи.) в моем представлении - это цикл PDCA. Первый шаг которого ''Plan'' - это определение рамок процесса и его проектирование, а второй шаг ''Do'' - это внедрение и эксплуатация спроектированного процесса. Т.е. управление в моей терминологии включает организацию. Вы же, очевидно, под управлением понимаете не management, а control, т.е. только фазу Check цикла PDCA. На мой взгляд, для нее лучше было бы использовать термин ''контроль''. А Вы использовали термин ''управление'', и полный цикл управления Вам назвать нечем.
Нач. отдела, зам. руководителя, Москва
Михаил Кузнецов пишет: Речь идет о единой методике. И способах ее распространения.
Боюсь, это утопия. Смотрите: проектная ''библия'' называется PMBoK - ''Body of Knowledge'', свод знаний. Процессная - аналогично, CBOK. При этом подчеркивается, что это не ''how-to book'', а ''what-is book''. Нет и не будет единой, пригодной для всех организаций и ситуаций методики. Есть спектр методов, которые профессионал должен знать в теории и уметь применять на практике. В проектном управлении я не большой специалист, но что касается процессного управления, то эта область по охвату тянет на прикладную науку. Просить единую методику - это все равно, что просить единый метод решения дифференциальных уравнений. Не получится, увы.
Нач. отдела, зам. руководителя, Москва
Владимир Токарев пишет: Мне представляется, что слово иерархия (и.м.) здесь лишнее - просто описан некачественный процесс делегирования. При чем тут иерархия?
По мнению автора, иерархия имеет тенденцию порождать некачественное делегирование.
Оставлять комментарии могут только зарегистрированные пользователи
Статью прочитали
Обсуждение статей
Все комментарии
Дискуссии
Все дискуссии
HR-новости
Компании стали чаще привлекать сотрудников 45+, женщин и студентов после частичной мобилизации

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

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

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