Фреймворки для решения кейсов
В этой, восемнадцатой статье из серии «Менеджмент цифрового мира» (оглавление) я буду рассказывать о фреймворках масштабирования Agile на большие подразделения или компанию в целом. Эту тему я уже начал в прошлой статье «Kanban и Lean - эволюция вместо революции»: Kanban также позволяет оркестровать работу в рамках компании, но он нем я здесь говорить больше не буду.
Отмечу, что ячейкой организации в любом случае является автономная самоорганизующаяся Agile-команда, поэтому совместимость способов управления с Agile-культурой является принципиальным требованием. Опыт показывает, что многие подходы менеджмента, основанные на уважении авторитета руководителя, полагаемого безусловным, или следовании за непогрешимым лидером не выдерживают столкновения с Agile-культурой: сотрудники могут просто уйти целой командой. И если руководство привыкло к такому стилю управления, то в Agile нет никакого смысла. С другой стороны, как я говорил в статьях «Три вызова цифрового мира» и «Цифровой мир: от физического труда — к умственному» методы регулярного менеджмента в цифровом мире перестают работать, а Agile-методы являются одной из работающих альтернатив, что подробно рассмотрено в статье «Agile – ответ IT на вызовы цифрового мира».
Фреймворки имеют разную сложность и рассчитаны на компании или подразделения разного размера. При этом большинство из них рассчитано на короткие цепочки создания ценности, когда одна кроссфункциональная команда делает продукт, поставляемый потребителям. Как я писал в статье «Место Agile-команд в компании», в условиях неопределенности и быстрого изменения условий работы компании в VUCA-мире короткие цепочки являются естественным способом организации труда, способным быстро реагировать на изменения, в отличие от стабильных условий функционирования, которые ведут к специализации и образованию длинных цепочек из функциональных подразделений.
Большинство фреймворков, о которых я буду говорить, ориентированы на обеспечение только основной операционной работы компании. Однако, следует учитывать, что границы ответственности команд могут быть существенно различны. Достаточно распространенной является практика, когда в ответственность команд передается найм и увольнение сотрудников, их обучение, а также финансовая ответственность за создаваемый продукт, то есть команда становится независимым подразделением.
В других случаях HR остаются независимым подразделением, так же как бухгалтерия и юридическая служба, и тогда их работа может быть организована как сервисная инфраструктура для команд, работающая по Kanban или одним из гибридных Agile-методов. Сохранение традиционной организации тоже возможно, однако, важно обеспечить хорошее качество сервиса и не служить препятствием для движения команд основного операционного контура.
И перед тем, как перейти к обзору фреймворков я хочу порекомендовать доклад Асхата Уразбаева «Фреймворки масштабирования Agile» на SECR-2017 со сравнением разных фреймворков.
Начну я с наиболее простого Scrum of Scrums, который появился раньше других. Он применяется в случае, если у вам в компании есть независимые Scrum-команды, каждая из которых делает свой продукт. Тогда для работы надо общими вопросами достаточно собрать команду Product Owner для обсуждения стратегии развития продуктов и координации усилий, и команду Scrum Master для обсуждения и координации вопросов организации. Если в командах есть Tech Lead, отвечающий за технологии и обучение им сотрудников, то добавляется еще координирующая команда из них.
Однако, бывают ситуации, когда одна команда не может обеспечить развитие продукта в требуемой темпе, ее мощности не хватает. Ведь размер команды ограничен, эффективно работает команда в 7-9 человек, а если их становится сильно больше, то необходимо дополнительное структурирование. Есть относительно простой способ нарастить команду до 15-20 человек, представленный на схеме. Это конструкция из мини-команд, каждая из которых состоит из опытного сотрудника и 1-2 стажеров, для которых опытный является наставником для стажеров. При этом операционные вопросы взаимодействия решаются командой из руководителей мини-команд.
Другой относительно простой способ – это собрать Integration Team из представителей отдельный команд, которая будет решать вопросы координации и зависимостей. Это предлагает Nexus и достаточно в случае, когда зависимости являются достаточно слабыми.
Более сложный фреймворк – Large Scaled Scrum (LeSS) (русское описание) – несколько команд на одном продукте с общим Product Owner, BackLog, спринтами, планированием, демо и поставкой, это позволяет объединить до 8 команд. У фреймворка есть huge вариант, применяемый для больших компаний и рассчитанный на работу 1000+ человек.
Ответственность команды не ограничивается выполнением основных производственных задач, она имеет много планов и фокусов, и логично, когда это реализуется через отдельные организационные структуры. Это мы видели на примере Scrum of Scrum, который организует две структуры управления – продуктовую и организационную, иногда дополняемую третьей, технологической. Более сложной конструкцией является Spotify фреймворк, который заслуживает отдельного рассмотрения.
Основной производственной единицей в ней является клан (tribe) в 100-200 человек, который работает над отдельным продуктом. Он представляет собой матрицу: делится на кроссфункциональные производственные отряды (squad) и функциональные отделы (chapter). Отряды реализуют новый функционал и состоят из специалистов разных специализаций, которые дополняют друг друга. А отделы координируют работы специалистов из разных команд, использующих общие технологии, решая такие задачи, как разработка мобильных интерфейсов в едином стиле, однородная работа серверной части или развитие технологий тестирования. Отметим, что отделы работают над применением технологий в рамках продукта, а вот для развития технологий в целом по компании существуют еще гильдии (guild) по интересам. По мере роста компании над кланами появились структуры следующего уровня – альянсы (alliance) и бизнес-единицы (business unit).
Конструкция – очень сложная и многоплановая и во многом обусловленная контекстом компании. Spotify ей делится, но с предостережением: «используйте наши опыт, но не пытайтесь тупо скопировать, оно не взлетит, мы это точно знаем, потому что у нас самих конструкция развивается и растет». Но много попыток именно механического копирования, обычно неудачных. А вот идеи заложены плодотворные.
При этом в самой компании Spotify организационная структура развивается очень быстро. И я хочу интересующимся порекомендовать доклад Yuliya Kurapatenkava на Saint TeamLeadConf-2018, в котором она рассказывала про логику развития (мой конспект есть в отчете с конференции, сам доклад по-английски). И вы можете сравнить то, что звучит в докладе с тем описанием фреймворка, которое доступно по ссылке в начале раздела и фиксирует состояние несколько лет ранее.
Здесь стоит рассмотреть практическое применение подобных фреймворков. Один продукт, над которым работают несколько команд, далеко не всегда означает единственный продукт в смысле софта, более того, часто речь идет об одном бизнес-продукте, поддержка которого со стороны софта требует общей серверной части и нескольких приложений на разных платформах – web и мобильных. Естественным образом для того, чтобы какой-то новый функционала стал доступен конечным пользователям, он часто должен быть реализован в серверной части и для каждой из платформ. И тут может быть два подхода: сделать команды, каждая из которых сосредоточенна вокруг каждого софтверного продукта, при этом только она работает с кодовой базой продукта и отвечает за его архитектуру. В этом случае для организации могут применяться фреймворки, подобные LeSS.
Однако, то что задача по реализации нового функционала делится на несколько, каждую из которых выполняет своя команда, сильно увеличивает количество необходимых синхронизаций и время разработки. Поэтому часто применяется и другой способ организации, кросс-функциональные команды, включающие специалистов по всем приложениям и делают все доработки для новой фичи. При этом возникает общее владение кодом, и надо дополнительно принимать меры для удержания целостности архитектуры каждого приложения, а также обучения и передачи опыта, потому что внутри команды такие специалисты не могут учиться. И это получается структура, похожая на клан в Spotify.
Так вот, в зависимости от потока задач и этапа развития компании предпочтительная структура может сильно изменяться. И сейчас IT-компании умеют достаточно быстро и успешно перестраивать свою структуру в зависимости от потребностей развития продукта. Я хочу сослаться на опыт компании ivi. На TeamLeadConf-2018 Евгений Россинский рассказывал, как они обеспечивали целостность продуктов и поддерживали знания разработчиков при переходе к кроссфункциональным командам от команд, собранных вокруг отдельных приложений. А через год TeamLeadConf-2019 он же рассказывал как за год они для решения задач реинжиниринга ядра продукта вернулись к командам, организованным по приложениям, провели реинжиниринг, а затем – снова перешли к кросс-функциональным командам, и все это - за один год, и продолжая мониторинг производительности, чтобы не допустить деградации.
Компания ivi предоставляет чистый цифровой продукт. Однако, похожая бизнес-структура сейчас характерна и для банков и для туроператоров, потому что их продукты сейчас все больше и больше перемещаются в цифровую сферу. Но, насколько я знаю, быстро пересобираться таким образом они еще не умеют, да и для IT опыт ivi является передовым. И, думаю, это может дать хорошее представление о том, какова она – динамично развивающаяся и перестраивающаяся современная цифровая компания, насоклько быстро она умеет изменяться.
Scaled Agile Framework (SAFe) является самым сложным Agile-фреймворком, но при этом – самым популярным. Это сложная конструкция уровня компании с управлением потоками создания ценности и архитектурой. На мой взгляд, популярность этого фреймворка сродни популярности PMBOK или RUP – в нем есть все и на все случаи жизни, и предлагается просто взять нужное. Те, кто читал мою статью «Развитие и провал регулярного менеджмента в IT» не удивятся моему мнению, что у это – неработоспособная конструкция, хотя и привлекательная в своем инженерном совершенстве. И он не будет работать по тем же самым причинам – его сложность превышает разумный предел, при этом обвинить сам фреймворк будет невозможно, всегда окажется, что это вы не смогли его правильно реализовать.
Но дело не только в сложности фреймворка: SAFe пытается за счет сложных регламентов превратить запутанную область в сложную, а это – невозможно (подробнее о сложности областей – в моей статье «Место Agile-команд в компании»). Однако, SAFe может быть полезен как теоретический источник, подобно PMBOK. Кстати, автором фреймворка является Дин Леффингуэлл (Dean Leffingwell), один из авторов RUP.
Довольно интересен фреймворк Enterprise Scrum предлагает переход от создания IT-продукта к поставке ценности, управляемой набором связанных метрик. К сожалению, в отличие от всего остального он не завершен. Его создатель Mike Beedle, кстати, один из авторов Agile-манифеста был, к сожалению убит в Чикаго весной 2018 года, и работа не завершена. Однако, на сайте есть достаточно подробная конструкция системы метрик, совместимая с Agile-методами управления, и, возможно, она вам окажется полезной при конструировании собственной, хотя в готовом виде ее, естественно, брать не стоит. Поэтому я и даю ссылку.
На этом я завершаю эту статью. Полное оглавление серии «Менеджмент цифрового мира» можно увидеть у меня на сайте. В следующей статье мы поговорим про кейсы Agile-трансформации. Продолжение следует…
На первом этапе кейс-интервью вы собираете информацию, на втором — обрабатываете и структурируете ее. Иногда упорядочить хаос сложно. Но сейчас мы расскажем, как превратить массив данных в четкие рабочие гипотезы, и покажем готовые фреймворки для решения бизнес-задач. Эту статью мы написали в рамках серии материалов под тегом «кейс-интервью», в которых разбираемся, как пройти этот этап отбора. Ищите другие публикации по теме, а ниже читайте о том, как обнаружить рабочие гипотезы и зачем для этого рисовать дерево.
Что делать, если я не понимаю, как решить проблему кейса?
Иногда можно впасть в ступор и застрять на этапе структурирования, но этого легко избежать, если использовать готовые подходы. Их еще называют фреймворками. Не факт, что любой кейс получится подогнать под существующий шаблон, но из тупика он вас точно вытащит. Рассказываем об основных готовых инструментах для решения кейса:
- Profitability Framework. Подойдет для кейсов на увеличение прибыли. Идея в том, что прибыль можно увеличить с помощью роста выручки на единицу продукта и количество проданных единиц либо через снижение издержек. Кандидату остается найти подходящее решение
- Business Situation Framework. Подойдет для кейсов о выходе на новый рынок, запуске продукта или изменении позиционирования. Кандидату нужно проанализировать четыре составляющие бизнеса: потребителя, саму компанию, ее продукт и конкурентов. На основе полученных данных будет легко найти источники роста.
- SPECIAL-T. Подойдет для стратегических кейсов. В основе фреймворка лежит мысль о том, что во внешней среде на компанию могут влиять восемь параметров: Suppliers (поставщики), Public (общество), Economy (экономика), Competitors (конкуренты), Industry (отрасль), Auditors (аудиторы), Legislation (законодательство) и Technologies (технологии). С помощью анализа этих параметров и нужно искать решение.
- Marketing Mix (или 5P). Подойдет для маркетинговых кейсов по решению любых проблем, связанных с продуктом. Шаблон предлагает формулировать гипотезу с помощью анализа 5P: продукта (product), упаковки (package), места (place), цены (price) и продвижения (promotion).
В статье мы перечислили базовые фреймворки и не углублялись в подробности. Если вам не хватает вводных, читайте наш учебник по решению кейсов. Там мы разбираем каждую букву в аббревиатуре фреймворков. Закрепить теорию лучше всего практикой. Для этого мы придумали Школу Changellenge >> — образовательный интенсив, который за 21 день подготовит вас к кейс-интервью и другим этапам отбора. Вместе с экспертами из Big3 вы будете составлять резюме, решать реальные бизнес-задачи и учиться тому, что остальные осваивают спустя годы практики.
1. What does MECE mean?
MECE (pronounced “mee-see”) is short for Mutually Exclusive, Collectively Exhaustive. MECE is a principle for breaking down items into small pieces. “Mutually exclusive” means no overlap between each piece, while “collectively exhaustive” means all the pieces combined form the original item without any gap.
“MECE framework” is a common misnonym – MECE itself is not a framework, but a principle for frameworks. When a problem-solving framework is MECE, its branches must not have any overlap while covering all possible root causes .
Получите карьерную поддержку
Если вы не знаете, с чего начать карьеру, зашли в тупик или считаете, что совершили какие-то ошибки, спросите совета у специалистов. Заполните заявку и консультанты Changellenge >> окажут вам помощь. Это отличный шанс вместе экспертом проработать проблемные вопросы и составить карьерный план.
Mutually Exclusive (ME) vs Collectively Exhaustive (CE) – Which is more important?
When mutual exclusivity (ME) is violated, Joe may over-analyze and duplicate effort in one area. People often think of this as a lack of efficiency .
When collective exhaustivity (CE) is violated, Joe on the other hand may completely miss out on an area. He may never solve the problem if the root-cause lies in the missing area. People often think of this as an effectiveness issue.
However, in many situations, each of ME and CE standing alone can also help with both efficiency and effectiveness. A non-ME analysis may also lead to non-CE. And a non-CE one can as well cause consultants to analyze over and over the same area without finding the root-cause -> inefficient.
This sounds cliche, but true nonetheless: both ME and CE are equally important.
Let's start with the basics: what are case interview frameworks?
Case interview frameworks are a method for approaching business problems using a defined structure. The structure of a framework allows the user to break down a problem into its fundamental pieces. There are 2 categories of frameworks: pre-existing frameworks, and custom bespoke frameworks.
In this guide, we'll cover both categories. Let's begin with pre-existing frameworks, which are established business frameworks. Some of them are pretty well known, so you may have heard of them before. Here are the top 7 pre-existing case interview frameworks:
The number one mistakes candidates make in case interviews is to learn frameworks by heart and to reuse them in interviews. Your interviewer will immediately notice if you do this and penalise you. Instead, you should create custom frameworks for all your cases. Trust us, it's actually not that hard! You can jump to the relevant sections below:
1. Profitability framework ↑
The profitability framework is the most basic framework in business analysis. It simply breaks down profits into its basic revenue and cost components and is commonly used to identify the root cause of profitability issues.
- Revenue can simply be broken down in the Number of units sold by the business times the Price per unit.
- Costs can be broken down in Variable and Fixed costs. And Variable costs can then in turn be broken down in the Number of units produced and the Cost per unit.
2. The 4Ps framework ↑
The 4Ps framework is widely used by company executives to design their marketing strategy. There are different variations of this framework that is also sometimes referred to as the “Marketing mix” framework but the 4Ps is the most common one. This framework is commonly used when launching a new product or when reviewing the positioning of an existing product.
3. Porter's 5 forces ↑
Porter’s 5 forces is a framework commonly used by CEOs to explore the competitive dynamics of industries. Indeed not all industries are structured the same way. Some industries are really hard to get into (E.g.: banking) while others have got very low barriers to entry (E.g.: newspapers). Suppliers have got strong bargaining power in some industries (E.g.: high-end medical equipment) but little power in others (E.g.: small milk producer), etc. Understanding these dynamics is extremely important when considering to enter a new industry or when assessing the competitive dynamics of the industry a company is already in.
- Customers’ bargaining power: How much bargaining power do customers have? If there is only one buyer but multiple suppliers then that buyer will be at a strong advantage. Key elements to consider here include: customer concentration (percentage of industry revenues from Top 3 buyers), customer price sensitivity, customer information availability, etc.
- Suppliers’ bargaining power: How much bargaining power do suppliers have? Similarly to the previous point, if there is only one supplier but multiple buyers then that supplier will be at a strong advantage. Key elements to consider include: concentration of suppliers (percentage of industry revenues to Top 3 suppliers), difficulty of switching from one supplier to another, differentiation between suppliers, etc.
- Threat of substitutes: What are the substitutes for the product and are they increasingly popular? As a reminder, water is a substitute for Coke while Pepsi is a competitive product for Coke. Key elements to consider here include: potential new substitutes, ease of substitution, evolution of customer propensity to substitute, etc.
- Threat of new entrants: How difficult is it to enter the industry for potential new players? Key elements to consider here include: regulation authorisations, capital requirements, economies of scale, network effects, etc.
- Existing rivals: How competitive are existing rivals in the industry? Key elements to consider include: number of competitors and their market shares, similarity between their products and products of the firm analysed, financial health of competitors, etc.
4. 3Cs framework ↑
The 3Cs framework is also commonly used to put together strategies for companies. As you will notice below, a lot of its components overlap with the Porter’s 5 forces.
- Customers: Who is the customer? Key elements to consider include: customer demographics (E.g.: age, sex, income, etc.), customer needs, customer segments size and growth rates, customer willingness to pay and price sensitivity, etc.
- Competition: What are the competitive dynamics? Key elements to consider include: competitors’ value proposition and brand, competitors’ market share and growth, competitors’ financial health, etc.
- Company: What defines the company? Key elements to consider include: product offering, profitability, core competencies, unique selling point, financial performance and resources, etc.
5. Market entry framework ↑
The market entry framework is commonly used to make decisions on whether a company should enter a new market or not. For instance, you could use it to decide if Startbucks should enter the Chinese market. Or if Nike should enter the sports broadcasting business.
- Market: What are the characteristics of the market we are trying to enter? Key elements to consider include: market size and profitability, products already available in the market, intensity of the competition, heaviness of the regulation etc.
- Client capabilities: Does the client have the right capabilities to enter that new market? Key elements to consider include: differences between the client's current market and the new one they are now targeting, number of times client has entered new markets and success achieved, other companies already in the new market, etc.
- Financials: Does it make financial sense to enter the new market? Key elements to consider include: current financial situation of the client, cost to enter new market, ongoing costs once market entered, expected revenues and return on investment, etc.
- Entry strategy: How should the client go about entering the new market? Key elements to consider include: timing of market entry (now vs. delay), speed of market entry (test region vs. whole country), opportunity to buy competitor or do a JV, management approach (control from HQ vs. decentralise), etc.
6. Pricing case framework ↑
Companies always face a difficult issue when launching a new product or service. What should its price be? The pricing framework is extremely helpful to help answer that question.
- Cost-based: What price do we need to set to cover all our costs? Key elements to consider include: fixed costs and their allocation across products, variable costs and number of units produced / sold, profitability targeted, etc.
- Value-based: How much are customers willing to pay for our product? Key elements to consider include: price of the next best alternative to our product, features that make our product better than the next best alternative, value of these features, etc.
- Competitor-based: What is the competition charging for similar products? Key elements to consider include: available substitute products from the competition, price of these substitute products, value of our product vs. substitutes, etc.
- Overall strategy: Given the elements above, what should our pricing strategy be? Key elements to consider include: objective of the pricing strategy (e.g. high profitability or high market share), opportunities for upsell / cross-sell that should be taken into account (e.g. Kindle and ebooks), possibility to sell different versions of the same product (e.g. iPhone 8, iPhone 8 Plus) etc.
7. Merger and acquisition framework ↑
Finally, the merger and acquisition framework is used when companies are looking to acquire or merge with competitors. These situations are not very frequent in a CEO's life but highly stressful which helps understand why consultants are often asked to support such initiatives.
- The market: What are the characteristics of the market in which the target evolves? Key elements to consider include: market size and growth, market profitability and intensity of the competition, market regulation, etc.
- The target: How attractive is the target to be acquired? Key elements to consider include: current and future financial position of the target, important assets or capabilities owned by the target, quality of the target's management team, target / buyer culture fit, etc.
- The buyer: What's driving the buyer to make the acquisition? Key elements to consider include: acquisition rationale (e.g. target undervalued, etc.), acquisition financing, buyer's acquisition experience, acquisition timing, etc.
- Synergies and risks: What are the acquisition synergies and risks? Key elements to consider include: value of individual and combined entities, cost synergies, revenue synergies, biggest risks of failure, etc.
Do not reuse pre-existing frameworks for case interviews ↑
Once you are familiar with frameworks, the question then becomes: how do you now use that knowledge in case interviews? There are a lot of opinions about how you should do this on the Internet. But the main two schools of thought seem to be: Marc Cosentino’s Case In Point and Victor Cheng’s LOMS .
In Case In Point, Marc Cosentino attempts to classify case interviews into 10+ categories and then suggests that candidates should learn a specific framework by heart for each of them. This is an interesting exercise as it exposes you to a range of business problems and helps you think about them in different ways. However, in our experience, learning 10+ frameworks is difficult and time consuming.
More importantly, in live case interviews, trying to recognise one of the 10+ case categories and the framework they are associated to is a real nightmare! Instead of focusing on solving the problem at hand, you end up trying to remember a framework that will not even perfectly fit the case you are solving. In our experience, the best candidates avoid this strategy.
In his LOMS programme, Victor Cheng advocates for a much simpler method than Case In Point and suggests you should only learn two frameworks: the profit framework for profitability cases, and a general framework for all other cases (Product, Consumer, Company, Competition). The benefit of this approach is its simplicity. It gives you a starting point that’s easy to remember when you are putting a framework together.
However, in our experience, this approach has got a fatal drawback. In practice, there aren’t that many profitability cases, and as a consequence you always end up using the general framework. Even if you adapt this general framework to the case you are given, it will not be perfectly tailored to the case you are trying to solve. More importantly perhaps, your interviewer will quickly realise that you are using a pre-cooked framework and that will reflect very negatively on you.
Both Case In Point and LOMS share the same flaw: they try to force pre-defined frameworks onto cases. In our experience, this is bound to produce average results because all cases are unique.
So here is the hard truth about case interview frameworks: the best candidates DO NOT learn frameworks by heart, instead they learn a consistent METHOD to craft bespoke frameworks for each case.
Learn to create your own unique frameworks ↑
A good framework is a bit like a tailor made suit: it is adapted to the problem you are trying to solve, the company, the industry and it is also as MECE as possible. If you use pre-defined frameworks, you run the risk of missing important elements of the specific problem you are trying to solve. This will therefore mean you perform less well than you could have if you had created a framework adapted to the specific problem from scratch.
In real life, consultants extremely rarely use pre-defined frameworks. They are familiar with them because they have studied them but they do not directly re-use them as-is on projects. Instead, they create a framework or issue tree specific to the problem they are working on. To do so they rely on conversations with their client as well as past experiences.
This might sound intimidating but the good news is that creating bespoke frameworks is actually much simpler than you think. It requires a few things:
- Changing your approach from adapting frameworks to creating them from scratch
- Learning a step-by-step method to create bespoke frameworks
- Practicing this step-by-step method on multiple examples
In our McKinsey Case Interview Prep Programme and BCG & Bain Case Interview Prep Programme, we teach a simple step-by-step method to create bespoke frameworks for each case. Candidates who have worked with us so far have managed to quickly learn this method and to perform at a high level in their interviews. If you would like to get a taste of this approach, you can watch the video extracts below or download our Free Case Prep materials here.
In summary, we find that learning existing frameworks is useful to discover a range of ways to think about a company. But in our experience, when it comes to consulting case prep, it is best to forget these pre-defined frameworks and focus instead on learning a step-by-step method to craft bespoke frameworks for each case.
If you’ve got any thoughts on frameworks or on this article, leave them in the comment section, we look forward to reading you.
Additional resources
If you would like to fast track your case interview preparation and maximise your chances of getting an offer at McKinsey, BCG or Bain, come and train with us. More than 80% of the candidates training with our programmes end up getting an offer at their target firm. We know this because we give half of their money back to people who don't.
Как создать структуру
Пирамида Минто
Решая проблему, большинство людей сначала собирает данные, а затем переходит к их анализу. Консультанты отличаются от простых смертных тем, что они в первую очередь строят гипотезы о путях решения проблемы, а потом анализируют их. В основе этого метода лежит принцип пирамиды, разработанный Барбарой Минто, первой женщиной-консультантом McKinsey. Ее идеи до сих пор используются и в консалтинге, и во многих других сферах.
Суть пирамиды проста — вы делите проблему на части. Верхушка — это основной вопрос. Дальше — ряд идей, которые не пересекаются, но, дополняя друг друга, создают весь возможный спектр решений поставленного вопроса. На следующем уровне вы детализируете каждую идею, находите аргументы, и так до самого конца, пока разбивка не приведет вас к конкретным решениям. Рассмотрим упрощенный пример пирамиды Минто. Допустим, главная проблема компании — это падение прибыли. Причина может крыться либо в снижении доходов, либо в росте расходов. Доходы могли упасть из-за изменения цены или объема продаж. Проанализировав каждый фактор, который в конечном итоге влияет на прибыль, компания сможет определить, что именно вызвало ее падение, и решить проблему.
Чтобы качественно структурировать проблему и быть уверенными, что вы ничего не забыли, следуйте правилу MECE: элементы пирамиды должны быть взаимоисключающими (не дублируют друг друга) и совместно исчерпывающими (все вместе они дают полную картину). Второе правило не менее важное: элементы на одном уровне должны быть соразмерны и однородны.
Если вы затрудняетесь с тем, насколько глубоко нужно исследовать проблему, используйте правило пяти «почему» и постарайтесь раскрыть вопрос на пять уровней в глубину.
Существует два подхода к построению «пирамиды»: дерево решений и дерево гипотез. При необходимости их можно комбинировать. Первый способ стоит использовать, если вы не очень хорошо разбираетесь в теме. Он основан на аргументах и утверждениях и отвечает на вопрос «каким образом?». Вы определяете основную проблему и разбиваете ее на более мелкие аспекты до тех пор, пока не будет найдено решение.
Второй подход базируется на предположениях и гипотезах и отвечает на вопрос «почему/зачем?». Его можно применить, если вы отлично владеете темой и можете сходу предположить, как нужно решать проблему. Дальнейшая работа строится на том, чтобы доказать или опровергнуть вашу гипотезу.
Оптимальный вариант — комбинация этих двух способов. На первом этапе постройте дерево решений, рассмотрите проблему с разных сторон, а затем предложите варианты решения каждой составляющей проблемы.
3. MECE Principle – 2 Basic Rules
Let’s follow the footsteps of Joe, a hypothetical senior intern, hoping to land a job at the White Cinema.
So, one day, Joe is called upon to address a problem regarding customer feedback: a series of anonymous negative reviews due to sound quality.
Joe suspects that the majority of customers are happy with the sound. There are just a few particular seats with bad sound quality (and he is right, it is the center-rear part where a few directional speakers have broken down; but he doesn’t know that yet, of course).
The cinema has 144 seats; rows are numbered 1-12 front-to-rear, and columns are marked A-L left-to-right; they are further arranged in nine 4×4 blocks, marked I-IX from left to right and from front to rear (the problematic block is VIII). The question is: how should he divide the seats?
Подписаться на карьерную рассылку
Подписывайтесь на рассылку и получайте карьерные советы — от выбора индустрии и компании до лайфхаков по самоорганизации и развитию коммуникативных навыков.
While most famous for its use in management consulting , MECE is a magic problem-solving principle that can be used anywhere, anytime, and by anyone.
This definitive guide will explain what MECE is, why MECE is important in problem-solving, and how you can be MECE. There will also be tips and tricks, application of MECE in consulting resume and case interview .
2. Why is MECE Important?
MECE is extremely important in problem-solving because it ensures complete coverage of the problem, helping to identify all possible root causes to ensure maximum-impact solutions. It also prevent effort duplications, saving time and resources. In other words, the problem is solved with the highest effectiveness and efficiency.
A very non-MECE segmentation, for instance, is to divide the students in a university into “male students” and “freshmen”. If the university tried to conduct a school-wide student survey this way, they would waste resources surveying each male freshmen twice, yet still failing to attain the feedback from all students (e.g: females sophomore were not included).
A MECE segmentation in this case can be based on gender (male/female) or seniority (freshman/sophomore/junior/senior); either way, every student will be surveyed once only, maximizing the results while minimizing the resources consumed.
And heck, MECE makes you sound smart and logical . That alone is already enough for me to keep reading. For all the benefits that the MECE principle provide, it is a central pillar of consulting/case interview problem-solving , a must-know for every aspiring management consultant – which is why in the Case Interview End-to-End Secrets Program , I emphasize this concept repeatedly both in case videos and the exercises.
Из этой статьи вы узнаете:
С чего начать поиск решения кейса, чтобы не запутаться?
Если дать случайному студенту кейс, то он, скорее всего, будет искать решение максимально хаотично. Это может привести к успеху, в конце концов и в лотерее есть победители. Но мы все-таки советуем использовать подход, который применяют консультанты из McKinsey & Company и Bain & Company. Вам нужно получить от интервьюера всю информацию, а потом попросить несколько минут на ее обработку. За это время вы должны разбить основную задачу на составляющие, подумать над возможными решениями и расставить приоритеты.
Проще всего создать структуру с помощью Issue Tree. На его вершине располагается главная задача, которую вы сформулировали по SMART еще на прошлом этапе решения кейса. Ветви — это уточняющие вопросы, с помощью которых мы детализируем проблему. А в корнях лежат четкие действия, которые нужно совершить. Issue Tree поможет вам не запутаться и, что самое главное, найти рабочие гипотезы — варианты решения бизнес-задачи.
Откуда берутся идеи
Мы предлагаем начинать решение с генерации идей по кейсу. Этот шаг позволит собрать вместе все мысли по задаче, которые вы затем оформите в структуру. Если для генерации идей у вас пока мало вводных, то поищите дополнительную информацию: по отрасли, по компании. Но не тратьте на это слишком много времени: в детали вы сможете углубиться на следующем этапе решения.
Самый распространенный и любимый всеми метод генерации идей — мозговой штурм (или брейнсторм), в ходе которого участники с разным опытом и навыками собираются вместе и делятся идеями о способах решения поставленной задачи. Чтобы сделать брейнсторм эффективным, заранее ознакомьтесь с проблемой и внимательно фиксируйте все высказанные предложения. Используйте флипчарт или доску, чтобы люди могли видеть список выработанных идей. Вовлекайте каждого члена команды и сами тоже не отсиживайтесь. Идеи могут быть самыми странными и глупыми. Главное — никого не критиковать, чтобы не демотивировать участников и не остановить поток мыслей. В какой-то момент из него точно выплывет что-то стоящее.
Фреймворки
Если вы только недавно познакомились со структурным мышлением, попробуйте шаблоны, которые часто используют консультанты — так называемые фреймворки. Наиболее популярные из них — это Profititability Framework, Business Situation Framework (Customer, Product, Company, Competition), SPECIALT, 5P (Marketing Mix), Матрица McKinsey, 5 сил Портера, SWOT-анализ и т.д. Все эти инструменты очень просты в использовании и помогают привести мысли в порядок. Так что не поленитесь разобраться в них. И помните: самые успешные консультанты умеют не только применять существующие фреймворки, но и разрабатывать собственные. Подходите к решению любой задачи творчески.
Mutually Exclusive – ME
This is just a fancy word for “ No Overlap ”. Each sub-branch must be clearly separated from all others. In the White cinema example here, here is a bad way to break down:
There is a clear overlapping area. Those seats in the center blocks would be accounted for twice in any analysis conducted using this breakdown.
Подведем итог
Самое сложное в любом деле — начать. Это касается и структурирования. Вместо того, чтобы тратить часы, пытаясь создать идеальную структуру, советуем взять драфтовую версию, которую в дальнейшем можно будет доработать. Возможно, готовый черновик уже существует. Ваши коллеги, знакомые и отраслевые эксперты могли работать над подобной задачей. Пообщайтесь с ними, покопайтесь в интернете и попробуйте найти то, что можно будет взять за основу для вашей дальнейшей работы.
Анализ всего дерева решений может длиться вечно, поэтому советуем вспомнить правило Парето о 20% усилий, которые дают 80% результата. Используйте интуицию, не пренебрегайте прикидками и не бойтесь рисковать: так вы быстро справитесь с основными аспектами, а ваше дерево не превратится в гигантскую секвойю. Во время анализа постоянно возвращайтесь к гипотезам и проверяйте, по-прежнему ли они актуальны. Новые данные, которые вы получите во время работы, могут кардинально изменить исходные предположения. Не тратьте время на маловажные факторы. Всегда думайте о том, зачем вы что-то делаете, и по ходу решения устраняйте незначимые аспекты, чтобы ваше дерево выросло стройным и здоровым.
Освоить структурное мышление и научиться использовать фреймворки для решения бизнес-задач можно на Школе Changellenge >>. Это пятинедельный карьерный онлайн-интенсив. Вашими преподавателями будут эксперты из рейтинговых компаний, вы заведете новые полезные знакомства и получите весомую строчку в резюме. Регистрируйтесь!
Как правильно сформулировать гипотезу и что с ней делать дальше?
Мало обнаружить гипотезы — их нужно еще правильно сформулировать. Отличить хорошую гипотезу от плохой можно по одному главному критерию: предположение конкретное и отвечает на вопрос кейса. К тому же вы можете измерить и протестировать свою догадку, а еще у вас есть данные, которые ее доказывают. Соответственно, плохая гипотеза — это абстрактное утверждение, которое нельзя подтвердить или опровергнуть. Либо настолько очевидная догадка, что она просто не может быть решением кейса.
Пример плохой гипотезы: «Реклама привлечет новых клиентов».
В общем, представьте себя ученым, который совершил открытие и планирует получить за него Нобелевскую премию. Что вы сделаете первым делом? Оцените адекватность своих идей перед тем, как озвучивать их публике. На кейс-интервью ваша аудитория — это интервьюер, который вместо престижной награды готов дать вам работу за качественную гипотезу. Но учтите, что публика будет придираться и оспаривать ваши идеи. Как их отстоять и доказать? Об этом поговорим в следующей статье под тегом «кейс-интервью».
Получите карьерную поддержку
Если вы не знаете, с чего начать карьеру, зашли в тупик или считаете, что совершили какие-то ошибки, спросите совета у специалистов. Заполните заявку и консультанты Changellenge >> окажут вам помощь. Это отличный шанс вместе экспертом проработать проблемные вопросы и составить карьерный план.
Подписаться на карьерную рассылку
Подписывайтесь на рассылку и получайте карьерные советы — от выбора индустрии и компании до лайфхаков по самоорганизации и развитию коммуникативных навыков.
Развиваете вы бизнес, покупаете квартиру или планируете отдых — любую задачу можно решить быстрее и эффективнее, если мыслить структурно. В рамках Школы Changellenge >> разбираем главные инструменты структурного мышления: пирамиду Минто, дерево решений, гипотезы, фреймворки и правило MECE.
Collectively Exhaustive – CE
As with mutually exclusive , the term collectively exhaustive is also just a fancy word for “ No Gap ”. All components adding up must be exactly equal to the original sum. In the White cinema example here, if one breaks down all seats into: Left and Center seats, the whole Right area would be missing and hence a gap.
Notice that a collectively exhaustive set must NOT exceed the intended sample space. So block number (I, II, III, …, XII) is NOT collectively exhaustive since blocks X, XI and XII do not belong in the original set.
Как сформулировать гипотезу
Все вышесказанное бесполезно, если слово «гипотеза» для вас — пустой звук. Определив проблему, вам нужно сделать несколько предположений о том, в чем ее корень. Это делается в три шага:
- идентифицируем главный вопрос: какие стратегические задачи стоят перед нами, кто оказывает влияние на компанию, каковы наши приоритеты;
- собираем все, что известно по теме: это могут быть как факты, так и предположения;
- формулируем гипотезу о возможном пути решения проблемы.
Помните: суть не в том, чтобы придумать гипотезу, а в том, чтобы она была качественной. Плохую гипотезу выявить легко: ее нельзя проверить, она слишком очевидна, не поддается количественной оценке, заставляет тратить время попусту.
Читайте также: