Wie du einen Beratungs-Case strukturierst: Die Issue-Tree-Methode

Bevor du lernst, eine zu bauen, versteh, was du eigentlich baust.

Stell dir vor, du bist Feuerwehrfrau und kommst an einem brennenden Gebäude an. Du rennst nicht planlos hinein und fängst an, Wasser zu spritzen. Du verschaffst dir zuerst einen Überblick über das Gebäude: welche Stockwerke brennen, wo die Ausgänge sind, wo Menschen eingeschlossen sein könnten. Diese 30-sekündige Einschätzung ist deine Struktur. Sie sagt dir, wohin du Ressourcen lenkst und in welcher Reihenfolge.

Eine Case-Struktur ist dasselbe. Sie ist eine schnelle Einschätzung (vor jeder Analyse), wie der Problemraum aussieht. Welche Bereiche könnten das verursachen? Welche Bereiche können wir sofort ausschließen? Wo ist der Ort mit der größten Hebelwirkung, um zuerst zu graben? Die Struktur beantwortet die Frage nicht. Sie kartiert das Gelände, damit deine Analyse keine Zeit in den falschen Räumen verschwendet.

Ohne sie bist du die Feuerwehrfrau, die blind hineinrennt. Mit ihr bist du diejenige, die das Problem in der halben Zeit findet.

Ein Problembaum ist das visuelle Werkzeug, mit dem Berater Struktur aufbauen und kommunizieren. So solltest du darüber denken.

Du bist Ermittler und betrittst gerade einen Tatort. Du pinselst nicht jede Oberfläche nach Fingerabdrücken ab. Du beginnst mit drei Fragen: Motiv, Mittel, Gelegenheit. Jede davon zerfällt in Unterfragen. Das Motiv zerfällt in: Wer profitiert von diesem Ergebnis, und wer hatte einen Groll? Die Mittel zerfallen in: Wer hatte Zugang, und wer hatte die Fähigkeit? Du arbeitest dich den Baum hinunter und streichst Äste, sobald Beweise sie ausschließen.

Ein Problembaum tut genau das für ein Business-Problem. Die Wurzel ist die Frage des Kunden: „Warum sinkt unser Gewinn?“ Die erste Ebene von Ästen ist die MECE-Zerlegung (überschneidungsfrei und vollständig) der möglichen Ursachen: ein Umsatzproblem, ein Kostenproblem oder beides. Der Umsatz zerfällt dann in Preis und Volumen. Das Volumen zerfällt in Kundenzahl und Kaufhäufigkeit. Jeder Ast ist eine Hypothese. Du streichst die, die die Daten ausschließen, und gehst bei denen in die Tiefe, die die Daten stützen.

Der Baum verhindert, dass du im Kreis läufst. Jede Frage, die du stellst, entspricht einem Knoten. Wenn eine Frage keinem Knoten entspricht, fügst du entweder den Knoten hinzu oder lässt die Frage fallen, denn dann untersuchst du etwas außerhalb des Problemraums.

Der Interviewer gibt dir die Fragestellung. Du stellst eine klärende Frage, um das Ziel zu bestätigen. Dann sagst du: „Darf ich mir eine Minute nehmen, um meine Gedanken zu strukturieren?“ Das passiert in dieser Minute.

Schritt 1: Schreib die Frage des Kunden oben auf dein Blatt. Nicht die Situation. Die Frage. „Sollte Peloton die Preise senken?“, nicht „Das Abonnentenwachstum von Peloton verlangsamt sich.“

Schritt 2: Zeichne drei bis vier Äste auf Ebene 1. Das sind die wichtigsten MECE-Kategorien des Antwortraums. Bei einem Profitabilitäts-Case: Umsatz und Kosten. Bei einem Markteintritts-Case: Marktattraktivität, Wettbewerbsvorteil und Go-to-Market. Erfinde nicht für jeden Case ein neues Framework. Eine kleine Zahl verlässlicher Strukturen auf Ebene 1 deckt 80% der Cases ab.

Schritt 3: Füge unter jedem Ast eine Detailebene hinzu. Umsatz zerfällt in Preis und Volumen. Volumen zerfällt in Neukunden und Kundenbindung. Diese zweite Ebene beweist dem Interviewer, dass du das Fachgebiet kennst und nicht nur die Vorlage.

Schritt 4: Nenne eine Hypothese. Leg dich auf eine Arbeitstheorie fest, bevor du nach Daten fragst. „Meine Hypothese ist, dass das Problem auf der Kostenseite liegt, konkret bei Fixkosten, die sich nicht an die geringere Nachfrage angepasst haben, aber ich möchte das zuerst mit Umsatzdaten überprüfen.“ Genau das trennt hypothesengetriebene Analysten von Datensammlern.

Übe das am Peloton-Case, einem klassischen Profitabilitätsproblem, bei dem die Verzweigung zwischen Hardware-, Abonnement- und Content-Kosten genau zeigt, welcher Hebel am meisten zählt.

Die Methode zu kennen, reicht nicht. Diese vier Fehler tauchen in fast jedem ersten Entwurf auf.

Fehler 1: Mit einem benannten Framework statt mit dem Problem beginnen. „Ich nutze die 4 Ps“ ist keine Struktur. Es ist eine Vorlage. Frameworks sind Zutaten, keine Ergebnisse. Deine Struktur sollte aus der konkreten Frage des Kunden entstehen, nicht aus einer auswendig gelernten Liste.

Fehler 2: Äste auf Ebene 1, die nicht MECE sind. „Umsatz, Kosten und Bruttomarge“ überschneiden sich. Die Bruttomarge enthält den Umsatz. Wenn ein Datenpunkt in zwei Äste passen könnte, ist deine Struktur kaputt, bevor die Analyse überhaupt beginnt.

Fehler 3: Zu viele Äste. Drei bis vier Äste auf Ebene 1 sind die Grenze. Bei mehr als vier hast du das Problem beschrieben, statt es zu strukturieren. Wenn du sechs Äste hast, sollten zwei davon zusammengelegt oder gestrichen werden.

Fehler 4: Die Hypothese überspringen. Eine Struktur ohne Hypothese ist nur eine Liste. Die Hypothese macht den Baum zum Werkzeug. Sie sagt dir, welchen Ast du zuerst untersuchst und welches Ergebnis deine Meinung ändern würde.

Case-Struktur ist ein Muskel. Du baust ihn durch Tun auf, nicht durch Lesen.

Übung 1: Strukturiere eine Schlagzeile. Nimm eine beliebige Wirtschaftsmeldung und bau einen Problembaum auf Ebene 1 für das beschriebene Problem. „Die Kundenfrequenz bei Starbucks liegt 8% unter dem Vorjahr.“ Zeichne den Baum, bevor du den Artikel liest. Prüfe dann, wie nah du dran warst.

Übung 2: Zwing dich zu einer Hypothese. Schreib nach jeder Struktur, die du zeichnest, einen Satz, der mit „Meine Hypothese ist …“ beginnt, bevor du nach Daten fragen darfst. Wenn du keine Hypothese bilden kannst, ist deine Struktur nicht konkret genug.

Übung 3: Übe an einem Case, der sich wehrt. Der beste Weg, eine Struktur zu testen, ist, sie unter Druck einzusetzen, an einem Case mit echten Daten, Sackgassen und Wendungen, die eine schwache Ausgangsstruktur bestrafen. Genau das baut realistisches Case-Training auf.