Entscheidungsmethode

Checkliste Entscheidungsqualität

Sechs Elemente, die gute Entscheidungen von Glückstreffern unterscheiden. Prüfe sie, bevor du dich festlegst.

Zuletzt aktualisiert: April 2026

Was ist Entscheidungsqualität?

Entscheidungsqualität bedeutet, den Entscheidungsprozess zu bewerten, bevor das Ergebnis feststeht. Das Framework wurde von Ronald Howard an der Stanford University in den 1960er-Jahren entwickelt und später von Carl Spetzler, Jennifer Meyer und Claudia von Winter in "Decision Quality: Value Creation from Better Business Decisions" (2016) formalisiert. Die zentrale Erkenntnis: Du kannst das Ergebnis nicht kontrollieren, aber du kannst die Qualität des Prozesses kontrollieren, der zur Entscheidung führt. Eine gute Entscheidung kann ein schlechtes Ergebnis haben (Pech). Eine schlechte Entscheidung kann ein gutes Ergebnis haben (Glück). Entscheidungen nach ihren Ergebnissen zu beurteilen ist der häufigste Fehler im Management.

Stell dir Entscheidungsqualität als Kette mit sechs Gliedern vor. Eine Kette ist nur so stark wie ihr schwächstes Glied. Wenn dein Team das Framing, Alternativen, Information, Werte und Logik perfekt hinbekommen hat, aber das Commitment übersprungen hat (die Umsetzenden wurden nicht gefragt), wird die Entscheidung bei der Umsetzung scheitern, egal wie stark die anderen fünf Elemente sind. Alle sechs zu prüfen ist keine Bürokratie. Es bedeutet, das eine schwache Glied zu finden, das unter Druck brechen wird, solange noch Zeit ist, es zu stärken.

Das Decision-Quality-Framework wird in der Strategieberatung (McKinsey, Bain, BCG nutzen Varianten), in Pharmaunternehmen (Entscheidung, ob ein Medikament von Phase II zu Phase III geht), bei Öl- und Gasunternehmen (Investitionsentscheidungen im Milliardenbereich) und in Vorständen bei Übernahme-Entscheidungen eingesetzt. Im deutschsprachigen Raum überschneidet sich das Konzept mit der Tradition der Entscheidungslehre und Entscheidungsprozessen, wie sie in VDI/VDE-Richtlinien referenziert werden. Besonders wertvoll ist es für Entscheidungen mit hohem Einsatz, die schwer umkehrbar sind und bei denen ein guter Prozess wichtiger ist als eine schnelle Antwort.

Framing

Kannst du die Entscheidung in einem Satz formulieren?

Ist die Entscheidung klar definiert? Sind sich alle Beteiligten einig, was entschieden wird und warum?

So sieht es gut aus: Wir müssen bis Freitag entscheiden, welches CRM wir mit dem 8-köpfigen Vertriebsteam 90 Tage testen.

Warnsignal: Wir müssen unsere Technologiestrategie klären. (Zu breit. Erst eingrenzen.)

Alternativen

Würde ein kluger Außenstehender eine Option vorschlagen, die du nicht bedacht hast?

Mindestens drei wirklich unterschiedliche Optionen verhindern die Falle des binären Denkens ("machen oder nicht machen"). Binäres Framing eliminiert kreative Lösungen, die besser sein könnten als beide Optionen. Gute Alternativen sind realistisch (jede könnte tatsächlich umgesetzt werden), unterscheidbar (keine Minimalvarianten derselben Idee) und enthalten mindestens eine Option, die Annahmen in Frage stellt. Ein Team, das nur "AWS vs. On-Premise bleiben" betrachtet, hat nicht wirklich Alternativen erkundet.

So sieht es gut aus: Wir haben 4 Optionen identifiziert: Salesforce, HubSpot, Pipedrive, Eigenentwicklung. Jede ist realistisch umsetzbar.

Warnsignal: Unsere Optionen: machen oder nicht machen. (Binäres Framing übersieht kreative Alternativen. Mindestens 3 suchen.)

Information

Was würde deine Meinung ändern? Hast du diese Daten?

Identifiziere, was du weißt, was du nicht weißt und was du herausfinden musst, bevor entschieden wird. Das Ziel ist nicht perfekte Information (die nie existiert), sondern ausreichende Information: genug, um zwischen Optionen auf den Kriterien zu differenzieren, die zählen. Was schiefgeht bei Schwäche: Teams entscheiden auf Basis von Annahmen, die nie getestet wurden, und entdecken mitten in der Umsetzung, dass eine kritische Annahme falsch war. Der günstigste Zeitpunkt, fehlende Daten zu beschaffen, ist bevor du dich festlegst.

So sieht es gut aus: Wir haben Preise aller Anbieter, Referenzgespräche mit je 2 Kunden und eine technische Bewertung des Integrationsaufwands.

Warnsignal: Wir haben die Anbieter-Websites gelesen und eine G2-Bewertung. (Nicht genug Daten. Noch einen Tag investieren.)

Werte

Würden zwei Personen die gleichen Kriterien verwenden?

Erfolgskriterien müssen explizit und zwischen allen Entscheidern abgestimmt sein, bevor Optionen bewertet werden. "Was bedeutet Erfolg?" sollte eine konkrete, messbare Antwort haben. Ohne definierte Werte bewertet jede Person Optionen an ihren eigenen privaten Kriterien, was zur Illusion von Einigkeit führt: Alle stimmen für Option B, aber aus komplett verschiedenen Gründen. Wenn Werte schwach sind, optimiert der CFO auf Kosten, der CTO auf Skalierbarkeit, und niemand merkt, dass sie verschiedene Gleichungen lösen.

So sieht es gut aus: Das Team ist sich einig: Erfolg heißt 80% Adoption in 90 Tagen und 20% schnellere Lead-Reaktionszeit.

Warnsignal: Erfolg heißt, das Projekt läuft gut. (Zu vage. Messbare Kriterien definieren, bevor Optionen bewertet werden.)

Logik

Könntest du deine Argumentation einem Skeptiker erklären?

Die Argumentation, die Information mit Empfehlung verbindet, sollte klar genug sein, dass ein Skeptiker ihr folgen und einzelne Glieder anfechten könnte. Gute Logik ist dokumentiert: "Wir haben Option B gewählt, weil sie bei unseren drei höchstgewichteten Kriterien in der Entscheidungsmatrix am besten abschnitt." Schlechte Logik ist implizit: "Wir haben uns für Option B entschieden, weil es sich richtig anfühlte." Wenn Logik schwach ist, kann die Entscheidung nicht jemandem erklärt werden, der nicht im Raum war.

So sieht es gut aus: Wir haben alle 4 Optionen an unseren 5 Kriterien mit einer Entscheidungsmatrix bewertet. Der Weg von Bewertung zu Empfehlung ist dokumentiert.

Warnsignal: Der CEO mag Salesforce, also nehmen wir Salesforce. (Entscheidung per Autorität, nicht per Logik. Die Matrix durchführen.)

Commitment

Stimmen alle, die diese Entscheidung umsetzen müssen, ihr zu?

Die beste Analyse ist wertlos ohne Zustimmung der Personen, die umsetzen. Commitment bedeutet: Die Umsetzenden waren Teil der Bewertung (nicht nur nachträglich informiert), sie verstehen und befürworten die Begründung, und sie haben die Ressourcen und den Zeitrahmen zur Umsetzung. Eine Entscheidung, die die Führungsebene ohne das Team trifft, das sie umsetzt, scheitert typischerweise nicht weil die Analyse falsch war, sondern weil das Team entweder passiv widersteht oder Umsetzungsbarrieren entdeckt, die die Führung nie bedacht hat.

So sieht es gut aus: Die Vertriebsleiterin war Teil der Evaluation und steht öffentlich hinter der Wahl. Training ist geplant.

Warnsignal: Das Team wurde nicht gefragt. Sie erfahren es im All-Hands. (Kein Buy-in heißt keine Adoption. Umsetzende einbeziehen, bevor entschieden wird.)

0 / 6 Elemente geprüft

Schwach: Mehrere Lücken. Mehr Zeit investieren.

Praxisbeispiel

Ein Softwareunternehmen mit 50 Mitarbeitenden stand vor der Entscheidung, ob die Produktivinfrastruktur von On-Premise auf die Cloud migriert werden soll. Der CTO schlug die Migration in einem Leadership-Meeting vor, und das Team war bereit, den Umzug zu AWS zu genehmigen. Bevor die Zusage kam, schlug die VP Product einen Decision-Quality-Check vor. Er dauerte 25 Minuten.

Das Team ging alle 6 Elemente durch: Framing war stark ("Sollen wir unsere Produktivinfrastruktur innerhalb von 6 Monaten in die Cloud migrieren?" mit klarem Scope, Zeitrahmen, CTO als Entscheider). Alternativen war schwach: Das Team hatte nur zwei Optionen betrachtet, AWS oder bei On-Premise bleiben. Niemand hatte Azure evaluiert (das Credits für ihren Use Case bot), Google Cloud (mit passendem Managed-Kubernetes-Service) oder einen Hybrid-Ansatz. Das Team hatte sich auf AWS fixiert, weil der CTO es bei seinem vorherigen Arbeitgeber genutzt hatte.

Information und Werte waren stark: Kostenvergleiche, Performance-Benchmarks und definierte Erfolgskriterien (99,9% Uptime, weniger als 200ms Latenz-Erhöhung, Migration innerhalb von 6 Monaten, Kosten maximal 15% über aktuell). Logik war stark: Entscheidungsmatrix mit 5 Kriterien vorbereitet.

Commitment war schwach: Das IT-Operations-Team (3 Personen, die die Migration durchführen würden) war nicht konsultiert worden. Als der DQ-Check diese Lücke aufdeckte, lud der CTO den Ops-Teamlead zum nächsten Meeting ein. Der Ops-Lead brachte sofort zwei Probleme auf: Das aktuelle Backup-System war mit keinem Cloud-Anbieter-Snapshot-Modell kompatibel, und eine kritische Legacy-Anwendung benötigte Kernel-Level-Zugriff, den Cloud-VMs nicht bieten.

ElementBewertungFeststellung
FramingStarkKlarer Scope, Zeitrahmen und Entscheider
AlternativenSchwachNur AWS vs. On-Premise betrachtet. Azure, GCP, Hybrid-Ansatz übersehen
InformationStarkKosten-, Performance- und Machbarkeitsdaten vorhanden
WerteStarkErfolgskriterien definiert: Uptime, Latenz, Zeitrahmen, Kosten
LogikStarkEntscheidungsmatrix mit 5 Kriterien vorbereitet
CommitmentSchwachIT-Operations-Team (die Umsetzenden) nicht konsultiert

Der DQ-Check dauerte 25 Minuten und verhinderte eine Festlegung auf AWS, ohne Alternativen zu erkunden oder die Zustimmung des Teams einzuholen, das die Migration durchführen würde. Nach Hinzufügen von Azure und Hybrid als Optionen und Einbeziehung des Ops-Teams war die finale Entscheidung ein Hybrid-Ansatz: Unkritische Dienste zu Azure (das 50.000 EUR Credits bot), Legacy-Anwendung bleibt 6 Monate on-premise bis zum Refactoring. Das Ops-Team entwarf den Migrationsplan selbst, was bedeutete, dass sie ihn verantworteten statt ihm zu widerstehen.

Praxis-Tipp: Die Checkliste am ANFANG des Entscheidungsprozesses nutzen, nicht als finale Prüfung. Ein schwaches Element früh zu entdecken (wie fehlende Alternativen) ist billig. Es zu entdecken, nachdem Ressourcen gebunden sind, ist teuer. Je früher du das schwache Glied findest, desto weniger kostet die Reparatur.

Praxis-Tipp: Im Team: jeder füllt die Checkliste unabhängig aus, bevor Ergebnisse verglichen werden. Die Meinungsverschiedenheiten darüber, welche Elemente stark sind, sind das wertvollste Ergebnis. Wenn drei Personen "Commitment" als stark bewerten, aber eine als schwach, weiß diese Person etwas, das die anderen nicht wissen.

Praxis-Tipp: Besonders auf "Alternativen" und "Commitment" achten, weil das die beiden häufigsten Schwachstellen sind. Teams springen oft direkt zur Bewertung der ersten zwei Optionen, die ihnen einfallen (schwache Alternativen), und entscheiden ohne die Umsetzenden zu fragen (schwaches Commitment).

Praxis-Tipp: Bei einem Score von 3-4 von 6 dem Drang widerstehen, trotzdem weiterzumachen. Die schwachen Elemente adressieren, bevor entschieden wird, auch wenn es einen Tag oder eine Woche zusätzlich kostet. Die Kosten einer 5-Tage-Verzögerung sind fast immer niedriger als die Kosten eines 6-Monats-Projekts, das scheitert, weil das Framing falsch war oder das Team kein Buy-in hatte.

Häufig gestellte Fragen

Ronald Howard an der Stanford University legte die Grundlagen in den 1960er-Jahren. Carl Spetzler, Jennifer Meyer und Claudia von Winter formalisierten das Sechs-Elemente-Modell in "Decision Quality: Value Creation from Better Business Decisions" (2016). Die Strategic Decisions Group (SDG) wendet das Framework seit über 30 Jahren auf Unternehmensentscheidungen an.
10-15 Minuten für eine Einzelprüfung. 20-30 Minuten, wenn ein Team von 4-6 Personen unabhängig prüft und dann vergleicht. Die Vergleichsdiskussion ist, wo der echte Wert entsteht, also nicht überspringen. Für Entscheidungen mit hohem Einsatz kann ein 30-Minuten-DQ-Check Monate verschwendeter Arbeit verhindern.
Diese Meinungsverschiedenheit IST das Ergebnis. Wenn drei Personen "Information" als stark bewerten, aber eine als schwach, hat diese Person eine Datenlücke identifiziert, die die anderen übersehen haben. Die Meinungsverschiedenheit klären, bevor weitergemacht wird.
Der volle 6-Elemente-Check ist für Entscheidungen mit bedeutenden Konsequenzen gedacht. Für Alltagsentscheidungen reicht ein schneller mentaler Scan der Top 3 Elemente (Framing, Alternativen, Commitment) in 2 Minuten und deckt trotzdem die häufigsten Fehler ab. Faustregel: Wenn die Entscheidung schwer umkehrbar ist, die volle Checkliste durchlaufen.
Entscheidungsqualität prüft, ob dein Prozess solide ist. Die Entscheidungsmatrix ist eines der Werkzeuge innerhalb dieses Prozesses (sie adressiert das Element "Logik", indem sie die Bewertung von Optionen strukturiert). DQ ist der Meta-Check: Bevor du eine Entscheidungsmatrix durchführst, verifiziere, dass Framing stimmt, genug Alternativen vorhanden sind, ausreichend Information vorliegt, Werte definiert sind und die richtigen Leute einbezogen werden.