Ein Vorstand entscheidet sich für ein Engineering-Tool — gegen die ausdrückliche, schriftlich begründete Empfehlung der eigenen Technik. Drei Jahre später: Reaktionszeiten bis zu 50% der Tahgesarbeitszeit. Das Tool ist immer noch im Einsatz. Eskalationen, Entwicklerteams…. Keine Änderung des Tools.
Für dieses Muster gibt es noch keinen etablierten Namen. Ich nenne es die Tool Fallacy — in Anlehnung an die Sunk Cost Fallacy, aber sie ist mehr als das.
Die These#
Jede Tool-Entscheidung ohne explizite Funktionsdefinition und ohne Mess-Merkmale ist eine Wette.
Das ist falsifizierbar: Zeigen Sie mir eine Organisation, die ohne vorher formulierte Funktion (“was soll das Ding leisten, für wen, woran gemessen?”) dauerhaft die richtige Tool-Wahl trifft. Ich kenne keine. Ich kenne aber viele, die mit dem Marktführer unglücklich sind und es nicht messen können — weil nie definiert wurde, was “glücklich” bedeutet hätte.
Was die Tool Fallacy ist — und was nicht#
Zunächst die Abgrenzung, denn ein Einwand liegt nahe: “Das gibt es doch schon, das ist Maslows Hammer.” Nein. Das Law of the Instrument — wer nur einen Hammer hat, sieht überall Nägel — beschreibt das Problem, ein vorhandenes Tool für alles zu benutzen. (Exel) Die Tool Fallacy beschreibt das Gegenteil: ein vorhandenes Tool trotz Evidenz zu behalten. Der Hammer-Besitzer überschätzt sein Werkzeug. Der Tool-Fallacy-Betroffene weiß längst, dass es nicht funktioniert — und die Organisation behält es trotzdem.
Dahinter steckt kein einzelner Denkfehler, sondern eine Kobunationaus vier Mechanismen, die sich nur im Symptom treffen:
1. Escalation of Commitment. Die echte Sunk-Cost-Verwandte. “Wir haben die Integration schon bezahlt, jetzt ziehen wir es durch.” Je teurer die Einführung war, desto unmöglicher wird der Abbruch. Und das selbst wenn die versenkten Kosten für die Zukunftsentscheidung irrelevant sind. Das Wechselrisiko wird gegen null Alternativkosten gerechnet, weil die Kosten des Bleibens nirgends erfasst werden.
2. Authority Displacement. Tool-Entscheidungen sind “Chefsache”. Das ist erst einmal richtig — Budget, Vertragslaufzeit, strategische Bindung gehören nach oben. Aber Chefsache absorbiert dabei still die Fachsache: Die Frage “welches Tool” wird auf der Ebene entschieden, auf der die Frage “wofür eigentlich” nie gestellt wurde. Wenn der Vorstand gegen die explizite Empfehlung der Technik entscheidet, ist das kein kognitiver Bias mehr. Das ist dimplomatisch ausgedrückt ein Governance-Fehler.
3. Social Proof. “Wir nehmen den Marktführer.” Der moderne Nachfahre von Nobody ever got fired for buying IBM. Die Entscheidung fühlt sich sicher an, weil viele sie getroffen haben — nicht, weil sie zur eigenen Funktion passt. Die Frage “braucht ihr das überhaupt?” wird durch die Frage “was nehmen die anderen?” ersetzt.
4. Fossilisierung. Der leiseste Mechanismus. Kein aktiver Fehler, kein Drama — nur: niemand misst mehr, ob das Tool noch die Funktion erfüllt. Wer 2026 noch mit einem Requirements-Werkzeug aus einer anderen Ära arbeitet, hat irgendwann einmal eine vielleicht sogar richtige Entscheidung getroffen. Die Welt hat sich geändert. Das Mess-Signal, das den Drift gemeldet hätte, existiert nicht.
Der stärkste Einwand — ernst genommen#
Bevor ich die Marktführer-Entscheidung kritisiere: Sie ist aus Sicht des Entscheiders rational. Das muss man anerkennen, sonst argumentiert man am Problem vorbei.
Der Marktführer bietet ein Ökosystem. Es gibt Personal am Markt, das ihn kennt. Der Hersteller wird in fünf Jahren noch existieren. Integrationen sind versprochen. Und — nicht zynisch, sondern realistisch — die Entscheidung ist karrieresicher: Scheitert das Projekt mit dem Marktführer, lag es am Projekt. Scheitert es mit dem Nischenanbieter, lag es an der Tool-Wahl.
Auch das Wechselrisiko ist real, nicht eingebildet. Migration kostet, Schulung kostet, die Übergangsphase kostet doppelt. Wer “wechselt einfach” ruft, hat noch keinen Wechsel verantwortet.
Der Konter liegt woanders: Diese Rationalität optimiert das Risiko des Entscheiders, nicht die Lebensfähigkeit der Organisation. Beides kann zusammenfallen — tut es aber nur, wenn die Funktion vorher definiert wurde. Ohne Funktionsdefinition ist die Marktführer-Wahl nicht falsch, sie ist unprüfbar. Und unprüfbare Entscheidungen verrotten garantiert.
Der strukturelle Blick: ein eingefrorener Lösungs-Block#
In meinem Lebensfähigkeitsmodell ist ein Tool eine Lösung, die eine Funktion realisieren soll, und die Funktion wird durch Merkmale gemessen. Die Tool Fallacy hat darin eine präzise Struktur — sie ist kein diffuses “schlechtes Bauchgefühl”, sondern zwei fehlende Kanten:
- “Wir nehmen den Marktführer” heißt: Die Lösung wurde gewählt, ohne dass die Funktion je artikuliert wurde. Die Kante Lösung realisiert Funktion zeigt ins Leere — es gibt keine Funktion, gegen die man prüfen könnte.
- Das vermodernde Requirements-Tool heißt: Die Kante Merkmal misst Funktion fehlt. Ohne Merkmal kein Drift-Signal. Ohne Drift-Signal friert der Block ein, und niemand merkt es — bis ein neuer Mitarbeiter fragt, warum das hier so aussieht wie 2009.
- Vorstand gegen Technik heißt: Das Drift-Signal aus der Quelle Mensch ist angekommen — und wurde verworfen. Der Block bleibt eingefroren, jetzt mit Ansage.
Ein Tool, das nicht an eine formulierte Funktion und ein Mess-Merkmal gebunden ist, kann gar nicht “gut” oder “schlecht” sein. Es ist unbewertet. Daraus wird die Interimslösung, und die hält bekanntlich am Längsten.
“Ein Tool ist nur gut, wenn man es manuell kann”?#
Fast. So absolut ist der Satz falsch — niemand muss Assembler von Hand schreiben können, um einen Compiler sinnvoll zu nutzen. Die haltbare Fassung lautet:
Man muss die Methode beherrschen, die das Tool automatisiert — nicht die Mechanik.
Wer FMEA nicht als Methode versteht, produziert mit dem teuersten FMEA-Tool schneller mehr Müll. Wer Anforderungen nicht formulieren kann, verwaltet mit dem besten Requirements-Tool präzise dokumentierten Unsinn. Das Tool amplifiziert Methodenkompetenz — in beide Richtungen. Grady Booch hat es vor Jahrzehnten auf den Punkt gebracht: A fool with a tool is still a fool. Man darf ergänzen: ein schnellerer.
Deshalb beginnt die Tool Fallacy nicht beim Tool-Kauf. Sie beginnt eine Ebene früher — bei der nie gestellten Frage, welche Methode hier eigentlich unterstützt werden soll.
Payload: Die Entscheidung messbar und reversibel machen#
Die Antwort auf die Tool Fallacy ist nicht “wechselt sofort” und auch nicht “kauft nie den Marktführer”. Beides wäre nur die nächste unprüfbare Entscheidung. Die Antwort ist ein Verfahren:
1. Funktion vor Lösung. Bevor ein Tool-Name fällt: Was ist das Problem?
- Welche Funktion soll erfüllt werden,
- für wen?
Wenn diese Frage nicht in zwei Sätzen beantwortbar ist, ist jede Tool-Diskussion verfrüht. “Braucht ihr das überhaupt?” ist keine rhetorische Frage — sie ist der erste Prüfschritt.
2. Merkmale vor Vertragsunterschrift. Woran messen wir in zwölf Monaten, ob die Lösung die Funktion erfüllt? Mögliche Antworten:
- Antwortzeit
- Durchlaufzeit
- Adoptionsquote
- Fehlerrate
— konkret, mit Zahl und mit VORHER festgelegter Messmethode. Ein Tool ohne definiertes Mess-Merkmal ist per Konstruktion unfalsifizierbar, und Unfalsifizierbares verrottet.
3. Pilot mit Exit-Kriterien. Nicht “Pilotprojekt zur Akzeptanzsteigerung” — das ist Verkauf, kein Test. Sondern: vorher festgelegte Kriterien, bei deren Verfehlen der Pilot endet. Ein Pilot ohne definierten Abbruchpfad ist keine Erprobung, sondern eine Einführung in Raten.
Ihr werdet der Pilot (für die Gesamteinführung), da ist es schon zu spät
4. Drift-Signale institutionalisieren. Die Empfehlung der eigenen Technik ist ein Datum, kein Störgeräusch. Wer sie überstimmt, dokumentiert warum — und legt fest, welches Merkmal die Überstimmung im Nachhinein als richtig oder falsch deklarieren wird. Dann ist auch eine Entscheidung gegen die Fachebene keine Fallacy mehr, sondern eine dokumentierte, überprüfbare Wette.
Mit diesen vier Schritten darf man dann auch den Marktführer pilotieren. Nicht, weil er der Marktführer ist — sondern weil er die formulierte Funktion nachweislich am besten realisiert. Das ist der ganze Unterschied. Und er entscheidet darüber, ob Ihre Tool-Landschaft in fünf Jahren ein Werkzeugkasten ist oder ein Museum.
Der Aufwand#
Mag recht groß sein, aber rechnen Sie die “anderen Kosten” dagegen, sind Sie signifikant günstiger, wenn Sie diesen Weg gehen.
Chefsache bleibt die Tool-Entscheidung trotzdem — aber Chefsache heißt dann: dafür sorgen, dass die vier Schritte vor der Unterschrift systematisch und dokumentiert stattgefunden haben.