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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Контроль

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Фото: pixabay.com

Расскажите коллегам:
Эта публикация была размещена на предыдущей версии сайта и перенесена на нынешнюю версию. После переноса некоторые элементы публикации могут отражаться некорректно. Если вы заметили погрешности верстки, сообщите, пожалуйста, по адресу correct@e-xecutive.ru
Комментарии
Виталий Елиферов +4100 Виталий Елиферов Менеджер, Москва
Николай Лотох пишет: Непонятно. Вы увязали функциональную структуру и управление. Но это разные вещи. Управлять можно даже находясь вне официальной структуры
Да, совершенно верно! Например, ''позвоночное право'' в виде административного ресурса. Вообще, управляет тот, кто имеет права и полномочия на распределение и перераспределение ресурсов. Так что, вперед: ''От ''Процессного подхода'' к ''Ресурсному подходу к управлению'' (так и называется моя статья в профиле на ЛинкедИне).
Менеджер, Санкт-Петербург
Николай Лотох пишет: Вопрос опять упирается в терминологию. Вы что называете управлением?
То, что я называю управлением несколько шире формата настоящего форума: управление (control) несколько шире, чем управление (management) К сожалению, в этом смысле я кибернетик…
Николай Лотох пишет: Из Ваших примеров следует, что любая возможность давать указания, ставить цели (задачи) или осуществлять контроль для Вас означает управлять.
Применительно к этой и подобным дискуссиям я использую термин управление в контексте как постановка целей и предприятие действий по их достижению... Кстати, осуществлять контроль и осуществлять управление в ряде случаев полные синонимы… потерять контроль, т.е потерять управление []…
Николай Лотох пишет: Непонятно. Вы увязали функциональную структуру и управление. Но это разные вещи. Управлять можно даже находясь вне официальной структуры
Николай Официальная или реальная структура системы по Вашему это только функциональные структуры... Свою реальность я вам объяснил, в ней нет оргструктуры тождественной функциональной... В своих репликах я анализирую исключительно Вашу реальность, на основании приведенных Вами постов и приведенных Вами терминов их определений…
Николай Лотох Николай Лотох Консультант, Украина
Александр Воробьев пишет: То, что я называю управлением несколько шире формата настоящего форума: управление (control) несколько шире, чем управление (management)
Я не могу понять эту фразу
Николай Лотох Николай Лотох Консультант, Украина
Александр Воробьев пишет: я использую термин управление в контексте как постановка целей и предприятие действий по их достижению...
На мой взгляд, постановка целей может происходить вне управления. Т.е. цели подразделению ставятся вышестоящим руководителем до начала управления деятельностью подразделения. Только получив цель от своего начальника руководитель подразделения начинает управлять подразделением, чтобы достичь поставленную перед подразделением цель. Выработка и постановка целей может не относиться к собственно управленческой деятельности. Управление требуется для достижения поставленных сверху целей. Это упрощенно, чтобы мысль была ясна. Управление может быть направлено на внешнюю для подразделения цель. Что касается Ваших слов относительно действий по достижению цели. Очевидно, что, в основном, эти действия носят характер не управленческий, а исполнительный. Нужно специально оговаривать тот факт, что действия по достижению цели имеют минимум двоякий характер: - сами действия - управление ими
Анатолий Панин Анатолий Панин Нач. отдела, зам. руководителя, Москва
Виталий Елиферов пишет: 1. На стр. 42-43 этой книги НЕТ НИ ОДНОЙ цитаты, ни из Друкера, ни из кого либо еще. 2. Вы обвиняете авторов книги в некорректной цитате и искажении ''...смысла того, что пишет Питер Друкер.'', но точной цитаты и первоисточника - не приводите
Я написал Вам, что прочел книгу, а не две страницы из нее. Да и на этих страницах ничего не говорится об упомянутом мною там же ''Стратегическом управлении''. А цитату не привел из-за объема, да и не думал что у Вас будут с этой цитатой проблемы. Вы привели цитату из книги Питера Друкера ''Задачи менеджмента в XI веке'', глава II ''Единственно правильный тип организационной структуры''. Во введении к этой главе, Питер Друкер так описывает состояние сложившееся на тот момент: ''С самого своего начала (более чем столетие назад) и до сих пор изучение принципов организации опиралось на одно важное представление. Существует - или должен существовать - некий единственно правильный тип организационной структуры. Представление о ''единственно правильной организационной структуре'' неоднократно менялось, но ее поиски продолжаются по сей день''. Однако, рассматривая вопрос, Питер Друкер уже немного ниже пишет: ''Сегодня, наконец, стало ясно, что такого явления, как единственно правильная организационная структура не существует. Есть просто разные виды структур, каждый из которых имеет свои сильные и слабые стороны. Стало очевидным, что организационная структура - не самоцель. Это инструмент, с помощью которого можно повысить производительность совместного труда работников. В этом качестве любая организационная структура годится для решения определенных задач в определенных условиях и в определенное время''. Таким образом из некорректно приведенной вами цитаты Питера Друкера следует, что существует некий единственно правильный тип организационной структуры, а Питер Друкер говорит как раз об обратном.
Виталий Елиферов пишет: 3. Вы искажаете фамилию автора.
Да, действительно, случайно исказил Вашу фамилию. Приношу свои искренние извинения.
Виталий Елиферов пишет: Вы допускаете слишком много ошибок
Я допустил только одну ошибку в Вашей фамилии и еще раз приношу свои искренние извинения. Жду Ваших извинений за Ваше такое огульное заявление.
Николай Лотох Николай Лотох Консультант, Украина
Александр Воробьев пишет: Кстати, осуществлять контроль и осуществлять управление в ряде случаев полные синонимы… потерять контроль, т.е потерять управление
Из потери управления вследствие потери контроля не следует контроль= управлению. Если в последовательной цепи из 5 лампочек сгорела 1, а потухли все, то это не означает, что все лампы перегорели. Контроль - только один из важных, но не единственных этапов (звеньев, функций) в управлении. Контроль обеспечивает управленца информацией о происходящем. Но этим управление не исчерпывается
Менеджер, Санкт-Петербург
Николай Лотох пишет: Александр Воробьев пишет: То, что я называю управлением несколько шире формата настоящего форума: управление (control) несколько шире, чем управление (management) Я не могу понять эту фразу
КИБЕРНЕТИКА — (древнегреч. kybernetike (techne) ‘искусство управления’) отрасль знания, суть которого была сформулирована Винером как наука ‘о связи, управлении и контроле в машинах и живых организмах...’ в книге ‘Cybernetics: Or Control and Communication in the Animal and the Machine.... Management частный случай control...
Николай Лотох Николай Лотох Консультант, Украина
Александр Воробьев пишет: Официальная или реальная структура системы по Вашему это только функциональные структуры...
Не так. Структура не системы, а организации (предприятия). И не официальная, а орг структура и организационно- штатная. Что они отражают? Элементы - это либо функциональные подразделения (созданные как центры ответственности за некие функции). Либо вакансии (заполненные или нет) для сотрудников, которые тоже создаются под конкретные функции. И + связи между элементами. Поэтому я и написал, что орг структура предприятия, неважно в какой форме будет организована, все равно будет - функциональной структурой по своей сути Конечно, можно и другие структуры для организации придумать. Например, структуру связей в организации.
Николай Лотох Николай Лотох Консультант, Украина
Александр Воробьев пишет: То, что я называю управлением несколько шире формата настоящего форума: управление (control) несколько шире, чем управление (management) Я не могу понять эту фразу КИБЕРНЕТИКА — (древнегреч. kybernetike (techne) ‘искусство управления’) отрасль знания,
А как связаны определение кибернетики и предыдущая фраза об том, что управление ( ) шире управления ( )?
Менеджер, Санкт-Петербург
Николай Лотох пишет: Из потери управления вследствие потери контроля не следует контроль= управлению.
Вам виднее в каких случая контроль (control) =/= управление (control)
Николай Лотох пишет: Если в последовательной цепи из 5 лампочек сгорела 1, а потухли все, то это не означает, что все лампы перегорели.
Не означает, что контроль (control)? что управление (control) этой последовательной цепью, а запланированного результата все равно нет...
Оставлять комментарии могут только зарегистрированные пользователи
Статью прочитали
Обсуждение статей
Все комментарии
Дискуссии
Все дискуссии
HR-новости
Бюджет на кибербезопасность увеличила каждая вторая российская компания

По большей части организации тратились на программное обеспечение, обучение сотрудников и на обновление оборудования.

У 70% компаний есть корпоративные стандарты по дресс-коду

87% работодателей признались, что внешний вид кандидата оказывает влияние на объективность оценки его профессиональных навыков.

Компании стали чаще приглашать на работу несовершеннолетних

Работодатели стали на 28% активнее, чем в прошлом году, приглашать на работу подростков.

Россиянам для счастья стало нужно больше денег

На первом месте по зарплатным ожиданиям оказалась Москва, на втором – Владивосток.