ратегии, ориентированные на лидерство в затратах и масштабирование, требуют меньшей гибкости, чем стратегии, ориентированные на инновации.
В совокупности эти компоненты создают Agile-бизнес-систему. Правильное внедрение Agile – это умелое сочетание этих компонентов для устойчивого достижения целей компании, даже в изменчивых и непредсказуемых условиях. Измерение Agile требует разработки показателей в каждой области.
Мы понимаем, что это может показаться недостижимым. На самом деле речь идет всего лишь о способе организации, визуализации существующих вопросов и поиске их ответов, чтобы сделать каждую проблему управляемой. Чтобы улучшить результаты, вам надо понять, откуда они берутся, а затем улучшить процессы, которые их создают. Фокус в том, чтобы научиться анализировать динамические системы достаточно детально, чтобы узнавать инсайты, при этом ими не перегружаясь, – проще говоря, найти баланс и полагаться на минимально жизнеспособное решение.
Приведем пример. Один из наших розничных клиентов был в восторге от растущего числа Agile-команд в его организации и соответствующего ускорения роста выручки. Но анализ происходящего с учетом различных элементов выявил некоторые сюрпризы. Доходы (важный результат) увеличивались, потому что ускорялся рост отрасли. Но доля компании в этом росте (более важный результат) снижалась. Ее основные клиенты были лояльны, как и прежде, но компании не удавалось привлечь большой и быстрорастущий сегмент покупателей следующего поколения. Их не впечатляли традиционные формы маркетинга или мерчандайзинга. Они хотели быстрых и надежных онлайн-продаж. Клиенты желали, чтобы покупки в магазине были связаны не столько с брендированной продукцией, сколько с принятием советов о естественных формах ухода за кожей (промежуточные результаты). Была создана Agile-команда в цепочке поставок, но она скорее сосредоточилась на повышении эффективности работы традиционных складов, а не на аспектах стоимости и скорости онлайн-покупки через предложение с возможностью немедленного получения заказа в магазине (деятельность), более привлекательных для нового потребителя. Не было Agile-команд, сфокусированных на покупке правильных брендов, на разработке нужных дисплеев или обеспечении наилучшего опыта обслуживания (снова деятельность) для этого сегмента покупателей. Хуже того, в командах не было членов, которые представляли бы или хотя бы понимали потребности следующего поколения (входные данные). Как только эти причинно-следственные связи были выявлены, Agile-команды взялись за них, корректируя свою деятельность, цели, а также промежуточные и конечные результаты.
Используйте Agile-методы, чтобы определить нужный вам уровень Agile
Теперь вам должно быть ясно, почему заголовок главы «Какой уровень Agile вам нужен?» мы назвали вопросом с подвохом. В начале «пути» к Agile предсказать ответ почти невозможно. Прогнозирование, командование и контроль – это опасный подход к любым инновациям, но особенно к проектированию и разработке новой бизнес-системы. Как ни странно, руководители высшего звена, которые ожидают, что сотни или тысячи Agile команд будут следовать Agile принципам и практикам, иногда инстинктивно возвращаются к бюрократическим методам, чтобы придумать, разработать и внедрить новую систему. Есть старое изречение, приписываемое Альберту Эйнштейну, что проблемы нельзя решить, находясь на том же уровне мышления, который их создал. Тем не менее, именно так очень многие руководители подходят к Agile-трансформациям. Ошибки принимают разные формы.
• Вместо того чтобы продемонстрировать интеллектуальную скромность и признать, что руководящее видение – это рабочий прототип, который будет адаптироваться по мере накопления опыта, руководители пытаются максимизировать мотивацию к изменениям, притворяясь, что у них есть все ответы. Они навязывают негибкие организационные структуры. Они отрезают путь к отступлению, чтобы снять любые вопросы о приверженности.
• Вместо того чтобы признать людей, работающих на переднем плане, важными клиентами руководства – людьми, которые должны принимать участие в инновационном процессе и в конечном итоге заставить систему работать, – руководители строят планы за закрытыми дверями и раскрывают изменения через выпуск пресс-релизов.
• Вместо того чтобы считать обратную связь от опытных сотрудников ценной возможностью для улучшения, руководители рассматривают их мнение как критику со стороны сопротивляющихся переменам, которых следует исправить или уволить.
• Вместо того чтобы реагировать на изменения, отделы управления программами строят сложные диаграммы Ганта с яркими красными точками, помечая людей как нарушителей, которые отклоняются от планов.
Ценность приведенных выше показателей заключается в их способности фокусировать корректирующие действия на истинных ограничениях. Всегда есть хотя бы одно препятствие к дальнейшему прогрессу, но обычно их меньше, чем считает большинство людей. Концентрация на устранении проблем, которые не являются ограничениями, не повышает производительность и часто представляет собой пустую трату времени, денег и энергии. Вот почему спешка с реорганизацией всегда оказывается менее полезной, чем ожидают руководители. Обычно подобное решение скрывает другие проблемы, и в результате создается больше травм, чем ценности.
Как правило, реструктуризация – это всего лишь эвфемизм для массовых увольнений. Вы когда-нибудь задумывались, как и почему компании переходят от децентрализации к централизации и обратно, каждый раз объявляя об увольнениях для снижения затрат? Или почему они совершают другие виды движения «вперед-назад», например, переходят от функциональных организаций к продуктовым, затем к матричным и обратно? Как может каждое изменение вести к дальнейшему снижению затрат? Причина заключается в том, что команда руководства сначала устанавливает квоту затрат и только потом разрабатывает организационную структуру, чтобы уложиться в эту квоту, а операторам приходится разбираться с последствиями. Agile-переходы могут в конечном итоге привести к непрерывным структурным изменениям. Но организационные органы почти никогда не являются основным ограничением, и компаниям редко требуются немедленные массовые увольнения (или от них есть польза?).
Agile предлагает множество способов ускорить переход с получением большей ценности и меньшими затратами. Сосредоточьтесь на исправлении реальных узких мест. Заставьте руководителей вести себя как Agile-команда. Проясните общую цель. Этого недостаточно? Остановите деятельность, которую клиенты не хотят, а команды не в силах выполнять. Замените неэффективные инновационные группы Agile-командами. Все еще недостаточно? Разбейте планирование и бюджетирование на простые процессы с короткими интервалами. Сосредоточьте функции поддержки и контроля на изменении бизнес-процессов, чтобы лучше удовлетворять их внутренних клиентов. Если система остается несбалансированной, обеспечьте частое получение обратной связи по производительности. Если эти довольно простые решения сработают, вы сможете постоянно совершенствоваться, откладывая или избегая некоторых самых дорогих и болезненных решений.
Подобные рычаги изменений, по сути, становятся бэклогом Agile-команды руководства. Команда разрабатывает новую, высоко инновационную Agile-систему, и именно это в конечном итоге заставит все внутренние и внешние процессы работать. Как и любая другая Agile-команда, группа руководства определяет приоритеты, последовательность и согласует свои действия, чтобы создавать наибольшую ценность при наименьших затратах. Команды работают совместно как междисциплинарная группа, чтобы создавать систему, преодолевать препятствия и иметь возможность переориентироваться в случае получения непредвиденных результатов. Мы думаем об этом процессе как о квалифицированном инженере по микшированию музыки, отчасти художнике и отчасти ученом. Если высокие частоты слишком резкие, но их очень трудно изменить, вы справляетесь с ними, поднимая басовую партию. Не надо менять больше, чем нужно, так как это повлечет за собой другие проблемы, которые позднее потребуют решения и дополнительных затрат (Рис. 3–4; определения см. в Приложении В).
Все эти рычаги могут быть ценными, если их применять в правильной последовательности к соответствующим проблемам. В данной книге мы не можем подробно описать все возможности, но в Главах 4–8 обсудим, как использовать некоторые из популярных методов управления изменениями.
Почти за двадцать лет до появления Agile-манифеста молодой Марк Аллен самостоятельно пришел к провозглашенным в нем принципам и методам. У него была цель – выиграть чемпионат мира Ironman. Но для достижения этой цели ему надо было поразить движущуюся цель. Первый победитель Ironman в 1978 году завершил гонку с показателем времени 11:46:58. В феврале 1982 года, к которому Аллен готовился, пытаясь получить результаты ведущих конкурентов, победитель финишировал за 9:19:41, а спортсмен, занявший второе место, – за 9:36:57. Бенчмаркинг не только приводил к крайнему физическому и умственному истощению, но и ограничивал потенциал Аллена. Когда в 1989 году он выиграл свой первый чемпионат Ironman, то уложился в 8:09:14.[12] Это более чем на три с половиной часа быстрее, чем результаты пионеров триатлона. Аллен научился тренироваться, поддерживая тяжелый, но устойчивый темп. Он был терпелив и «играл вдолгую». По мере того как он тренировался в своем оптимальном темпе, его результаты продолжали улучшаться.[13]
Руководители высшего звена могли бы выбрать аналогии и похуже, чем представлять себя и свои организации триатлонистами на тренировках. Максимальная аэробная частота сердечных сокращений – это устойчивый темп изменений в организации. Вместо таких инструментов и методов, как силовые тренировки или улучшение питания, чтобы преодолеть плато (остановку в улучшении результатов), существуют модели поведения руководителей, культурные нормы, системы планирования и финансирования, организационные структуры, развитие персонала, бизнес-процессы и технологии. В следующих главах мы обсудим, как расставить приоритеты, упорядочить и реализовать эти способы.