Warum Unternehmen schlechte Entscheidungen treffen – und wie es besser geht

Veröffentlicht auf stagl.systems

Jedes Unternehmen trifft täglich Hunderte von Entscheidungen. Welches Tool wird eingeführt? Migrieren wir in die Cloud oder bleiben wir On-Premises? Bauen wir selbst oder kaufen wir zu? Die meisten dieser Entscheidungen werden nicht durch strukturierte Analyse getroffen, sondern durch Gewohnheit, Hierarchie oder den Lautesten im Raum. Das Ergebnis: Projekte, die niemand wollte, Architekturen, die niemand versteht, und Budgets, die in Lösungen fließen, die das eigentliche Problem gar nicht adressieren.

Dieser Beitrag zeigt, wie Entscheidungen in der Praxis typischerweise ablaufen, warum diese Muster so gefährlich sind und welche Methoden tatsächlich zu besseren Ergebnissen führen.

Wie Entscheidungen in der Realität ablaufen

Die HiPPO-Entscheidung

HiPPO steht für „Highest Paid Person’s Opinion” – und beschreibt eine der häufigsten Dynamiken in Unternehmen. Eine Führungskraft äußert in einem Meeting eine Präferenz, und ab diesem Moment arbeitet das gesamte Team daran, diese Präferenz zu rechtfertigen. Gegenargumente werden nicht mehr ernsthaft vorgebracht, weil niemand dem Chef widersprechen will.

In der IT-Welt sieht das oft so aus: Ein CTO liest einen Artikel über eine bestimmte Technologie, erwähnt sie beiläufig – und sechs Monate später hat das Team einen Proof of Concept gebaut, ohne je systematisch evaluiert zu haben, ob diese Technologie zum konkreten Problem passt.

Die Konsens-Falle

Das Gegenstück zur HiPPO-Entscheidung ist die endlose Suche nach Konsens. Alle müssen einverstanden sein, bevor etwas passiert. Das klingt demokratisch, führt aber in der Praxis dazu, dass Entscheidungen entweder massiv verzögert werden oder zum kleinsten gemeinsamen Nenner verwässern. Am Ende bekommt man eine Lösung, mit der niemand unzufrieden ist – aber auch niemand zufrieden.

Besonders in größeren Organisationen mündet dieses Muster häufig in Endlos-Meetings, in denen dieselben Argumente immer wieder durchgekaut werden, ohne dass jemand den Entschluss fasst, eine Richtung einzuschlagen.

Die Bauchgefühl-Entscheidung

„Ich hab da ein gutes Gefühl” ist ein Satz, der in vielen Unternehmen als ausreichende Begründung für Investitionen im sechsstelligen Bereich durchgeht. Intuition hat durchaus ihren Platz – aber nur, wenn sie auf relevanter Erfahrung basiert. Wer seit 15 Jahren Datenbanken betreibt, hat berechtigte Intuition bei der Wahl eines Datenbanksystems. Wer als Vertriebsleiter die Datenbankarchitektur mitbestimmt, hat das nicht.

Das Problem an Bauchgefühl-Entscheidungen ist nicht die Intuition selbst, sondern dass sie sich jeder Überprüfbarkeit entzieht. Wenn die Entscheidung schiefgeht, kann niemand nachvollziehen, auf welcher Grundlage sie getroffen wurde.

Die Hype-Entscheidung

Eng verwandt mit dem Bauchgefühl ist die Entscheidung nach aktuellem Hype. Kubernetes, weil alle Kubernetes machen. GenAI, weil der Wettbewerb GenAI macht. Microservices, weil Microservices modern sind. Die Frage „Löst das unser konkretes Problem?” wird dabei systematisch übersprungen.

Besonders in der aktuellen KI-Welle sieht man das ständig: Unternehmen investieren in LLM-Infrastruktur, ohne einen einzigen Use Case identifiziert zu haben, der über eine bessere Suchfunktion hinausgeht. Das Ergebnis sind teure GPU-Cluster, die nach der initialen Begeisterung im Leerlauf vor sich hin rechnen.

Die Vendor-Lock-in-Entscheidung

Ein Anbieter macht ein überzeugendes Pitch-Deck. Die Demo sieht fantastisch aus. Der Vertrieb verspricht nahtlose Integration, minimalen Aufwand, maximalen Nutzen. Der Vertrag wird unterschrieben, und erst danach stellt sich heraus, dass die Integration alles andere als nahtlos ist, dass die versprochenen Features erst in der Enterprise-Lizenz enthalten sind und dass die Daten in einem proprietären Format liegen, das den Wechsel praktisch unmöglich macht.

Dieses Muster ist besonders in der DACH-Region relevant, wo viele mittelständische Unternehmen IT-Entscheidungen an externe Berater delegieren, die ihrerseits Partnerschaften mit bestimmten Anbietern pflegen.

Warum diese Muster so hartnäckig sind

Diese Entscheidungsmuster halten sich nicht, weil die beteiligten Menschen inkompetent wären. Sie halten sich, weil sie kurzfristig funktionieren. Die HiPPO-Entscheidung ist schnell. Konsenssuche vermeidet Konflikte. Bauchgefühl erspart Analyseaufwand. Hype-Entscheidungen lassen sich gegenüber dem Vorstand leicht verkaufen. Und der Vendor übernimmt bequem die Verantwortung.

Das eigentliche Problem liegt tiefer: In vielen Unternehmen fehlt eine Kultur, in der Entscheidungen explizit als Entscheidungen behandelt werden – mit klar definierten Kriterien, nachvollziehbarer Begründung und einem Verantwortlichen, der auch nach zwölf Monaten noch zu seiner Wahl steht.

Wie man wichtige Entscheidungen richtig trifft

1. Die Entscheidung als solche erkennen

Der erste Schritt klingt banal, wird aber regelmäßig übersprungen: Bewusstsein dafür schaffen, dass gerade eine Entscheidung getroffen wird. Viele Weichenstellungen passieren implizit – jemand legt in einem Ticket eine Architektur fest, ein Team wählt eine Bibliothek, eine Abteilung beginnt mit einem Tool zu arbeiten. Wenn niemand explizit sagt „Das ist eine Entscheidung, die Konsequenzen hat”, wird sie auch nicht als solche behandelt.

Eine hilfreiche Faustregel: Wenn eine Entscheidung schwer oder teuer rückgängig zu machen ist, verdient sie einen strukturierten Prozess.

2. Die Entscheidung richtig einordnen

Nicht jede Entscheidung braucht denselben Prozess. Jeff Bezos unterscheidet zwischen Typ-1-Entscheidungen (irreversibel, hohe Tragweite) und Typ-2-Entscheidungen (reversibel, begrenzte Auswirkung). Typ-1-Entscheidungen brauchen gründliche Analyse. Typ-2-Entscheidungen brauchen Geschwindigkeit.

Die Wahl eines Cloud-Providers für die zentrale Infrastruktur ist eine Typ-1-Entscheidung. Die Wahl eines Linting-Tools ist eine Typ-2-Entscheidung. Viele Organisationen behandeln beides gleich – entweder alles mit übertriebener Gründlichkeit oder alles aus dem Bauch heraus.

3. Kriterien vor Optionen definieren

Bevor man Lösungen evaluiert, muss klar sein, was eine gute Lösung ausmacht. Welche Anforderungen sind Muss-Kriterien, welche sind Kann-Kriterien? Wie werden sie gewichtet?

Diese Kriterien sollten schriftlich festgehalten werden, bevor die erste Demo stattfindet oder das erste Angebot eingeholt wird. Denn sobald man eine konkrete Lösung vor Augen hat, verschiebt sich die Bewertung unbewusst zugunsten dieser Lösung. Man sucht plötzlich nach Gründen, warum genau dieses Tool passt, statt neutral zu prüfen, ob es die Anforderungen tatsächlich erfüllt.

4. Den Advocatus Diaboli institutionalisieren

Jede wichtige Entscheidung braucht jemanden, dessen explizite Aufgabe es ist, die Gegenposition zu vertreten. Nicht als destruktiver Nörgler, sondern als strukturierte Qualitätssicherung. Amazon nennt das den „Disagree and Commit”-Ansatz – aber vor dem Commit muss das Disagree tatsächlich stattfinden.

In der Praxis kann das ein fester Punkt im Entscheidungsprozess sein: Bevor eine Architekturentscheidung final wird, muss mindestens eine Person dokumentieren, warum man es anders machen sollte. Wenn niemand Gegenargumente findet, hat man entweder nicht gründlich genug nachgedacht oder eine offensichtlich richtige Entscheidung vor sich – letzteres ist seltener, als man denkt.

5. Entscheidungen dokumentieren

Eine Entscheidung, die nicht dokumentiert ist, existiert nicht. Oder schlimmer: Sie existiert in fünf verschiedenen Versionen in fünf verschiedenen Köpfen. Architecture Decision Records (ADRs) sind ein bewährtes Format: Was wurde entschieden? Warum? Welche Alternativen wurden betrachtet? Welche Risiken wurden akzeptiert?

Das klingt nach Bürokratie, spart aber langfristig enorm viel Zeit – nämlich dann, wenn sechs Monate später jemand fragt, warum man sich damals für PostgreSQL statt MongoDB entschieden hat, und niemand mehr die Antwort kennt.

Psychologische Phänomene, die Entscheidungen verzerren

Hinter den beschriebenen Mustern stecken keine Charakterschwächen, sondern gut erforschte kognitive Verzerrungen. Wer sie kennt, kann sich zumindest teilweise dagegen wappnen.

Confirmation Bias – Die selektive Wahrnehmung

Menschen suchen instinktiv nach Informationen, die ihre bestehende Meinung bestätigen, und blenden Widersprüche aus. In der IT-Entscheidungsfindung zeigt sich das klassisch bei Tool-Evaluierungen: Ein Teamlead hat bereits eine Präferenz und liest drei Blogposts, die diese Präferenz stützen. Die zwei kritischen Erfahrungsberichte auf Seite zwei der Suchergebnisse werden überscrollt.

Besonders tückisch wird der Confirmation Bias in Kombination mit der HiPPO-Dynamik. Wenn die Führungskraft eine Richtung vorgibt, sucht das gesamte Team nur noch nach bestätigenden Daten – nicht aus Opportunismus, sondern weil das Gehirn es automatisch tut.

Sunk Cost Fallacy – Die Falle der versunkenen Kosten

„Wir haben schon so viel investiert, jetzt können wir nicht mehr aufhören.” Dieser Satz hat mehr gescheiterte Projekte am Leben gehalten als jedes andere Argument. Rational betrachtet sind bereits getätigte Investitionen für zukünftige Entscheidungen irrelevant – was zählt, ist ausschließlich der erwartete Nutzen ab jetzt. Emotional ist es aber extrem schwer, ein Projekt zu beenden, in das man bereits zwölf Monate Arbeit und 200.000 Euro gesteckt hat.

In der Softwareentwicklung sieht man das besonders bei Legacy-Migrationen: Ein Rewrite wird begonnen, läuft aus dem Ruder, und statt ehrlich zu evaluieren, ob der alte Ansatz doch besser war, wird immer weiter in den neuen investiert – weil ja schon so viel Arbeit drinsteckt.

Anchoring – Der erste Eindruck dominiert

Der Ankereffekt beschreibt die Tendenz, sich bei Entscheidungen überproportional am ersten verfügbaren Datenpunkt zu orientieren. Wenn ein Vendor in seiner ersten Präsentation eine Zahl nennt – sei es ein Preis, eine Performance-Kennzahl oder eine Implementierungsdauer – wird diese Zahl zum Referenzpunkt, an dem alle folgenden Informationen gemessen werden.

Das erklärt auch, warum die Reihenfolge von Präsentationen bei Ausschreibungen oft entscheidend ist. Das erste Tool, das man sieht, setzt den Standard. Alles danach wird unbewusst daran gemessen, statt an den vorher definierten Kriterien.

Gruppendenken – Der Druck zur Konformität

In eng zusammenarbeitenden Teams entsteht häufig ein impliziter Druck, keine abweichenden Meinungen zu äußern. Nicht weil Widerspruch bestraft wird, sondern weil die soziale Zugehörigkeit zum Team wichtiger erscheint als die sachliche Richtigkeit der Entscheidung. Das Ergebnis: Alle nicken, niemand hat wirklich zugestimmt, und hinterher sagt jeder „Ich hatte da schon Bedenken”.

Gruppendenken wird verstärkt durch Zeitdruck, hohe Teamkohäsion und das Fehlen strukturierter Dissens-Mechanismen. Genau deshalb ist der oben beschriebene Advocatus Diaboli so wichtig – er gibt dem Widerspruch eine legitime Rolle.

Dunning-Kruger-Effekt – Überschätzung der eigenen Kompetenz

Menschen mit oberflächlichem Wissen in einem Gebiet neigen dazu, ihre Kompetenz systematisch zu überschätzen. In der IT-Entscheidungsfindung zeigt sich das, wenn Stakeholder ohne technischen Hintergrund nach einem Konferenzvortrag oder einem Artikel glauben, die Implikationen einer Technologieentscheidung vollständig zu verstehen.

Das Gegenstück ist ebenso problematisch: Echte Experten unterschätzen häufig, wie komplex ihre Argumente für andere sind, und scheitern daran, ihre Bedenken verständlich zu kommunizieren. So entsteht eine Dynamik, in der die Überzeugten laut reden und die Kompetenten schweigen.

Status-Quo-Bias – Die Angst vor Veränderung

Menschen bevorzugen den aktuellen Zustand gegenüber Veränderung, selbst wenn die Veränderung objektiv besser wäre. In Unternehmen äußert sich das als „Das haben wir schon immer so gemacht” oder „Never change a running system”. Bestehende Lösungen werden nicht deshalb beibehalten, weil sie die besten sind, sondern weil der Wechsel Aufwand, Unsicherheit und Risiko bedeutet.

Der Status-Quo-Bias ist besonders gefährlich, weil er sich als Vorsicht tarnt. Wer für das Bestehende argumentiert, klingt vernünftig und risikoavers. Dass Stillstand selbst ein Risiko ist – nämlich das Risiko, den Anschluss zu verlieren – wird dabei systematisch unterschätzt.

Die Rolle vergangener Entscheidungen

Vergangene Entscheidungen sind mehr als Geschichte. Sie formen aktiv, wie heutige Entscheidungen getroffen werden – oft auf Wegen, die den Beteiligten gar nicht bewusst sind.

Pfadabhängigkeit – Gefangen in alten Gleisen

Jede technische Entscheidung schränkt den Raum zukünftiger Entscheidungen ein. Wer sich vor fünf Jahren für ein bestimmtes ERP-System entschieden hat, hat damit nicht nur eine Softwarelizenz gekauft, sondern auch Integrationen, Schulungen, Prozesse und Datenstrukturen geschaffen, die alle auf diesem System aufbauen. Die nächste Entscheidung wird nicht mehr frei getroffen, sondern im Kontext dieser bestehenden Abhängigkeiten.

Das ist nicht per se schlecht – Pfadabhängigkeit schafft auch Stabilität und Effizienz. Problematisch wird es, wenn die ursprüngliche Entscheidung unter völlig anderen Voraussetzungen getroffen wurde und man sie trotzdem als gegeben hinnimmt, statt sie in Frage zu stellen.

Commitment Escalation – Wenn Scheitern keine Option ist

Eng verwandt mit der Sunk Cost Fallacy, aber mit einer zusätzlichen sozialen Dimension: Wer eine Entscheidung öffentlich vertreten hat, wird sie verteidigen – auch gegen besseres Wissen. Führungskräfte, die ein Projekt vor dem Vorstand angekündigt haben, werden alles tun, um es als Erfolg darzustellen. Teams, die eine Technologie gewählt und intern evangelisiert haben, werden Probleme herunterspielen.

Diese Dynamik erklärt, warum so viele IT-Projekte erst dann als gescheitert erklärt werden, wenn es wirklich nicht mehr anders geht – oft Jahre nachdem Insider die Probleme bereits erkannt haben. Die psychologischen Kosten des Eingestehens sind zu hoch.

Survivorship Bias – Wir lernen von den Falschen

Unternehmen orientieren sich bei Entscheidungen gerne an Erfolgsgeschichten: „Netflix macht das so”, „Spotify hat das auch eingeführt”. Dabei wird übersehen, dass man nur von den Unternehmen hört, bei denen es funktioniert hat. Die hundert Firmen, die denselben Ansatz versucht und gescheitert sind, schreiben keine Blogposts und halten keine Konferenzvorträge.

In der Praxis führt das dazu, dass Architekturen und Methoden kopiert werden, die unter ganz anderen Voraussetzungen entstanden sind. Microservices funktionieren bei Netflix – einem Unternehmen mit tausenden Entwicklern und spezifischen Skalierungsanforderungen. Das heißt nicht, dass sie für ein 15-Personen-Team die richtige Wahl sind.

Erfahrungstransfer – Narben statt Daten

Vergangene negative Erfahrungen prägen zukünftige Entscheidungen oft stärker als jede Analyse. Wer einmal ein desaströses Cloud-Migrationsprojekt erlebt hat, wird bei der nächsten Cloud-Entscheidung übervorsichtig reagieren – unabhängig davon, ob die Umstände vergleichbar sind. Wer einmal von einem Open-Source-Projekt im Stich gelassen wurde, wird automatisch kommerzielle Lösungen bevorzugen.

Diese „Narben” sind menschlich verständlich, aber als Entscheidungsgrundlage gefährlich. Sie ersetzen systematische Analyse durch emotionale Reaktion und behandeln Einzelfälle als allgemeingültige Regeln.

Fazit: Entscheidungen als Disziplin begreifen

Gute Entscheidungen sind kein Talent, sondern eine Disziplin. Sie erfordern Struktur, Transparenz und die Bereitschaft, sich mit den eigenen kognitiven Schwächen auseinanderzusetzen. Das bedeutet nicht, dass jede Entscheidung ein wochenlanges Analyseprojekt werden muss. Es bedeutet, dass man bewusst entscheidet, welche Entscheidungen welchen Prozess verdienen.

Die wichtigsten Prinzipien zusammengefasst: Irreversible Entscheidungen langsam treffen, reversible schnell. Kriterien definieren, bevor man Optionen evaluiert. Gegenargumente aktiv suchen statt passiv abwarten. Entscheidungen dokumentieren, damit sie nachvollziehbar bleiben. Und vor allem: Anerkennen, dass vergangene Entscheidungen und psychologische Muster die eigene Urteilsfähigkeit beeinflussen – nicht als Schwäche, sondern als Eigenschaft des menschlichen Denkens, mit der man professionell umgehen kann.

Wer das beherzigt, wird nicht jede Entscheidung richtig treffen. Aber deutlich weniger falsch.