В первой части мы констатировали, что разделение труда, приводя к росту производительности труда отдельного работника, одновременно порождает разобщенность между службами, которая влечет за собой снижение эффективности компании в целом.
Эти проблемы проявляются с ростом масштаба и возраста компании. Пока у руля основатели, пока размер исчисляется десятками сотрудников, наличия взаимопонимания и мотивированности у менеджеров достаточно, чтобы потери на «трение» были минимальными. Затем, например, компания приглашает нового энергичного директора по продажам, который полностью переформатирует отдел продаж. Само по себе это может и хорошо, но былого взаимопонимания с директором по производству нет, и начинаются трения, которые выплескиваются в «поиски крайнего» на планерках у директора.
Или же собственник (он же до поры до времени генеральный) решает, что бизнес наконец-то крепко стоит на ногах, и он имеет право отойти от оперативного управления и отдаться любимому серфингу. И тут в компании начинается разгул феодальной вольницы.
Какие есть варианты действий у руководителя в ситуации начинающегося раздрая?
Несистемный ответ на вызов: ручное управление. Руководитель вникает в возникающие между службами конфликты, принимает волевые решения, добивается результата.
Проблемы: во-первых, это ненадолго. Невозможно постоянно жить в состоянии стресса, да и подчиненные приспосабливаются. Во-вторых, это работает только до определенного масштаба — если организация достаточно велика, во все вникать невозможно.
Тут обычно приходится ко двору идея управления по показателям. Разумеется, иметь объективную информацию о состоянии компании лучше, чем не иметь. Но вот, предположим, вы получили вожделенные данные, и, допустим, они вас не устроили — делать-то что?
Воспользуемся аналогией: водитель автомобиля смотрит на спидометр, и если он показывает не ту скорость, которая его устраивает, то у него есть педали — тормоз, газ. Показатели — это тот же спидометр, но где педали, на которые можно жать в управлении компанией?
Можно нажать на подчиненных, то есть делегировать проблему вниз по иерархии — заместителю или директору по направлению. Но это работает только если проблема находится внутри соответствующего департамента, кросс-функциональные проблемы таким способом не решаются: с какой стати, к примеру, директор по производству должен выполнять распоряжения коммерческого директора?
Причем выполнять распоряжения равного по рангу — это еще в лучшем случае. Иерархическая модель взаимоотношений склонна воспроизводить сама себя: генеральный поручает разобраться с проблемой директору по направлению, он своему заму, тот еще ниже, и в результате проблема падает на менеджера среднего уровня, у которого для ее решения нет ни необходимой компетенции, ни авторитета.
Проблема остается нерешенной или, на языке бюрократии, поручение — не выполненным. О, это вечная тема: «Необходимо повысить контроль исполнительской дисциплины!», «Нам срочно нужна компьютерная система контроля поручений!». Не то чтобы эти системы были бесполезны, просто не надо слишком многого от них ожидать — они не спасут там, где имеет место дисбаланс между ответственностью и полномочиями: на исполнителя возлагают ответственность, но не дают полномочий.
Фундаментальный порок систем контроля поручений в том, что они хорошо справляются с контролем исполнения поручений, но никак не касаются того, кто решение будет принимать, насколько оно окажется оперативным и качественным. А в кросс-функциональных проблемах (тех, которые возникают на стыке между подразделениями, как например, при выставлении коммерческого предложения в бизнесе «проектирование под заказ») именно это является самым сложным. Функциональное управление хорошо работает по «вертикали» иерархии и плохо — по «горизонтали».
Удивительно, но эта проблема была полностью осознана относительно недавно. Одним из первых, кто заговорил о ней во весь голос, был Гэри Раммлер, в 1991 году в соавторстве со своим партнером Аланом Брэки издавший книгу с говорящим названием «Как управлять белым полем на организационной диаграмме» («How to Manage the White Space on the Organization Chart»).
На сегодняшний день существует всего два подхода к решению кросс-функциональных проблем, которые можно назвать системными: 1) проектное управление, 2) процессное управление.
Начнем с первого. В чем суть проектного управления?
Фактически руководитель компании делегирует руководителю проекта самые главные свои полномочия — возможность принимать решения и требовать их исполнения, не считаясь с должностями и статусом. Это делегирование ограничено только рамками проекта и положениями, зафиксированными в уставе проекта.
Как это выглядит на практике? Один руководитель проекта, когда ему приходилось сталкиваться с саботажем со стороны исполнителя или руководителя подразделения, произносил одну и ту же фразу: «Вы сами сделаете то, что от вас требуется, или хотите, чтобы вас об этом попросил лично генеральный директор? Я могу это устроить». Работало замечательно.
На руководителя проекта, с одной стороны, возлагается вся ответственность за его успех, а с другой — ему даются чрезвычайные полномочия, «в мирной жизни» принадлежащие руководителю. Правильный баланс ответственности и полномочий — залог эффективности проектного управления.
Процессное же управление — это попытка еще больше систематизировать кросс-функциональную работу. Оно применимо там, где работа раз за разом выполняется по одному и тому же шаблону.
Идея процессного управления — сесть и договориться не по тому, как мы будем выполнять конкретный проект, а как мы будем выполнять этот и все последующие аналогичные проекты, раз и навсегда.
Ключевые критерии, отличающие процесс от проекта — повторяемость и предсказуемость. Если состав и последовательность работ уникальны, то это проект.
У процесса последовательность тоже может от раза к разу не совпадать — возможны варианты, условия, развилки, бизнес-правила. Важна предсказуемость: сколько бы ни было развилок, все они нам известны наперед, и известны условия, по которым процесс пойдет по той или другой траектории. Если это условие выполняется, мы имеем дело с процессом.
Для наглядности сведем различия между ручным, проектным и процессным управлением в таблицу:
|
| Ручное управление | Проектное управление | Процессное управление |
| Передача ответственности между подразделениями | Через служебные записки и распоряжения | Обеспечивает менеджер проекта | Автоматически в соответствии с утвержденной схемой процесса |
| Начальные затраты | Проектирование отсутствует, начальные затраты нулевые | Существенные затраты на инициацию проекта | Большие затраты на проектирование процесса |
| Текущие затраты | Большие затраты из-за использования критического ресурса - руководителя | Существенные затраты из-за использования дорогого ресурса – менеджера проекта | Минимальные затраты – все делается по шаблону |
| Предсказуемость | Результат слабо предсказуем, так как зависит от субъективных факторов | План-график, основанный на экспертной оценке исполнителей и менеджера проекта | Сквозной мониторинг, основанный на нормативах и статистике продолжительности задач и подпроцессов |
| Контроль | О фактическом состоянии дел можно судить только по докладам исполнителей | Контроль план-графика и фактических результатов работ ведется раздельно (в разных системах), соответствие не гарантировано | Отметка о выполнении задачи в рамках процесса невозможна без предоставления фактически полученных результатов, разрыв исключен |
Резюмируя, проектное и процессное управление — это два системных метода компенсации неизбежных издержек функционального управления: потери управляемости на стыках между службами, утраты концентрации на целях организации, субоптимизации и тому подобное.
Какие следствия вытекают из этого утверждения:
1) Эффект применения проектного и процессного управления тем больше, чем больше масштаб проблем, порождаемых чисто функциональным управлением. В свою очередь, масштаб кросс-функциональных проблем определяется следующими факторами:
- Глубина организационной иерархии. В чисто функциональной иерархии, если вам что-то нужно от соседнего подразделения, вы пишете служебную записку наверх, начальству, и она пересылается до нужного уровня. Например, если вам нужна помощь соседнего отдела — на уровень начальника департамента, если соседнего департамента — на уровень первого лица. Чем глубже иерархия, тем более извилистым получается путь, тем выше потери.
- Степень вовлеченности подразделений в совместную деятельность (горизонтальный охват бизнес-процесса). Заказчика не интересует внутренняя структура компании, качество с его точки зрения — это прийти и уйти довольным с минимальными потерями времени и нервов (качество продукции и цена, конечно, при этом подразумеваются). Значит, как минимум, в рамках выполнения заказа клиента должны слаженно отработать отдел продаж, логистика, финансы и производство (если есть). Но если в рамках бизнес-процесса продаж подразделениям приходится договариваться хочешь-не хочешь (иначе не будет ни заказов, ни компании), то работа с рекламациями, также требующая взаимодействия и взаимопонимания между несколькими подразделениями, часто оказывается «в загоне». Негативные последствия для бизнеса обычно не заставляют себя ждать.
- Разобщенность компании – географическая, языковая, культурная. Понятно, что территориально-распределенной компании сложнее выстраивать коммуникации. Но разделительные линии могут проходить и в рамках одного офиса. Например, «мы» – это инженеры, конструктора, производственники и «они» – финансисты, бухгалтеры и прочие маркетологи.
2) Проектное и процессное управление не являются заменой функционального управления или компенсацией функциональной некомпетентности.
Довольно часто на бизнес-процесс смотрят как на способ собрать надежно работающий механизм из людей-«винтиков». Схемы и текстовые описания процесса рассматриваются как способ уменьшить зависимость от «человеческого фактора» и снизить требования к квалификации исполнителей. Мол, надо дать людям исчерпывающие инструкции, и тогда… Но известно, что «толковому работнику инструкция не нужна, а бестолковому бесполезна» — это, конечно, крайняя точка зрения, но доля истины в ней есть.
Увлеченность проектами и процессами не должна перерастать в принижение значимости функциональной компетенции. У вас есть классные менеджеры проектов? Отлично! А работать кто будет?
Процессы и проекты надо задействовать не тогда, когда компании не хватает грамотных людей — эту проблему можно и нужно решать традиционными методами, в рамках функционального управления. Руководитель отдела обычно является также самым опытным и грамотным специалистом, и его важнейшая обязанность — следить за профессиональным ростом своих подчиненных.
Процессы и проекты незаменимы в другой ситуации: когда каждый сотрудник на своем месте компетентен, но проект или сквозной бизнес-процесс объективно настолько сложен и затрагивает столь многих исполнителей из разных подразделений, что координация совместной работы требует специальных усилий.
Вспомним с чего все началось: с разделения труда и компетенций. Функциональная структура была и остается способом накопления и повышения необходимых компании компетенций. По этой причине порочной является идея выстраивания организационной структуры в соответствии с процессами — это приведет к тому, что специалистов из одной области «растащат» по разным департаментам. В результате станет невозможно сопоставлять их профессиональный уровень, и этот уровень неизбежно упадет.
Подобное приходится наблюдать в организациях, в которых руководителям бизнес-направлений удается добиться выделения в свое прямое подчинение программистов, чтобы они занимались только проблемами этого подразделения. Через некоторое время после вывода программистов из подчинения руководителя ИТ-службы они «бронзовеют»: начинают считать себя незаменимыми, и одновременно их профессиональный уровень снижается из-за отсутствия шкалы оценки, которую могут дать только коллеги из той же профессии.
Также плохая идея – менять организационную структуру, следуя за изменениями бизнес-процессов. Если компания достигла зрелости в процессном и/или проектном управлении, это позволяет ей реагировать на изменения во внешних условиях изменением процессов и проектов и таким образом избавиться от лихорадки реорганизаций.
Разобравшись с методологической основой проектного и процессного управления, в следующей части мы рассмотрим технологии, помогающие их реализовать, а также поговорим о кейс-менеджменте – относительно новом подходе к организации совместных работ.
Фото: pixabay.com
Выбирайте ПРИБЫЛЬ!