Diese Seite ist auch verfügbar in:

Wie man Entscheidungsmeetings aus der Sackgasse holt – mit Jürgen Habermas, Bowtie Analysis und entscheidungsfähiger Systemarchitektur

Wer kennt dieses Muster nicht?

Ein wichtiges Entscheidungsmeeting jagt das nächste. Die gleiche Frage wird immer wieder diskutiert – nur mit leicht veränderten Teilnehmern, neuen Slides und einem frischen Datenpunkt hier und da.

Man einigt sich darauf, dass man sich noch nicht einigen kann.

Also wird der Kreis erweitert. Dann wieder verkleinert. Neue Perspektiven werden eingeladen, alte verworfen. Zwischenzeitlich kippt die Stimmung: Mal scheint Option A vernünftig, dann wieder Option B.

Das Management schaut auf die Diskussion und sieht vor allem eines: Unsicherheit.

Die Konsequenzen sind nicht klar. Die Argumente widersprechen sich. Jede Entscheidung wirkt riskant.

Am Ende passiert, was in vielen Organisationen irgendwann passiert:

Ein Machtwort.

Formal ist entschieden – faktisch aber nicht.
Denn die Organisation trägt die Entscheidung nicht mit.

Das eigentliche Problem: Alle reden – aber nicht über dasselbe

Was hier schiefläuft, ist selten ein Mangel an Daten oder Kompetenz.

Das Problem ist subtiler:
Jeder bringt sein eigenes mentales Modell mit in die Diskussion.

Für den einen ist das Thema ein technisches Risiko.
Für den nächsten ein Business Case.
Für den dritten ein politisches Minenfeld.
Für den vierten eine Frage der Compliance, der Architektur oder der Lieferfähigkeit.

Und weil diese Modelle nie explizit gemacht werden, diskutiert man scheinbar über dieselbe Frage – tatsächlich aber über völlig unterschiedliche Realitäten.

Genau hier entsteht die Endlosschleife.

Die Diskussion bewegt sich nicht vorwärts, weil sie keinen gemeinsamen Gegenstand hat. Sie kreist um Meinungen, Annahmen und Bauchgefühle, ohne dass diese sauber verortet, überprüft oder gewichtet werden können.

Schritt 1: Ein gemeinsames Modell schaffen – mit Bowtie Analysis

Bevor man sinnvoll diskutieren kann, braucht man einen gemeinsamen Denkraum.

Die Bowtie Analysis ist dafür ein erstaunlich effektives Werkzeug.

Ursprünglich aus dem Risikomanagement kommend, zwingt Bowtie eine Gruppe dazu, ein Risiko strukturiert sichtbar zu machen.

In der Mitte steht das zentrale Risiko, zum Beispiel:

„Wir treffen eine falsche Release-Entscheidung.“

Links davon stehen mögliche Ursachen:

• unzureichende Datenlage
• technische Unsicherheit
• Zeitdruck
• widersprüchliche Anforderungen
• fehlende Testabdeckung
• unklare Verantwortlichkeiten

Rechts davon stehen mögliche Konsequenzen:

• Produktionsprobleme
• Umsatzverlust
• Reputationsschäden
• interne Eskalationen
• Kundenunzufriedenheit
• regulatorische Risiken

Dazwischen stehen Barrieren – also alles, was das Risiko verhindert oder abmildert:

• automatisierte Tests
• Feature Toggles
• Rollback-Mechanismen
• Monitoring
• Lasttests
• Freigabeprozesse
• technische Limits
• gestaffelte Rollouts

Der Effekt ist unmittelbar:

Plötzlich reden alle über dasselbe Bild.

Nicht mehr über diffuse Meinungen, sondern über ein explizites System aus Ursachen, Risiken, Konsequenzen und Gegenmaßnahmen.

Das ist der erste große Schritt aus der Endlosschleife.

Schritt 2: Diskussionen strukturieren – mit Habermas

Ein Modell allein löst aber noch kein Problem.
Es macht das Problem nur sichtbar.

Damit aus Sichtbarkeit eine tragfähige Entscheidung entsteht, braucht es eine saubere Form der Diskussion.

Hier wird Jürgen Habermas interessant.

Habermas’ Theorie des kommunikativen Handelns beschreibt Kommunikation nicht einfach als Austausch von Meinungen, sondern als Prozess, in dem Aussagen begründet, geprüft und verstanden werden müssen.

Übertragen auf Entscheidungsmeetings bedeutet das:

Eine Aussage darf nicht einfach im Raum stehen bleiben. Sie muss anschlussfähig werden.

Wenn jemand sagt:

„Das ist ein großes Risiko.“

Dann reicht das nicht mehr.

Die passende Frage lautet:

„Wo genau im Modell verortest du dieses Risiko?“

Ist es eine Ursache?
Eine Konsequenz?
Eine fehlende Barriere?
Eine Annahme über Systemverhalten?
Eine Sorge über Akzeptanz, Kosten oder Betrieb?

Und noch wichtiger:

Warum?

Damit verändert sich die Qualität der Diskussion fundamental.

Vom Bauchgefühl zur überprüfbaren Argumentation

Vorher klingt ein typischer Beitrag vielleicht so:

„Ich glaube nicht, dass wir releasen sollten.“

Das ist verständlich, aber schwer bearbeitbar.

Nach Bowtie und deliberativer Struktur klingt derselbe Beitrag anders:

„Ich sehe hier eine Ursache im Bowtie: Die Lasttests sind unvollständig. Meine Annahme ist, dass das System unter Peak-Last instabil wird. Die Konsequenz wäre ein Produktionsausfall. Die aktuell vorhandene Barriere reicht meiner Einschätzung nach nicht aus, weil sie nur funktional, aber nicht unter realer Last getestet wurde.“

Jetzt kann man konkret arbeiten.

Stimmt die Annahme?
Gibt es Daten dazu?
Ist die Konsequenz realistisch?
Ist die Barriere stark genug?
Welche zusätzliche Maßnahme würde das Risiko reduzieren?
Welche Entscheidung wäre unter diesen Bedingungen vertretbar?

Die Diskussion wird anschlussfähig.

Nicht, weil plötzlich alle derselben Meinung sind.
Sondern weil alle dieselbe Struktur verwenden.

Der entscheidende Effekt: Konvergenz statt Kreisbewegung

Das Zusammenspiel ist entscheidend:

Bowtie schafft ein gemeinsames Problemverständnis.
Deliberation sorgt für saubere Argumentation innerhalb dieses Modells.

Ohne Bowtie bleibt die Diskussion abstrakt.
Ohne Deliberation bleibt sie politisch.

Zusammen entsteht etwas anderes:

Ein Raum, in dem Entscheidungen überhaupt möglich werden.

Nicht jede Unsicherheit verschwindet.
Aber Unsicherheit wird sichtbar, verortbar und bearbeitbar.

Das ist der Unterschied zwischen einer Diskussion, die sich im Kreis dreht, und einer Diskussion, die zur Entscheidung konvergiert.

Ein praktischer Ablauf für reale Meetings

In der Praxis ist dieser Ansatz erstaunlich unspektakulär – und genau darin liegt seine Stärke.

Zuerst wird die Entscheidungsfrage präzisiert.

Nicht:

„Was machen wir jetzt?“

Sondern klar eingegrenzt:

„Können wir Release X unter den aktuellen technischen, fachlichen und operativen Bedingungen freigeben?“

Dann baut das Team gemeinsam ein Bowtie-Modell auf.

Was ist das zentrale Risiko?
Welche Ursachen können dazu führen?
Welche Konsequenzen hätte es?
Welche Barrieren existieren bereits?
Welche fehlen?

Dieser Schritt dauert oft nur wenige Minuten, ist aber der wichtigste Teil des Meetings.

Anschließend wird diskutiert – aber nicht mehr frei schwebend.

Jede Aussage muss sich einer Ursache, einer Konsequenz, einer Barriere oder einer Annahme zuordnen lassen.

Der Moderator übernimmt dabei eine neue Rolle.

Er moderiert nicht nur Redeanteile.
Er strukturiert Kommunikation.

Er fragt nach, wenn Aussagen unklar bleiben.
Er zwingt implizite Annahmen an die Oberfläche.
Er verhindert, dass Diskussionen wieder in politische oder rein emotionale Muster zurückfallen.

Am Ende entsteht keine „gefühlte“ Entscheidung mehr, sondern eine ableitbare.

Eine Entscheidung, die auf einem gemeinsamen Verständnis basiert.

Warum das in vielen Organisationen trotzdem scheitert

Der Engpass ist selten die Methode.

Der Engpass ist oft die Organisation selbst.

Denn diese Art der Diskussion hat Nebenwirkungen:

Hierarchien verlieren kurzfristig an Einfluss.
Unsicherheit wird sichtbar.
Interessen werden explizit.
Technische Schwächen können nicht mehr hinter abstrakten Aussagen verschwinden.
Politische Argumente müssen sich an überprüfbaren Strukturen messen lassen.

Das ist unbequem.

Aber genau diese Unbequemlichkeit ist notwendig, um aus Endlosschleifen herauszukommen.

Wie wir bei ONLU helfen: Deliberation überhaupt erst möglich machen

Bis hierhin klingt alles nach Methodik.

Und genau hier liegt der Denkfehler, den wir in vielen Organisationen sehen:

Das Problem ist nicht nur die Diskussion.
Das Problem ist, dass es oft nichts gibt, worüber man sinnvoll diskutieren kann.

In der Theorie braucht deliberative Kommunikation gute Argumente.

In der Praxis brauchen gute Argumente eine beobachtbare Realität.

Und genau daran scheitert es häufig.

Daten existieren nicht.
Oder sie sind zu teuer zu erheben.
Oder sie sind über Systeme verteilt.
Oder sie sind technisch vorhanden, aber fachlich nicht interpretierbar.
Oder sie sind politisch bereits so geframed, dass niemand ihnen wirklich vertraut.

Das Ergebnis:

Meetings werden zu einem Ersatz für fehlende Beobachtbarkeit.

Man diskutiert nicht, weil es so viele Optionen gibt.
Man diskutiert, weil das System keine klare Entscheidungsgrundlage liefert.

Der eigentliche Engpass: Keine entscheidungsfähige Realität

Wenn wir in Projekte kommen, sehen wir selten „zu wenig Meetings“.

Wir sehen etwas anderes:

Systeme ohne sinnvolle Metriken.
KPIs, die nichts mit konkreten Entscheidungen zu tun haben.
Logs, die keine Kausalität abbilden.
Architekturen, die Verhalten verstecken statt sichtbar machen.
Monitoring, das technische Zustände zeigt, aber keine fachlichen Fragen beantwortet.
Reporting, das zu spät kommt, um Entscheidungen zu beeinflussen.

Und genau deshalb entstehen Endlosschleifen.

Nicht, weil Menschen schlecht entscheiden.
Sondern weil das System keine entscheidungsfähige Realität liefert.

Unser Ansatz bei ONLU: Entscheidbarkeit herstellen – nicht Meetings optimieren

Wir gehen nicht in Organisationen und sagen:

„Ihr müsst einfach besser moderieren.“

Das wäre zu kurz gedacht.

Wir setzen früher an.

Wir bauen die Grundlage, damit deliberative Kommunikation überhaupt funktionieren kann.

Denn gute Entscheidungen entstehen nicht nur durch bessere Meetings.
Sie entstehen durch Systeme, die relevante Fragen sichtbar machen.

1. Minimal-invasive Messbarkeit statt Big-Data-Träume

Ein häufiger Reflex lautet:

„Dann bauen wir halt eine große Datenplattform.“

Ein Data Warehouse.
Eine neue Analytics-Schicht.
Ein zentrales Reporting.
Ein vollständiges Observability-Programm.

Das klingt professionell, ist aber oft:

zu langsam,
zu teuer,
zu generisch,
und am Ende wieder nicht entscheidungsrelevant.

Unser Ansatz ist pragmatischer:

Welche eine Metrik entscheidet diese konkrete Frage wirklich?
Wo im System entsteht sie ohnehin schon?
Wie können wir sie minimal sichtbar machen?

Oft reichen kleine technische Eingriffe:

ein zusätzlicher Counter,
ein strukturiertes Event,
ein klareres Log,
eine Statusmeldung,
ein technischer Grenzwert,
eine fachlich interpretierbare Kennzahl.

Keine monatelangen Plattformprojekte.
Keine Big-Data-Illusion.

Sondern gezielte Sichtbarkeit genau dort, wo Entscheidungen getroffen werden.

2. Bowtie operationalisieren: Risiken messbar machen

Eine Bowtie Analysis ist nur dann wertvoll, wenn sie nicht im PowerPoint endet.

Wir helfen dabei, die Elemente technisch zu verankern.

Ursachen werden als messbare Events oder Zustände sichtbar.
Konsequenzen werden als KPIs oder Systemverhalten beobachtbar.
Barrieren werden als konkrete technische Mechanismen umgesetzt.

Zum Beispiel:

Feature Toggles.
Limits.
Rollback-Strategien.
Monitoring-Regeln.
Alerting.
Validierungen.
Automatisierte Tests.
Gestaffelte Rollouts.
Prozesskontrollen.

Damit wird aus:

„Das könnte ein Risiko sein.“

ein überprüfbares System:

„Wenn Event X passiert und Barriere Y fehlt, sehen wir Effekt Z.“

Das ist der Moment, in dem eine Diskussion kippt.

Von Meinung zu überprüfbarer Realität.

3. Architektur so bauen, dass sie Fragen beantwortet

Die meisten Architekturen beantworten keine Fragen.
Sie führen nur Code aus.

Das reicht für Betrieb, aber nicht für gute Entscheidungen.

Wir drehen das bewusst um:

Eine gute Architektur muss entscheidungsfähig sein.

Das bedeutet:

Services stellen gezielt entscheidungsrelevante Informationen bereit.
Events bilden Geschäftsprozesse nachvollziehbar ab.
KPIs entstehen entlang realer Nutzung – nicht nachträglich im Reporting.
Technische Zustände werden mit fachlichen Auswirkungen verknüpft.
Schnittstellen zeigen nicht nur Daten, sondern Kontext.

Das Ziel ist nicht Observability als Buzzword.

Das Ziel ist konkreter:

Eine Architektur, die argumentierbar ist.

Eine Architektur, bei der man nicht nur sieht, dass etwas passiert, sondern auch versteht, warum es passiert, was es bedeutet und welche Entscheidung daraus ableitbar ist.

4. Feedback-Loops verkürzen, ohne Infrastruktur-Overkill

Ein weiteres Problem:

Selbst wenn Daten existieren, kommen sie oft zu spät.

Drei Wochen später im Reporting.
Nach dem nächsten Steering Committee.
Nach der nächsten Eskalation.
Nach dem nächsten Incident.

Dann sind sie zwar interessant, aber nicht mehr entscheidungswirksam.

Deshalb setzen wir auf kurze, direkte Feedback-Loops:

kleine Releases statt großer Big-Bang-Deployments,
gezielte Experimente statt breitflächiger Rollouts,
schnelle Rückmeldung aus dem System statt verspäteter Berichte,
technische Leitplanken statt rein manueller Freigaben.

Wichtig ist dabei:

Nicht maximal skalieren.
Sondern minimal entscheidungsfähig werden.

5. Kommunikation entpolitisieren durch Sichtbarkeit

Der vielleicht größte Effekt ist kein technischer, sondern ein kultureller.

Wenn Systeme transparenter werden, verändert sich die Kommunikation.

Meinungen verlieren an Gewicht.
Argumente gewinnen an Klarheit.
Annahmen werden überprüfbar.
Risiken werden verortbar.
Entscheidungen werden nachvollziehbar.

Das reduziert politische Diskussionen drastisch.

Nicht, weil Politik verboten wird.
Sondern weil sie weniger Angriffsfläche hat.

Wenn ein System zeigt, was passiert, muss weniger darüber spekuliert werden.

Was das konkret verändert

Wenn man diesen Ansatz konsequent verfolgt, verändert sich die Rolle von Meetings.

Meetings werden nicht mehr geführt, um überhaupt Klarheit zu erzeugen.
Sie werden geführt, um auf bestehender Klarheit Entscheidungen abzuleiten.

Die Dynamik dreht sich:

Vorher:
Diskussion erzeugt vermeintliche Erkenntnis.

Nachher:
Erkenntnis zwingt zur Entscheidung.

Das ist ein fundamentaler Unterschied.

Denn eine Organisation, die ihre Realität beobachten kann, muss weniger raten.
Und eine Organisation, die weniger raten muss, kann besser entscheiden.

Fazit: Deliberation braucht Realität

Die Kombination aus Bowtie Analysis und Jürgen Habermas liefert eine starke methodische Grundlage:

Ein gemeinsames Modell.
Eine saubere Art zu diskutieren.
Eine Struktur, in der Argumente überprüfbar werden.
Eine Basis, um aus Endlosschleifen herauszukommen.

Aber ohne technische Grundlage bleibt das Theorie.

Unsere Erfahrung bei ONLU ist klar:

Das eigentliche Problem ist nicht, dass zu wenig Daten existieren.
Sondern dass die richtigen Daten zur richtigen Zeit am richtigen Ort fehlen.

Deshalb ist unser Fokus nicht, Meetings besser aussehen zu lassen.

Unser Fokus ist:

Systeme so zu bauen, dass Meetings wieder Sinn ergeben.

Oder noch direkter:

Ohne beobachtbare Realität keine deliberative Kommunikation.
Ohne deliberative Kommunikation keine tragfähigen Entscheidungen.
Und ohne tragfähige Entscheidungen keine wirksame Organisation.