Некоторые недостатки проектов внедрения процессного подхода

2005 год, кажется была опубликована в Эксперте


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

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


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

1. Описание бизнес-процессов, существующих в организации «как есть»

2. Анализ полученной модели и разработка проекта «как должно быть»

3. Переход от «как есть» к «как должно быть»

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

В чем разница двух подходов? Для наглядности рассмотрим их в таблице:



Как работает мастер

Как работает мастер по схеме классического процессного подхода

Диагностика

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

Тщательное описание параметров объекта. Анализ полученной модели по отдельным элементам.

Разработка идеальной модели исследуемого объекта («как должно быть»)

Мастер имеет достаточно опыта, чтобы определить варианты «как должно быть» (если клиент не желает быть фриком, что возможно даже в бизнесе). Требуется лишь уточнить базовые универсальные модели с учетом специфики клиента, это не занимает много времени. От общего — к частному.

Анализ модели, выявивший большое количество «проблемных зон» позволит наметить пути устранения недостатков. Тщательно прорабатывается идеальное состояние каждого элемента системы.

Воплощение модели «как должно быть» в практической плоскости

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

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


Как работает мастер Как работает мастер по схеме классического процессного подхода

Диагностика Есть универсальные модели, определяющие нормативное состояние системы. Диагностика заключается в анализе отклонений от этих моделей без специального описания Тщательное описание параметров объекта. Анализ полученной модели по отдельным элементам.

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

Воплощение модели «как должно быть» в практической плоскости Мастер уверен в том, что базовая модель сработает и дает гарантию результата. Он не получит свой гонорар, пока не будет достигнут результат Мастер не дает никаких гарантий, хотя то, что каждый элемент будет оптимизирован — факт. Как поведет себя вся система (как будет выглядеть прическа) спрогнозировать не сможет никто. Тем не менее, работа сделана, клиент должен оплатить затраты сил и времени специалиста.

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

Давайте рассмотрим, что происходит на каждом этапе более подробно.

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

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

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

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

Самый веский аргумент против этапа описания модели «как есть» — теория управления изменениями. Есть известный автор в этой области — Джон Коттер. Один из основных принципов эффективных изменений, как он говорит, и с чем мы полностью согласны, — это получение быстрых первых результатов любого проекта. Этап описания не дает никаких позитивных ощутимых эффектов — это только подготовка к их получению в дальнейшем. Что думает персонал по этому поводу? — Как правило, следующее: «зачем писать, мы и так об этом знали, даже говорили начальству, что нужно сделать!» А еще люди просто устают о постоянных вопросов консультантов, неопределенности и от заданий, которые отрывают их от основной деятельности. Подкрепления их уверенности какими-либо эффектами для сотрудников на первом этапе не происходит — как ни печально.

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

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

Проблема, с которой сталкиваются «оптимизаторы» бизнес-процессов заключается еще и в том, что многие предложения улучшений часто натыкаются на какой-нибудь специфический фактор, который нельзя было заранее учесть при описании. В лучшем случае этот фактор обнаруживается на этапе разработки, в худшем — из-за него летит весь перечень мер по внедрению. Например, пару лет назад мы описали бизнес-процесс заключения договора на одном из предприятий. Модель выявила дублирование некоторых функций, многоразовое внесение реквизитов по договору в различные документы и базы данных и другие нестыковки. Была разработана модель «как должно быть», в которой функции были четко разделены между исполнителями, закреплена ответственность и полномочия. В результате, уже при внедрении модели «как должно быть» выяснилось, что существует еще один частичный (третий или четвертый) учет заключенных договоров во внутренней системе контроля выполнений заданий стратегического плана (исполнительская дисциплина), который требует соблюдения определенных процедур, идущих в противоречие с новым вариантом процесса. Разрабатывать модель «как должно быть» пришлось по новому кругу, причем теперь масштабы оптимизации значительно расширились, что утроило трудоемкость. Консультанты первый раз все сделали по правилам — описали ключевой бизнес-процесс в порядке хода работ, просто одно ответвление одного из выходов было забыто интервьюируемыми. Тем не менее, подобные детали, ускользающие из внимания, часто являются существенным препятствием. Это издержки метода «от частного к целому».

Необходимость структурирования и выделения процессов тем не менее существует. Как же подойти в реализации процессной теории на предприятии без больших издержек на внедрение и с гарантированным результатом?

Можно исправлять отдельные недостатки технологии внедрения, совершенствуя проекты, а можно подойти с другой стороны — «переосмыслить процесс», как говорил тот самый Хаммер.

Ответ кроется в примере про парикмахера, который приводился выше.

Пригласите мастера, а не консультанта.


…..



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