?

Log in

No account? Create an account
Лабораторный журнал -- Day [entries|friends|calendar]
Anatoly Levenchuk

[ website | Лабораторный журнал ]
[ userinfo | livejournal userinfo ]
[ calendar | livejournal calendar ]

Функции против процессов в оргдизайне [09 Apr 2005|01:00pm]
Как выяснилось, мало кто знает про оригинальный трюк, который я использую при проектировании бизнес-процессов верхнего уровня в какой-либо организации. Известно, что обсуждать бизнес-процессы топы терпеть не переваривают, но вполне готовы до одурения обсуждать квадратики и кружочки оргструктуры. ОК, можно это использовать.

Нужно взять чей-нибудь квадратик-будущего-подразделения, затем потребовать применить к нему тесты на конфликт интересов. Часто при этом появляется уже не один, а пара квадратиков -- и нечто общее между ними (но рисую я это обычно не между, а под ними, продолжая под всеми соседними появляющимися в ходе обсуждений квадратиками), которое немедленно объявляется "базой данных" (удивительно, но люди дальше не задают вопросы, что это такое. "База данных" -- это и бизнес-план из 18 отдельных документов, и сведения о текущих ремонтах, и график продаж со сведениями о его исполнении. Любые данные. )

Ежели дело идет туго, то пытаемся уточнить название подразделения. Это обсуждается радостно и с энтузиазмом, а название оказывается в основном "функцией" и состоит из каких-то невнятных номинализаций. Копаем название, пытаясь выделить главный объект работы (часто оказывается, что это -- ведение какого-то раздела "базы данных") и основную операцию. Все, вот он, момент процессной истины: при обсуждении немедленно всплывают соседние подразделения, которые либо предоставляют свои данные через "базу данных", либо используют получающиеся данные для контроля или дальнейших операций. Попугивая конфликтами интересов между "принятием решений" и "контроллингом" (чтобы добиться расщепления "функций" на отдельные осмысленные операции) смело расщепляем квадратики, оставляя их нарисованными над одной общей "базой данных" и снабжая входящими-выходящими стрелками с продуктами.

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

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

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

Ну, а ежели идти "в лоб" -- то есть а) требовать от топов нарисовать их бизнес-процессы, б) откладывать рисование оргструктуры на "после прорисовски бизнес-процессов", в) долго и тщательно объяснять, как перейти от функциональной метафоры к метафоре бизнес-процессов -- то это гарантированный неуспех проекта. Ибо обычно топы с интересом не обсуждают ничего, кроме своих табуреток, их количества, ресурсного их обеспечения, названий на табуретках. И только один какой-нибудь "директор по развитию" время от времени тоскливо вздыхает, что все руки не доходят в этой текучке до правильного подхода с бизнес-процессами -- но этот "директор по развитию" погоды обычно не делает. А в предлагаемом нами подходе процессного оргдизайна быстро выясняется, что оргсхема по факту находится у него в компьютере, а не в компьютере кадровика. И дальше дело идет еще быстрее...
8 comments|post comment

navigation
[ viewing | April 9th, 2005 ]
[ go | previous day|next day ]