Zum Inhalt springen

Strukturiertes Denken: der eigentliche Vorteil von Beratern

Strukturiertes Denken gibt Ihnen einen Einstieg, wenn ein Kundenproblem unübersichtlich ist und der Raum Klarheit erwartet. Hier ist die Methode, die ich nutze, mit einem Arbeitsblatt auf einer Seite und dem, was KI daran verändert hat.

Figur im Business-Anzug im Zentrum eines weißen, kreisförmigen Labyrinths
Inhalt
  1. Was strukturiertes Denken ist und was nicht
  2. Die vier Werkzeuge
  3. Die Rahmenfrage
  4. MECE
  5. Issue Trees
  6. Hypothesengetriebene Analyse
  7. Ein Arbeitsblatt auf einer Seite
  8. So sieht das in der Praxis aus
  9. Was KI 2026 verändert hat
  10. Häufige Fehler
  11. Die Fähigkeit aufbauen
  12. Häufig gestellte Fragen

Strukturiertes Denken ist der Weg, auf dem ein Berater von einem vagen, unübersichtlichen Kundenproblem zu einer Empfehlung kommt, der der Raum folgen und die er hinterfragen kann. Sie fassen die Entscheidung in Worte, zerlegen das Problem in Teile ohne Überschneidung, prüfen zuerst die wahrscheinlichste Antwort und verdichten die Ergebnisse zu einer klaren Empfehlung.

Dieser Beitrag richtet sich an Berater und Analysten, die dafür unter Druck ein wiederholbares Vorgehen suchen. Er behandelt die vier Werkzeuge, auf die ich mich stütze, ein Arbeitsblatt auf einer Seite für Ihr nächstes Mandat und das, was KI an dieser Fähigkeit verändert hat.

Ich habe erlebt, wie Leute in Kundenterminen erstarren. Nicht, weil sie keine Ideen hatten. Sondern weil sie nicht wussten, wo sie anfangen sollten.

Die Situation ist bekannt. Ein komplexes Problem, ein Raum voller erfahrener Führungskräfte, ein vager Auftrag und die Erwartung von Klarheit. Die unstrukturierte Reaktion: anfangen zu reden und hoffen, dass sich die Antwort ergibt. Manchmal klappt das. Öfter drehen Sie zwanzig Minuten lang Kreise, und niemand geht zufrieden hinaus.

Es ist die Praxis, ein mehrdeutiges Problem in seine Teile zu zerlegen, jeden Teil der Reihe nach durchzuarbeiten und die Ergebnisse wieder zu einer Empfehlung zusammenzuführen.

Es heißt nicht, eine Vorlage auszufüllen und das dann Analyse zu nennen. Es heißt nicht, einem Problem ein Framework aufzuzwingen, das nicht passt. Ein Berater, der auf jede Situation eine 2x2-Matrix legt, erkennt Muster wieder, aber er denkt nicht.

Was Sie aufbauen, ist eine Handvoll Fähigkeiten:

  1. Das eigentliche Problem erkennen, das oft ein anderes ist als das geschilderte
  2. Es in Teile zerlegen, die sich getrennt analysieren lassen
  3. Wissen, welche Informationen zählen und welche nicht
  4. Aus dem, was Sie finden, eine schlüssige Argumentation aufbauen
  5. Es klar sagen, wenn die Stimmung im Raum angespannt ist

Die Frameworks sind ein Gerüst, solange sich diese Fähigkeiten entwickeln. Wenn Sie das größere Werkzeugset kennenlernen möchten: Die gängigen habe ich in Consulting-Frameworks einfach erklärt beschrieben.

Die Rahmenfrage

Stellen Sie vor jedem Framework eine einzige Frage. Welche Entscheidung muss getroffen werden, und welche Information würde diese Entscheidung ändern?

Sie verbessert die Qualität der Analyse mehr als jedes strukturelle Werkzeug. Sie zwingt zur Klarheit darüber, was am Ende herauskommen soll, und verhindert, dass Sie gründliche Arbeit an einer Frage leisten, die niemand beantwortet haben wollte. Die HBR hat dasselbe Argument schon vor Jahren in Are You Solving the Right Problem? vorgebracht: Die meiste vergeudete Mühe beginnt mit einem schlecht definierten Problem.

Im SAP-Kontext ist „Welches Bereitstellungsmodell passt zu dieser Organisation?“ eine Entscheidung. „Was ist S/4HANA?“ ist eine Beschreibung. Die erste braucht Analyse. Die zweite braucht Dokumentation. Wenn Sie wissen, welche von beiden Sie gerade bearbeiten, entscheidet das darüber, wie Sie die Woche nutzen.

MECE

MECE steht für Mutually Exclusive, Collectively Exhaustive, also überschneidungsfrei und vollständig. Wenn Sie ein Problem aufteilen, sollte jeder Teil eigenständig sein (keine Überschneidung), und zusammen sollten die Teile das ganze Problem abdecken (keine Lücken).

Überschneidende Kategorien zählen doppelt. Lücken übersehen etwas. Die meisten Berater kennen das Kürzel. Nur wenige wenden es konsequent an.

Zwei Tests halten Sie ehrlich. Erstens: Könnte ein Element zugleich in zwei Ästen liegen? Dann überschneiden sich die Äste. Zweitens: Wäre die zentrale Frage beantwortet, wenn jeder Ast beantwortet wäre? Wenn nicht, gibt es eine Lücke. Perfektes MECE ist selten. Entscheidend ist, sich beide Fragen jedes Mal zu stellen.

Issue Trees

Ein Issue Tree setzt die zentrale Frage an die Wurzel und die Teilfragen an die Äste. Jeder Ast lässt sich für sich analysieren.

Nehmen Sie „Warum hat dieses SAP-Go-live das geplante Budget um 40 % überschritten?“ Die erste Aufteilung könnte lauten: Scope-Änderungen, Ressourcenkosten, Terminverlängerungen und ungeplante Nacharbeiten. Die Scope-Änderungen teilen sich dann weiter auf in formale Änderungsanträge, informelle Ergänzungen und spät entdeckte Lücken. Jedes Blatt lässt sich messen.

Issue Trees zahlen sich zu Beginn eines Mandats aus, bevor Sie irgendeine Analyse gemacht haben. Sie bewahren Sie davor, drei Wochen in einen Ast zu stecken, während ein anderer unberührt bleibt.

Hypothesengetriebene Analyse

Statt erst alle Daten zu sammeln und dann zu schlussfolgern, beginnen Sie mit der wahrscheinlichsten Antwort und prüfen sie. Strategieberatungen haben ihren Ruf auf diesem Vorgehen aufgebaut.

Bei knapper Zeit und einem komplexen Problem ist eine erschöpfende Analyse nicht möglich. Eine gute Hypothese sagt Ihnen, wohin Sie zuerst schauen. Hält sie, haben Sie Ihre Antwort. Hält sie nicht, weist die Evidenz, die sie widerlegt hat, meist in eine nützliche Richtung.

Es ist auch das Vorgehen, das am häufigsten missbraucht wird. Berater bilden eine Hypothese und suchen dann nur noch nach Belegen, die sie bestätigen. Fragen Sie, welche Belege Sie widerlegen würden, und suchen Sie zuerst danach.

Das ist die Abfolge, die ich einem neuen Berater vor seiner ersten Diagnose in die Hand geben würde. Füllen Sie sie aus, bevor Sie auch nur eine Tabellenkalkulation öffnen.

Vom vagen Auftrag zur EmpfehlungSieben Schritte, in dieser Reihenfolge. Den letzten überspringen die meisten.
  1. RahmenDie Entscheidung in einem Satz
  2. ZerlegenDrei bis fünf MECE-Fragen
  3. HypotheseEine Zeile pro Ast
  4. WiderlegenBelege, die Sie widerlegen würden
  5. TestenErgebnisse je Ast, mit Quellen
  6. SyntheseErst die Empfehlung, dann die Begründung
  7. BelastungstestEinwände beantwortet, bevor der Raum sie erhebt

Eine Empfehlung, die den Lenkungsausschuss übersteht

SchrittZu beantwortende FrageErgebnisWer gibt frei
1. RahmenWelche Entscheidung muss der Kunde treffen, und bis wann?Ein SatzDer Sponsor auf Kundenseite
2. ZerlegenWelche drei bis fünf Fragen entscheiden, gemeinsam beantwortet, diese Entscheidung?Issue Tree der ersten Ebene, auf MECE geprüftProjektleitung
3. HypotheseWas glaube ich aktuell, wie die Antwort lautet, und warum?Eine Hypothese pro Ast in einer ZeileProjektleitung
4. WiderlegenWelche Belege würden zeigen, dass die jeweilige Hypothese falsch ist?Datenanforderungsliste, priorisiertDie Datenverantwortlichen des Kunden sagen die Lieferung zu
5. TestenWas sagt die Evidenz?Ergebnisse je Ast, mit QuellenAst-Verantwortliche im Team
6. SyntheseWas soll der Kunde also tun?Erst die Empfehlung, dann die stützenden PunkteProjektleitung
7. BelastungstestWer im Raum wird widersprechen, und worin?Einwände und Antworten, vorbereitetEin Kollege, der nicht an der Arbeit beteiligt war

Schritt 7 überspringen die meisten. Er entscheidet auch darüber, ob die Empfehlung den Lenkungsausschuss übersteht.

Ein SAP-Kunde, ein großer Fertigungskonzern, betrieb eine stark angepasste ECC-Landschaft. Der IT-Leiter sagte es ohne Umschweife: „Wir müssen die Betriebskosten senken, können es uns aber nicht leisten, etwas kaputtzumachen.“

Der Instinkt sagt: Fangen Sie an, Einsparideen aufzulisten. Das ergibt eine lange Liste, viele nervöse Leute und keine Prioritäten.

Wir haben die Kostenanalyse in drei Äste gegliedert: Anwendungswartung, Infrastruktur und Lizenzen. Dann haben wir eine Analyse des kundeneigenen Codes darübergelegt. Wie viele Modifikationen waren tatsächlich im Einsatz? Mehr als die Hälfte nicht. Redundante Schnittstellen, ungenutzte kundeneigene Reports, überlappende Workflows.

Die Strukturierung erlaubte uns, auf Einsparungen zu zeigen, die sich sicher anfühlten, etwa das Archivieren ungenutzter kundeneigener Objekte und das Zusammenlegen von Entwicklungssystemen. Die Klarheit nahm Reibung aus der Politik und schuf Vertrauen. Ohne den Baum wäre es eine Liste von Kürzungen gewesen, die niemand unterschreiben wollte.

Dieselbe Methode funktioniert bei vageren Aufträgen. Ein Anbieter von Unternehmenssoftware bat uns einmal um „eine regionale Einführungsstrategie“ für den saudi-arabischen Mittelstandsmarkt. Wir teilten die Arbeit in Marktnachfrage, Wettbewerbsposition und Partnerreife. Unter Partnerreife stellten wir fest, dass das Reseller-Netzwerk kaum Erfahrung mit SAP S/4HANA Cloud hatte. Dieser Blocker hätte die Umsetzung gestoppt, so attraktiv der Markt auch aussah, und die Struktur brachte ihn ans Licht, bevor das Kampagnenbudget ausgegeben war.

Struktur ersetzt das Denken nicht. Sie macht es schneller und vermittelbar. Wer ein vages Problem unter Druck in eine klare Struktur zerlegen kann, ist mehr wert als jemand, der die Fragen beantworten kann, sobald sie definiert sind.

Die Frameworks haben sich nicht geändert. Zwei andere Dinge schon.

Der Entwurf ist jetzt billig. Joule, ChatGPT und Claude erzeugen in Sekunden einen Issue Tree oder einen Hypothesenbaum. Junior-Berater, die früher einen Abend für einen ersten Entwurf brauchten, erzeugen ihn jetzt in einer halben Minute und verbringen den Abend mit dem, was das Modell nicht kann: prüfen, ob die Struktur zum Problem passt, herausfinden, was fehlt, und die Annahmen im Prompt hinterfragen.

Die Prämie auf Urteilsvermögen ist gewachsen. Wenn jeder eine MECE-Gliederung erzeugen kann, lautet die Frage nicht mehr „Haben Sie das Problem zerlegt?“ Sie lautet: „Haben Sie bemerkt, dass das genannte Problem ein anderes ist, und haben Sie die Annahme erkannt, die das Modell stillschweigend übernommen hat?“ Berater, die ihr Urteilsvermögen in echten Projekten aufgebaut haben, haben heute einen größeren Vorsprung als 2024.

Die Fähigkeit hat sich also verschoben. Es geht nicht mehr darum, ob Sie einen Issue Tree bauen können. Es geht darum, ob Sie erkennen, wenn der von der KI entworfene Baum falsch ist, und ihn in einem Kundenraum korrigieren können.

Wenn Sie überlegen, was das für Ihre eigene Karriere bedeutet: Die Karrierepfade von SAPopedia zeigen die Beraterlaufbahnen, und das ERPCV-Karrierepaket hilft Ihnen, solches Urteilsvermögen im Lebenslauf zu belegen, statt nur Frameworks aufzulisten.

Mit einer Lösung beginnen. Der Kunde oder der Berater hat eine Antwort im Kopf, bevor das Problem gerahmt ist. Die Analyse wird zur Bestätigung.

Zu viel Struktur. Manche einfachen Probleme verdienen eine direkte Antwort statt einer MECE-Zerlegung. Zu wissen, wann man keine Struktur braucht, ist so wichtig wie zu wissen, wie man sie einsetzt.

In der falschen Tiefe zerlegen. Bäume, die zu früh zu tief werden, führen zu Lähmung. Bäume, die flach bleiben, führen zu Empfehlungen, nach denen niemand handeln kann. Passen Sie die Tiefe an die Entscheidung und die verfügbare Zeit an.

Analyse ohne Synthese. Ein strenger Baum, der in einem Datenabwurf endet. Struktur hilft Ihnen beim Denken. Urteilsvermögen erzeugt die Empfehlung.

Kommunikationsstruktur mit Denkstruktur verwechseln. Die Schlussfolgerung zuerst zu präsentieren, wie in Barbara Mintos Pyramid Principle, ist eine Kommunikationstechnik. Sie sagt nichts darüber, ob das Denken darunter stimmig war. Gute Kommunikation schlechter Analyse bleibt schlechte Analyse.

Es ist eine Fähigkeit, keine Charaktereigenschaft. Sie entsteht durch Übung.

Schreiben Sie nach jedem wichtigen Kundengespräch auf, wie Sie das Problem verstehen, wie Sie es zerlegen, Ihre Hypothese und die Belege, die sie prüfen würden. Tun Sie das, bevor Sie irgendwelche Daten ansehen. Schreiben erzwingt eine Klarheit, die Denken im Kopf nicht leistet.

Üben Sie Synthese, nicht nur Analyse. Aus einem Berg von Belegen eine vertretbare Empfehlung zu machen, ist die schwerere Hälfte. Die meisten Junior-Berater sind in der Analyse ausreichend gut und in der Synthese unterentwickelt. In dieser Lücke liegt die nächste Beförderung, und sie ist ein großer Teil dessen, was Berater tatsächlich tun, wenn man die Buzzwords abzieht.

Was ist strukturiertes Denken in der Beratung?

Es bedeutet, ein komplexes, mehrdeutiges Problem in Teile zu zerlegen, jeden Teil der Reihe nach durchzuarbeiten und die Ergebnisse zu einer klaren Empfehlung zusammenzuführen. Es macht schwierige Probleme handhabbar und das Denken sichtbar, sodass der Kunde ihm folgen und es hinterfragen kann, statt eine Schlussfolgerung auf Treu und Glauben hinzunehmen.

Die wichtigsten Werkzeuge sind die Rahmenfrage, Issue Trees, MECE und die hypothesengetriebene Analyse. Keines davon ersetzt das Urteilsvermögen.

Was bedeutet MECE und wie wird es eingesetzt?

Mutually Exclusive, Collectively Exhaustive. Die Teile einer Gliederung sollten sich nicht überschneiden, und zusammen sollten sie das ganze Problem abdecken.

Test auf Überschneidung: Könnte ein Element in zwei Ästen liegen? Test auf Lücken: Wäre die zentrale Frage beantwortet, wenn jeder Ast beantwortet wäre? Wenden Sie es an, wenn Sie den Issue Tree bauen. Es auf eine fertige Analyse anzuwenden, kommt meist zu spät.

Wie funktioniert hypothesengetriebene Analyse?

Sie nennen früh die wahrscheinlichste Antwort, listen die Belege auf, die sie bestätigen oder widerlegen würden, und prüfen sie dann. Das ist schneller, als erst alles zu sammeln, weil es Ihnen sagt, wo Sie suchen müssen.

Das Risiko ist der Bestätigungsfehler. Suchen Sie zuerst nach den Belegen, die Sie widerlegen könnten.

Wie rahmen Sie ein Beratungsproblem richtig?

Fragen Sie, welche Entscheidung getroffen werden muss und welche Information sie ändern würde. Prüfen Sie dann die Problemstellung des Kunden, bevor Sie sie übernehmen.

Ein Kunde, der fragt „Welches SAP-Modul sollen wir zuerst einführen?“, entscheidet vielleicht in Wahrheit: „Ist jetzt überhaupt der richtige Zeitpunkt, ein SAP-Programm zu starten?“ Wer die gestellte Frage beantwortet, ohne den Rahmen zu prüfen, liefert eine Analyse, die technisch stimmt und kaufmännisch falsch ist.

Worin unterscheiden sich Analyse und Synthese in der Beratung?

Analyse zerlegt ein Problem oder einen Datensatz in Teile, um sie zu verstehen. Synthese führt die Ergebnisse zu einer Empfehlung zusammen.

Das häufigste Versagen bei Ergebnisdokumenten: viel Analyse und keine Synthese. Der Kunde erhält einen Stapel Befunde und keine Antwort auf die Frage, für die er Sie engagiert hat. Wer die Schlussfolgerung zuerst schreibt, erzwingt die Synthese.

Wie wirkt sich strukturiertes Denken auf ERP-Einführungen aus?

Zum Programmstart verhindert es, dass Teams konfigurieren, bevor das eigentliche Problem verstanden ist. Eine Organisation, die sagt „Wir brauchen SAP“, muss vielleicht zuerst einen Prozess oder ein Datenproblem beheben, das SAP nur sichtbarer machen wird.

In der Fit-Gap-Arbeit stellt eine MECE-Gliederung der Geschäftsprozesse sicher, dass jeder Prozess betrachtet wird, nicht nur die, die in Workshops zur Sprache kamen. Nach einem holprigen Go-live bringt es Sie schneller zu einer belastbaren Empfehlung, die Entscheidung zu rahmen (stabilisieren, sanieren oder ersetzen) und eine Hypothese zur Hauptursache zu prüfen, als Symptome aufzulisten.

Noel D'Costa

Geschrieben von

Noel D'Costa

25 Jahre in SAP- und Oracle-ERP-Programmen in Luftfahrt, öffentlicher Verwaltung, Finanzwesen, Handel und Fertigung. Hintergrund im Finanzbereich. Ich helfe Führungsteams, Transformationen ehrlich zu planen, Programme in Schwierigkeiten zu stabilisieren und Systeme aufzubauen, die ihr erstes Jahr im Produktivbetrieb überstehen.

Nächster Schritt

Leiten Sie gerade ein ERP-Programm?

Wenn dieser Artikel ein Programm berührt, in dem Sie gerade stecken, bringt ein 30-minütiges Gespräch meist mehr als eine weitere Woche interner Analyse.