Реальная стратегия. Как планировать только то, что можно воплотить

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

Разумным образом пересматривайте планы масштабирования. Практика – лучший учитель. Например, может потребоваться сменить метод № 3 (экспоненциальный) на метод № 4 (каскадный), но это будет возможно только в случае, если вы с самого начала учли принцип постепенности. Следите за действенностью избранного вами метода масштабирования и по необходимости меняйте его. Ориентация на небольшие поэтапные достижения не только полезна для внедряемого решения. Этот подход сам по себе представляет собой обучающий процесс. В его ходе можно вносить корректировки в избранный вами метод. Исходя из текущей ситуации, можно ускоряться или замедляться. Но не торопите события. Каким бы тщательным ни было планирование, как бы глубоко ни прорабатывался проект, на этапе внедрения люди склонны терять выдержку и торопиться, ставя под угрозу конечные результаты. Этот риск особенно высок для сильно децентрализованных и неоднородных организаций, например компаний с большим числом направлений предпринимательской деятельности и обособленных подразделений. В подобных случаях масштабирование по методу № 1 («большой взрыв») обречено на неудачу.

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

6.3.3. Организуйте и используйте обратную связь

Итак, подытожим, что мы на данный момент сделали для воплощения стратегии. В ускорителе 2 были перечислены шаги, которые нужно предпринять в рамках создания MVP. В результате применения описанных в блоке 10 методов разработки мы получаем улучшенные и более технологичные версии MVP. Методы масштабирования, о которых шла речь в блоке 11, позволяют полноценно внедрять каждую усовершенствованную версию MVP.

Когда новый продукт или услуга доходит до всех потребителей и работников, возникает обратная связь, исключительно полезная для последующих доработок и итераций. Вот 10 рекомендаций по организации и использованию обратной связи[170].

1. Создавайте отдельные команды по разработке и по внедрению. У них разные задачи и побудительные факторы. Аналитика и проектирование не очень хорошо сочетаются с практической работой по внедрению. Многие менеджеры спрашивали меня, могут ли одни и те же люди заниматься и тем и другим. Мой ответ: таких от силы 15 %. Некоторые могут, но ни в коем случае не одновременно.

2. Команды должны быть небольшими. Пять – семь человек на разработку и столько же на внедрение. Как выразился Джефф Безос из Amazon, команды должны быть такими маленькими, чтобы их можно было накормить двумя пиццами.