Когда я только начинала проводить стратегические сессии, естественным казалось желание найти хороший сценарий: понятную последовательность шагов, проверенные методы, логику, которую можно один раз выстроить, а потом адаптировать под разные компании.
С опытом сценариев становилось всё больше. Появлялись программы годового стратегического планирования, работы с видением, стратегическими целями, продуктами, клиентами, конкурентными преимуществами, проблемами, эффективностью.
Некоторые программы действительно повторялись. Какие-то инструменты становились любимыми и надёжными. Но постепенно я увидела парадокс.
Чем больше у меня становилось готовых программ, тем меньше хотелось брать одну из них за основу нового проекта.
Причина была не в том, что старые сценарии перестали работать. Просто становилось всё очевиднее: две компании могут прийти с почти одинаковым запросом — и им понадобятся совершенно разные сессии.
Одинаковое название ещё ничего не говорит о программе
Возьмём самый распространённый запрос: «Нужно провести стратегическую сессию на следующий год».
На уровне названия задачи всё выглядит одинаково. Но в одной компании:
-
собственники уже определили будущее бизнеса;
-
есть понятная стратегия;
-
управленческий учёт работает;
-
руководители умеют готовить аналитику;
-
прошлогодние цели регулярно контролировались.
Тогда сессия может быть достаточно компактной: подвести итоги, проверить изменения среды, пересмотреть приоритеты, актуализировать показатели и проекты.
В другой компании под тем же запросом обнаруживается совсем другая ситуация:
-
собственники по-разному представляют будущее;
-
достоверных данных по направлениям бизнеса недостаточно;
-
результаты прошлого года никто системно не анализировал;
-
руководители спорят не о решениях, а о фактах;
-
зоны ответственности размыты.
Формально тема та же — «стратегическая сессия на следующий год». Но если провести её по тому же сценарию, результат будет совсем другим. Поэтому со временем для меня главным вопросом стало
не: «Какой сценарий сюда подойдёт?»
а: «Какая работа необходима именно этой компании, чтобы принять нужные решения?»
Сценарий незаметно начинает управлять консультантом
У готового сценария есть большое преимущество: он снижает неопределённость.
Консультант знает последовательность этапов, понимает методы, может рассчитать время. Но в этом же его опасность. Когда программа уже есть, появляется соблазн смотреть на запрос через неё.
-
Если в сценарии предусмотрен SWOT-анализ — значит, попробуем встроить SWOT.
-
Есть блок видения — будем обсуждать видение.
-
Есть работа с миссией — найдём для неё место.
-
Есть несколько красивых групповых упражнений — жалко отказываться от них.
Постепенно происходит почти незаметная подмена: не программа собирается под задачу, а задача клиента подгоняется под программу. Для меня это стало одним из принципиальных профессиональных выводов.
Метод сам по себе не имеет ценности. Он нужен только в том случае, если помогает получить конкретный управленческий результат.
Один и тот же инструмент может быть нужен в одном проекте и совершенно лишним в другом
Например, работа с видением. Есть компании, где к нему необходимо возвращаться. Что является причиной:
-
У собственников изменились планы.
-
Компания вышла на новые рынки.
-
Появились новые продукты.
-
Произошло серьёзное изменение внешней среды.
Тогда пересмотр видения становится важнейшей частью стратегической работы.
Но если с компанией проводятся ежегодные сессии, и видение было содержательно пересмотрено недавно, нет никакой необходимости каждый раз заново проводить большой блок только потому, что «так положено по сценарию».
Мы возвращаемся к нему, проверяем актуальность и изменяем там, где действительно произошли существенные изменения. То же происходит практически с каждым инструментом.
BCG-анализ может оказаться чрезвычайно полезным, если нужно принимать решения по продуктовому портфелю. Но он совершенно не нужен компании, если её текущая задача находится в другой области.
Анализ бизнес-процессов может стать центральной частью проблемной сессии по повышению эффективности — и быть лишним в проекте, где собственники решают вопрос о будущем бизнеса.
Профессионализм консультанта проявляется не только в том, что он умеет включить в программу. Не менее важно понимать, что в неё включать не нужно.
Программа начинает собираться ещё до сессии
Когда я говорю о Конструкторе стратегических сессий, иногда возникает ассоциация с набором готовых модулей: берём блок А, добавляем блок Б, затем блок В — программа готова.
На практике всё сложнее. Конструирование начинается с диагностики.
-
Мы уточняем запрос.
-
Определяем уровень решений.
-
Понимаем, кто должен участвовать.
-
Изучаем уже существующую аналитику.
-
Формируем задания докладчикам.
И на этом этапе программа начинает меняться.
Предположим, первоначально я планировала посвятить несколько часов анализу клиентской базы непосредственно на сессии. Но в ходе подготовки руководитель коммерческого направления делает качественный аналитический доклад: сегментирует клиентов, показывает динамику, прибыльность, причины потерь, потенциал отдельных групп. Часть вопросов уже получила ответы.
Зачем теперь заставлять всю команду повторять этот анализ в зале? Освободившееся время можно направить на принятие решений.
Бывает и наоборот. При подготовке выясняется проблема, которой первоначально вообще не было в программе. Но без её решения двигаться дальше невозможно. Тогда приходится менять архитектуру сессии.
Именно поэтому окончательная программа появляется в процессе подготовки проекта, а не в момент подписания договора.
Я стала различать ядро программы и всё остальное
Постепенно в моей практике появилась ещё одна конструктивная идея. В программе есть то, без чего невозможно получить необходимый результат.
Это обязательные блоки.
Есть вопросы, которые полезно проработать, если позволяет время и качество предыдущей работы. Это дополнительные блоки.
И есть темы или инструменты, которые можно держать в запасе на случай, если группа движется быстрее или по ходу обсуждения возникнет необходимость. Это резерв.
Такой подход оказался намного устойчивее попытки составить поминутный сценарий, который обязательно нужно выполнить от первого упражнения до последнего.
Потому что реальная группа не всегда работает точно по расчёту. Какой-то вопрос, на который отводили час, решается за двадцать минут. Другой внезапно вскрывает серьёзное противоречие и требует дополнительного времени.
Если консультант связан жёстким сценарием, он начинает защищать программу от группы. Если программа сконструирована вокруг результата, можно перераспределять время, не теряя логики проекта.
Конструктор — это не коллекция методов
Ещё один важный вывод появился уже при систематизации накопленной практики.
Можно собрать несколько десятков методов стратегической работы. Но это ещё не Конструктор. Конструктор начинается тогда, когда понятно, зачем и при каких условиях использовать каждый элемент.
Например:
-
какой вопрос он помогает решить;
-
какие данные должны быть подготовлены;
-
кто должен участвовать;
-
какой результат должен быть получен;
-
что необходимо сделать до групповой работы;
-
что должно произойти после неё;
-
с какими другими блоками этот элемент связан;
-
в каких ситуациях его лучше вообще не использовать.
То есть единицей Конструктора становится не упражнение. Ею становится управленческая задача и способ организации работы для её решения. Это значительно меняет взгляд на проектирование сессии.
Важна не последовательность методов, а логика решений
Допустим, компании необходимо определить стратегические приоритеты. Можно сразу собрать руководителей и предложить им сформулировать несколько направлений развития. Но на чём они будут основывать выбор?
Если нет предварительного анализа рынка, клиентов, продуктов, финансовых результатов и внутренних ограничений, приоритеты могут оказаться просто набором предпочтений участников. Значит, перед выбором должна появиться информационная основа.
Следующий вопрос: кто имеет право сделать выбор? Если он затрагивает будущее бизнеса, необходимо участие собственника.
После выбора приоритетов нужно понять, во что они превратятся:
-
цели?
-
показатели?
-
проекты?
-
изменения в структуре?
-
новые продукты?
Ответы на эти вопросы и формируют последовательность программы.
То есть логика выглядит не так: упражнение 1 → упражнение 2 → упражнение 3,
а скорее так: какое решение необходимо → какая информация для него нужна → кто его принимает → каким способом организовать обсуждение → во что решение должно превратиться после сессии.
Для меня именно это и стало основой Конструктора.
Иногда лучший элемент программы — тот, который проходит не в зале
Ещё один сдвиг произошёл, когда я перестала считать, что всё важное обязательно должно происходить во время общей встречи.
Некоторые вопросы значительно эффективнее решить заранее.
Например:
-
аналитические расчёты;
-
уточнение исходных данных;
-
индивидуальные позиции собственников;
-
предварительный анализ продуктового портфеля;
-
подготовку вариантов;
-
проработку вопросов, где необходима экспертная работа одного подразделения.
Тогда общая сессия используется для того, для чего она действительно особенно сильна: совместного осмысления информации и принятия решений, требующих участия нескольких людей.
Это кажется очевидным. Но как только перестаёшь считать двухдневную встречу центром всей работы, программа меняется очень сильно.
Один запрос — несколько возможных программ
Именно поэтому я сегодня спокойно отношусь к ситуации, когда два клиента приходят с одинаковой формулировкой, а получают совершенно разные проекты.
«Разработать стратегию».
-
У одной компании работа начнётся с собственников и будущего бизнеса.
-
У другой — с анализа продуктового портфеля.
-
У третьей выяснится, что стратегия уже существует, но не работает система реализации.
-
У четвёртой сначала придётся разобраться с управленческим учётом, потому что команда не располагает данными для стратегических решений.
Это не четыре варианта одного универсального сценария. Это четыре разных консультационных задачи.
Зачем тогда вообще нужны накопленные программы?
Возникает закономерный вопрос: если программу каждый раз нужно проектировать заново, зачем хранить прежние сценарии? Они чрезвычайно нужны. Но не как шаблоны для копирования. Каждая проведённая сессия становится источником профессионального опыта.
Из неё можно извлечь:
-
удачные блоки;
-
последовательности вопросов;
-
аналитические задания;
-
форматы групповой работы;
-
способы фиксации решений;
-
варианты итоговых документов;
-
понимание того, что не сработало и почему.
Со временем возникает большая профессиональная библиотека. Консультант уже не придумывает каждую программу с чистого листа. Но и не достаёт из папки сценарий «Стратегическая сессия №7». Он собирает новую конструкцию из проверенных элементов, соотнося каждый из них с реальной задачей.
Возможно, Конструктор появился именно потому, что готовых программ стало слишком много
Когда я начала систематизировать свой опыт для книг и обучения консультантов, стало особенно заметно: накопившиеся программы невозможно честно представить как набор рецептов.
В каждой слишком много контекста.
-
Почему именно эти участники?
-
Почему такой порядок?
-
Почему один инструмент занял три часа, а другой двадцать минут?
-
Почему в одной компании блок был обязательным, а в другой мы от него отказались?
За каждым сценарием стояли решения консультанта, которые в готовой программе уже не видны.
И мне стало важнее передать не сами программы, а способ их проектирования.
Не: «Сделайте так же».
А: «Поймите, почему здесь было сделано именно так — и решите, что необходимо вашему клиенту».
Наверное, именно здесь проходит переход от человека, умеющего хорошо проводить стратегические сессии, к консультанту, способному их проектировать.
Универсальным оказался не сценарий
В итоге я всё-таки нашла то, что можно переносить из проекта в проект. Но это оказался не универсальный сценарий.
Переносится профессиональная логика:
-
понять запрос;
-
провести диагностику;
-
уточнить задачу;
-
определить уровень решений и состав участников;
-
сформировать необходимую аналитическую основу;
-
выбрать обязательные блоки;
-
оставить дополнительные и резервные;
-
спроектировать способы принятия решений;
-
заранее определить, во что эти решения должны превратиться после сессии.
А дальше каждая программа получается своей.
Поэтому сегодня для меня Конструктор стратегических сессий — не сборник готовых сценариев.
Это способ мышления консультанта при проектировании работы.
И, пожалуй, чем больше у меня становится опыта, тем меньше мне нужен универсальный сценарий — и тем больше ценю способность каждый раз собрать программу именно под ту задачу, которую на самом деле решает бизнес.
