• Часто в процессе описания уже возникает желание сделать какие-то улучшения, но при такой технологии – нельзя! Кстати, описание «как есть» вообще часто является фикцией, т. к. процессы в компании зачастую протекают по-разному (в зависимости от конкретного филиала, сотрудника, его настроения и т. д.).
• Проектирование новых процессов часто выполняют консультанты и/или руководители в «кабинетном режиме», без контакта с теми, кто в этих процессах реально участвует. А потом выясняется, что в предложенных улучшениях не учтено множество нюансов, и попытки «натянуть» идеал на реальную компанию приводят к провалу. Поскольку сотрудники компании не участвовали в проектировании новых процессов, то в ходе внедрения начинается их активное и пассивное сопротивление.
Описанный выше подход мы называем революционным
[388].
А при работе с клиентами используем другой – более мягкий и результативный – эволюционный.
1. Команда описывает процесс, отталкиваясь от того, как он протекает сегодня, но «с прицелом» на ближайшее будущее: как есть + ЗБР
[389]. То есть таким, каким он должен стать в течение ближайшего месяца-трех. В обсуждении процесса участвуют все связанные с ним руководители и ключевые сотрудники. По ходу они выдвигают предложения, которые, во-первых, хорошо обоснованы, а во-вторых, будут вызывать гораздо меньше сопротивления при внедрении.
2. Как только вы определили, кто архитектор процесса (или видения, оргструктуры и пр.), он становится ответственным за его описание и развитие, лидером рабочей группы. Таким образом:
• ответственность за внедрение остается в компании, а не на консультантах
[390];
• АП получает хорошую мотивацию: теперь он может проявить себя в полезном интересном деле, внести ценный вклад в бизнес, да еще и отладить стыки со смежниками (зачастую они входят в рабочую группу по процессу), решить застарелые конфликты;
• высшее руководство компании освобождается от основного объема работы по улучшению, оставляя за собой создание общей архитектуры компании и контроль ее развития.
3. Команда постепенно внедряет процесс.
• Сначала проводит несколько практических «прогонов», в ходе которых выявляются недочеты, не замеченные раньше. Так процессы оттачивают, доводят до ума.
Чем важнее изменение, тем более тщательно нужно его тестировать на практике, чтобы не наломать дров. Но и в идеализм улетать не сто́ит.
• Когда новый процесс показал хорошие результаты, руководство утверждает его. С этого момента начинается его внедрение во всей компании.
• Нужно проинформировать о новом порядке работы всех, кого это касается. Просто разослать обновленный процесс сотрудникам на почту или раздать под роспись – недостаточно: это фикция, а не внедрение.
Желательно провести краткие внедренческие тренинги
[391], на практике обучить людей работать в новом процессе. В одной компании, учредители которой – бывшие офицеры, это назвали учениями по аналогии с армией. Руководители сразу поняли, о чем идет речь, воодушевились и запланировали ближайшую тренировку для команды. Вот как важно говорить на понятном для людей языке!
После этого обычно проводят оценку того, насколько сотрудники готовы работать по-новому.
• После внедрения новшество становится обязательным к применению. Нужно контролировать, особенно в первое время, что работники действительно работают по-новому.
4. Изменение отражают в архитектурной библиотеке компании
[392].
5. Людям важно видеть успехи, гордиться ими. Почаще замечайте и обсуждайте с командой изменения и улучшения – у сотрудников (да и у вас) будет больше энтузиазма двигаться дальше.
Последовательное и разумное применение этого нехитрого алгоритма изменений творит чудеса.
Практическое задание 112
Какую стратегию изменений вы используете в своем бизнесе? Случалось ли вам и вашей команде устраивать «революцию» в компании? К чему это приводило? Есть ли живые примеры эволюционных изменений?
Потренируйтесь развивать бизнес эволюционно. Например, на одном из процессов, которые вы описывали при работе над третьей главой книги. Или на чем-то другом: главное, чтобы это было важно вам прямо сейчас. Тогда будет и вдохновение, и упорство, и результаты.
Дойдите до реального внедрения и устойчивых результатов.
Создайте и обкатайте свой алгоритм эволюционного управления изменениями: с учетом специфики вашего бизнеса и команды.
7.2. Управление архитектурой бизнеса
По мере того как вы формализуете свой бизнес, в нем образуется все больше документов. Более того, появляются различные версии. На каждый момент времени актуальна только одна, и все должны работать по ней. К тому же разные документы должны стыковаться друг с другом. Вскоре наступает момент, когда руководителям и сотрудникам сложно удерживать всю эту информацию в своих головах.
Помню, как в одной крупной нефтяной компании сотрудники насчитали 11 противоречивых документов за разные годы, описывающих одну и ту же сложную технологическую операцию. Все документы считались действующими.
Итак, документация разрастается. И это неудивительно: сам бизнес, как правило, тоже усложняется по мере роста и развития. Вы как команда глубже разбираетесь в том, как работаете (прежде делали это интуитивно), описываете свое понимание и договоренности.
Что же получается? Вы начали создавать систему, а получилась какая-то «бюрократия с кучей бумажек»? И да, и нет.
В моей практике некоторые сильные, харизматичные руководители компаний, задавшись однажды этим вопросом, бросали систематизацию бизнеса и оставляли все как есть. Но это тупик
[393].
Получается дилемма. С одной стороны, без формальных документов нельзя, это возврат к исходному бардаку. С другой – система лишает бизнес мобильности. Раньше руководитель принимал решение – и тут же оно воплощалось в жизнь. А теперь надо сначала все обдумать, согласовать, внести изменения в документацию. Для многих ярких лидеров – это как серпом по самому важному месту ☺.
