Структурированное мышление: настоящее преимущество консультанта

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

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

Я видел, как люди столбенеют на встречах с клиентами. Не потому, что у них не было идей. Потому, что они не знали, с чего начать.

Обстановка знакомая. Сложная проблема, комната, полная руководителей, расплывчатый объём работ и ожидание ясности. Неструктурированная реакция: начать говорить и надеяться, что ответ появится сам. Иногда так и бывает. Чаще вы ходите кругами двадцать минут, и никто не уходит довольным.

Это практика разбивать неоднозначную проблему на части, разбирать каждую часть по порядку и собирать выводы обратно в рекомендацию.

Это не заполнение шаблона, которое выдают за анализ. Это не натягивание рамки на проблему, к которой она не подходит. Консультант, который применяет матрицу 2x2 к любой ситуации, подбирает шаблон, а не думает.

Вы развиваете несколько умений:

1. Видеть настоящую проблему, которая часто отличается от заявленной
2. Разбивать её на части, которые можно анализировать отдельно
3. Понимать, какая информация важна, а какая нет
4. Выстраивать связную аргументацию из найденного
5. Ясно излагать её, когда в комнате напряжение

Пока эти умения развиваются, фреймворки служат лесами. Если нужен более широкий набор инструментов, самые распространённые я разобрал в статье простые консалтинговые фреймворки с объяснениями.

Вопрос для формулирования задачи

Перед любым фреймворком задайте один вопрос. Какое решение нужно принять и какая информация могла бы его изменить?

Он делает для качества анализа больше любого структурного инструмента. Он заставляет определить, каким должен быть результат, и не даёт тщательно работать над вопросом, ответ на который никому не нужен. Много лет назад HBR привёл тот же довод в статье Are You Solving the Right Problem?: большая часть напрасных усилий начинается с плохо определённой проблемы.

В контексте SAP вопрос «какая модель развёртывания подходит этой организации» относится к решениям. Вопрос «что такое S/4HANA» относится к описаниям. Первому нужен анализ. Второму нужна документация. Понимание того, чем вы занимаетесь, определяет, как вы проведёте неделю.

MECE

MECE расшифровывается как Mutually Exclusive, Collectively Exhaustive, то есть «взаимоисключающие и в совокупности исчерпывающие». Когда вы разбиваете проблему на части, каждая часть должна быть отдельной (без пересечений), а вместе они должны покрывать всю проблему (без пробелов).

Пересекающиеся категории считаются дважды. Пробелы теряют важное. Аббревиатуру знает большинство консультантов. Строго применяют её единицы.

Честность обеспечивают два теста. Первый: мог бы элемент оказаться сразу в двух ветках? Тогда ветки пересекаются. Второй: если бы на каждую ветку был получен ответ, получил бы ответ и центральный вопрос? Если нет, есть пробел. Идеальный MECE встречается редко. Важно задавать эти два вопроса каждый раз.

Деревья проблем

В дереве проблем центральный вопрос стоит в корне, а подвопросы на ветвях. Каждую ветвь можно анализировать отдельно.

Возьмём вопрос «Почему этот go-live SAP превысил плановый бюджет на 40 %?» Первое разбиение может быть таким: изменения объёма, затраты на ресурсы, продление сроков и незапланированное устранение недостатков. Изменения объёма затем делятся на формальные запросы на изменение, неформальные дополнения и пробелы, обнаруженные поздно. Каждый лист можно измерить.

Деревья проблем окупаются в начале проекта, до того как вы провели хоть какой-то анализ. Они не дают потратить три недели на одну ветку, пока другая остаётся нетронутой.

Анализ от гипотезы

Вместо того чтобы собрать все данные и потом сделать вывод, вы начинаете с самого вероятного ответа и проверяете его. На этом подходе стратегические фирмы построили свою репутацию.

При ограниченном времени и сложной проблеме исчерпывающий анализ невозможен. Хорошая гипотеза подсказывает, на что смотреть в первую очередь. Если она подтверждается, ответ у вас есть. Если нет, данные, которые её опровергли, обычно указывают в полезном направлении.

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

Эту последовательность я бы передал новому консультанту перед его первой диагностикой. Заполните её, прежде чем открывать хоть одну электронную таблицу.

1. 01СформулироватьРешение одним предложением
2. 02РазложитьОт трёх до пяти вопросов по MECE
3. 03Выдвинуть гипотезуОдна строка на ветку
4. 04ОпровергнутьДанные, которые доказали бы вашу неправоту
5. 05ПроверитьВыводы по каждой ветке, с источниками
6. 06СинтезироватьСначала рекомендация, затем обоснование
7. 07Испытать на прочностьВозражения, на которые ответ готов до того, как их выскажут в комнате

Рекомендация, которая выдержит управляющий комитет

Шаг	Вопрос, на который нужно ответить	Результат	Кто утверждает
1. Сформулировать	Какое решение должен принять клиент и к какому сроку?	Одно предложение	Спонсор со стороны клиента
2. Разложить	Какие три-пять вопросов, если ответить на них вместе, закрывают это решение?	Дерево проблем первого уровня, проверенное на MECE	Руководитель проекта
3. Выдвинуть гипотезу	Какой, по моему нынешнему мнению, ответ и почему?	Гипотеза в одну строку на каждую ветку	Руководитель проекта
4. Опровергнуть	Какие данные показали бы, что каждая гипотеза неверна?	Список запрашиваемых данных, по приоритету	Владельцы данных клиента соглашаются их предоставить
5. Проверить	Что говорят данные?	Выводы по каждой ветке, с источниками	Владельцы веток в команде
6. Синтезировать	Что в итоге должен сделать клиент?	Сначала рекомендация, затем подтверждающие пункты	Руководитель проекта
7. Испытать на прочность	Кто в комнате не согласится и с чем?	Возражения и ответы, подготовленные заранее	Коллега, который не участвовал в работе

Седьмой шаг люди пропускают. Именно он решает, выдержит ли рекомендация управляющий комитет.

Один клиент SAP, крупная производственная группа, работал на сильно кастомизированном ландшафте ECC. Руководитель ИТ сказал прямо: «Нам нужно сократить операционные расходы, но мы не можем позволить себе что-либо сломать».

Инстинкт подсказывает начать перечислять идеи экономии. В итоге получаются длинный список, много нервных людей и ни одного приоритета.

Мы выстроили анализ затрат по трём ветвям: сопровождение приложений, инфраструктура и лицензирование. Затем добавили анализ пользовательского кода. Сколько модификаций реально использовалось? Больше половины не использовалось. Лишние интерфейсы, неиспользуемые пользовательские отчёты, дублирующие рабочие процессы.

Такая структура позволила указать на экономию, которая казалась безопасной: архивирование неиспользуемых пользовательских объектов и консолидацию сред разработки. Ясность снизила политическое трение и укрепила доверие. Без дерева это был бы список сокращений, под которым никто не хотел бы ставить подпись.

Тот же метод работает и на более расплывчатых заданиях. Один поставщик корпоративного ПО как-то попросил у нас «стратегию регионального запуска» для среднего сегмента рынка Саудовской Аравии. Мы разделили работу на спрос на рынке, конкурентную позицию и готовность партнёров. В готовности партнёров мы выяснили, что у их сети реселлеров мало опыта работы с SAP S/4HANA Cloud. Эта преграда остановила бы реализацию, каким бы привлекательным ни выглядел рынок, и структура выявила её до того, как они потратили бюджет кампании.

Фреймворки не изменились. Изменились две другие вещи.

Черновик теперь дёшев. Joule, ChatGPT и Claude построят дерево проблем или дерево гипотез за секунды. Младшие консультанты, которые раньше тратили вечер на первый набросок, теперь получают его за полминуты, а вечер тратят на то, чего модель не умеет: проверку, подходит ли структура к проблеме, поиск упущенного и оспаривание допущений в запросе.

Премия за суждение выросла. Когда каждый может сгенерировать MECE-разбиение, вопрос уже не в том, «разложили ли вы проблему». Вопрос в том, «заметили ли вы, что заявленная клиентом проблема на самом деле другая, и поймали ли вы допущение, которое модель приняла по умолчанию». У консультантов, которые выработали суждение на реальных проектах, сейчас больший отрыв, чем в 2024 году.

Так что навык сместился. Теперь вопрос не «умеете ли вы построить дерево проблем», а «можете ли вы понять, что набросанное ИИ дерево неверно, и исправить его в комнате с клиентом».

Если вы выясняете, что это значит для вашей карьеры, карьерные пути на SAPopedia описывают консалтинговые треки, а карьерный пакет ERPCV помогает показать такое суждение в резюме, а не просто перечислить фреймворки.

Старт с решения. У клиента или консультанта уже есть ответ до того, как проблема сформулирована. Анализ превращается в подтверждение.

Слишком много структуры. Некоторые простые проблемы заслуживают прямого ответа, а не MECE-декомпозиции. Знать, когда структура не нужна, так же важно, как знать, как её применять.

Декомпозиция на неподходящую глубину. Деревья, которые слишком рано уходят слишком глубоко, приводят к параличу. Деревья, которые остаются мелкими, дают рекомендации, на основе которых никто не может действовать. Подбирайте глубину под решение и доступное время.

Анализ без синтеза. Строгое дерево, которое заканчивается свалкой данных. Структура помогает думать. Рекомендацию рождает суждение.

Путаница между структурой коммуникации и структурой мышления. Подача с вывода вперёд, как в принципе пирамиды Барбары Минто, это приём коммуникации. Он ничего не говорит о том, насколько здравым было мышление под ним. Хорошо поданный плохой анализ остаётся плохим анализом.

Это навык, а не врождённое качество. Он приходит с практикой.

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

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

Что такое структурированное мышление в консалтинге?

Это разбиение сложной, неоднозначной проблемы на части, последовательная проработка каждой части и объединение выводов в ясную рекомендацию. Оно делает трудные проблемы посильными и делает рассуждение видимым, так что клиент может следить за ним и оспаривать его, а не принимать вывод на веру.

Главные инструменты: вопрос для формулирования задачи, деревья проблем, MECE и анализ от гипотезы. Ни один из них не заменяет суждение.

Что означает MECE и как это применяется?

Mutually Exclusive, Collectively Exhaustive: взаимоисключающие и в совокупности исчерпывающие части. Части разбиения не должны пересекаться, а вместе они должны покрывать всю проблему.

Проверка на пересечения: мог бы элемент оказаться в двух ветках? Проверка на пробелы: если бы на каждую ветку был получен ответ, получил бы ответ и центральный вопрос? Применяйте это при построении дерева проблем. Применять к готовому анализу обычно поздно.

Как работает анализ от гипотезы?

Вы рано формулируете самый вероятный ответ, перечисляете данные, которые подтвердили бы его или опровергли, и затем проверяете. Это быстрее, чем сначала собирать всё подряд, потому что гипотеза подсказывает, где искать.

Риск здесь в предвзятости подтверждения. Сначала ищите данные, которые могли бы доказать вашу неправоту.

Как правильно сформулировать консалтинговую проблему?

Спросите, какое решение нужно принять и какая информация могла бы его изменить. Затем проверьте формулировку проблемы клиентом, прежде чем принимать её.

Клиент, который спрашивает «какой модуль SAP внедрять первым?», возможно, на самом деле решает «стоит ли вообще сейчас запускать программу SAP?». Если ответить на заданный вопрос, не проверив постановку, получится анализ, технически верный и коммерчески неверный.

В чём разница между анализом и синтезом в консалтинге?

Анализ разбивает проблему или набор данных на части, чтобы их понять. Синтез объединяет выводы в рекомендацию.

Самая частая беда с результатом работы: много анализа и никакого синтеза. Клиент получает стопку выводов, но не получает ответа на вопрос, ради которого вас наняли. Если сначала написать заключение, синтез придётся сделать.

Как структурированное мышление применяется во внедрениях ERP?

В начале программы оно не даёт командам приступать к настройке, пока не понята настоящая проблема. Организации, которая говорит «нам нужен SAP», может сначала понадобиться исправить процесс или проблему с данными, которые SAP только сделает заметнее.

В работе по fit-gap MECE-разбиение бизнес-процессов гарантирует, что учтён каждый процесс, а не только те, что всплыли на воркшопах. После проблемного go-live формулировка решения (стабилизировать, восстановить или заменить) и проверка гипотезы об основной причине быстрее приводят к обоснованной рекомендации, чем перечисление симптомов.