DACI vs RACI: wann welches Framework

Wer schon einmal in einem 90-Minuten-Meeting sass, das mit „lass uns nächste Woche nochmal drüberreden" endete, kennt die Kosten schlechter Decision-Governance. Rollen sind unklar, Owner sind im Plural, „Alignment" wird zum Synonym für Verzögerung. Zwei Frameworks versprechen Abhilfe: RACI und DACI. Auf der Folie sehen sie ähnlich aus. Sie sind es nicht.

Dieser Artikel richtet sich an Product Manager, Engineering Manager und Operatorinnen, denen ständig Entscheidungen vor die Füsse fallen und die einen klareren Weg suchen, sie zu führen. Wir schauen uns an, was die beiden Frameworks tatsächlich sind, wo RACI bei nicht-trivialen Calls bricht, wann es trotzdem das richtige Tool ist, und wie ein DACI-Workflow in der Praxis abläuft.

Kurzauffrischung: was ist RACI?

RACI ist eine Matrix zur Verantwortungsverteilung, die in den 1970er Jahren aus dem Prozessmanagement kommt. Das Akronym steht für:

• Responsible – die Personen, die die Arbeit machen.
• Accountable – die eine Person, die das Ergebnis verantwortet und freigibt.
• Consulted – die Personen, deren Input vor der Arbeit eingeholt wird.
• Informed – die Personen, die nach Abschluss informiert werden.

RACI wurde gebaut, um abzubilden, wer in einem laufenden Prozess welchen Teil übernimmt. Denk an einen Lohnlauf, einen Quartalsabschluss, ein Onboarding-Workflow. Es beantwortet die Frage „wer macht in dieser wiederkehrenden Aktivität welchen Schritt?". Stark ist es dort, wo die Arbeit selbst klar definiert ist und die offene Frage Ausführung heisst, nicht Richtung.

Kurzauffrischung: was ist DACI?

DACI wurde Anfang der 2000er Jahre bei Intuit entwickelt und ist seitdem zum Standard-Decision-Framework bei Unternehmen wie Atlassian geworden. Das Akronym steht für:

• Driver – die eine Person, die den Entscheidungsprozess vorantreibt. Sie plant die Schritte, sammelt den Input, und bringt die Entscheidung zum Abschluss. Sie entscheidet nicht zwingend selbst.
• Approver – die eine Person, die die finale Entscheidung trifft. Oft, aber nicht immer, hierarchisch über dem Driver.
• Contributor – die Personen, deren Input die Entscheidung formt. Sie haben eine Stimme, kein Stimmrecht.
• Informed – die Personen, die das Ergebnis kennen müssen, aber nicht am Entscheid beteiligt waren.

Der Schwerpunkt verschiebt sich. DACI fragt nicht „wer macht die Arbeit?". Es fragt: „wer treibt diese Entscheidung zum Abschluss, und wer steht dafür gerade, ob die Antwort richtig war?"

Der Unterschied, der wirklich zählt

Beide Frameworks teilen eine einzelne Rolle in zwei. RACI trennt Tun von Verantworten (Responsible vs Accountable). DACI trennt Treiben von Entscheiden (Driver vs Approver). Diese zweite Trennung ist die, die für Entscheidungen den Unterschied macht, und die ist es, die RACI verwischt.

Bei RACI soll die „Accountable"-Person die Entscheiderin sein. Aber diese Rolle ist überladen: sie verantwortet das Ergebnis, gibt das Artefakt frei, und ist die Eskalationsstelle. In der Praxis führt das dazu, dass Teams „Accountable" stillschweigend an die ranghöchste verfügbare Person hängen, auch wenn sie zu weit weg von der Sache ist, um eine gute Entscheidung zu treffen. Die Entscheidung passiert dann entweder in deren Abwesenheit, wartet auf ihre Verfügbarkeit, oder wird drei Mal neu aufgerollt, weil niemand wirklich befugt war, abzuschliessen.

Die Driver/Approver-Trennung von DACI löst das. Der Driver treibt: holt die richtigen Leute zusammen, macht die Trade-offs sichtbar, formuliert eine Empfehlung, und legt sie dem Approver mit einer klaren Frage vor. Der Approver tut eine Sache: entscheiden. Diese Person muss nicht die Ranghöchste im Raum sein, nur die Richtige für genau diesen Call.

Wo RACI bei Entscheidungen leise scheitert

Drei Fehlermuster tauchen fast immer auf, wenn ein Team versucht, eine echte Entscheidung durch eine RACI-Matrix zu schicken.

1. Das Problem mit den vielen „Accountable"

RACI sieht eigentlich genau eine Accountable-Person pro Zeile vor. In der Praxis tragen Teams routinemässig zwei oder drei ein. „Engineering und Produkt sind gemeinsam accountable." „Der VP Sales und der Head of Customer Success teilen sich die Verantwortung." Das ist kein Kosmetik-Bug. Es ist die Hauptursache für stockende Entscheidungen, weil geteilte Accountability gar keine Accountability ist. Es gibt niemanden, in dessen Kalender du eine Deadline schreiben kannst.

DACI ist hier strukturell sauberer: ein Approver, fertig. Wer keinen einzelnen Approver benennen kann, hat die Entscheidung noch nicht entscheidungsreif gemacht. Allein das erzwingt ein Gespräch, das RACI dich überspringen lässt.

2. Die Veto-Falle der „Consulted"

Die „Consulted"-Rolle in RACI soll heissen „wir holen ihren Input ein". In der Praxis rutscht das zu „wir holen ihre Zustimmung ein". Sobald fünf Stakeholder consulted wurden, will keiner derjenige sein, dessen Einwand überstimmt wurde, also braucht die Accountable-Person implizit Konsens, um sich zu bewegen. Aus der Entscheidung wird eine Verhandlung über den kleinsten gemeinsamen Nenner statt über die beste verfügbare Antwort.

Die Contributor-Rolle in DACI ist ehrlicher mit dem Vertrag: du trägst bei, du entscheidest nicht. Vetorechte, wo es sie gibt, sind explizit und befristet, nicht durch Mehrdeutigkeit eingeschmuggelt.

3. Der fehlende Driver

RACI kennt keinen Driver. Das nächstliegende Pendant ist die „Responsible"-Person, aber Responsible meint „macht die Arbeit", nicht „treibt die Entscheidung". Für Ausführung ist das in Ordnung: die Arbeit selbst gibt den Takt vor. Für Entscheidungen ist es fatal. Entscheidungen bewegen sich nicht von alleine. Ohne expliziten Driver ist das Default-Ergebnis Verzögerung.

Einen Driver zu benennen ist eine der hebelstärksten Aktionen, die ein Team durchführen kann. Eine kleine strukturelle Änderung, die aus „das sollte irgendwann mal entschieden werden" ein „das wird bis Freitag entschieden, weil Anna verantwortet, dass es über die Linie kommt" macht.

Wann RACI trotzdem die richtige Wahl ist

Nichts davon heisst, dass RACI schlecht ist. Es heisst, RACI ist für ein anderes Problem gebaut. RACI ist das richtige Werkzeug, wenn:

• die Aktivität wiederkehrend und prozessförmig ist (Lohnlauf, Deployments, Incident Response, Audit-Vorbereitung).
• die offene Frage „wer macht welchen Schritt?" lautet und nicht „was sollten wir tun?".
• du eine klare Übergabekarte für einen funktionsübergreifenden Workflow brauchst.
• Compliance- oder regulatorische Doku die formale Responsible/Accountable-Trennung verlangt.

Für solche Fälle ist DACI Overkill und produziert Reibung. Du musst nicht „entscheiden", wie Lohnlauf jeden Zyklus läuft. Du musst wissen, wer welchen Schritt macht. RACI passt sauber.

Der Fehler entsteht, wenn man RACI verwendet, obwohl die echte Frage „was sollten wir tun?" lautet. Preisanpassungen, Hiring-Trade-offs, Architekturentscheidungen, GTM-Strategie, Vendor-Auswahl, Priorisierungs-Calls: das sind Entscheidungen, und Entscheidungen verdienen ein Decision-Framework.

Ein DACI-Workflow in der Praxis

So sieht ein sauberer DACI-Lauf aus, am konkreten Beispiel: ein B2B-SaaS-Team entscheidet, ob es einen Free-Tier einführt.

1. Entscheidung framen. Der Driver (eine erfahrene PM) schreibt ein Einseiten-Brief: was wird entschieden, warum jetzt, welche Constraints, wie sieht Erfolg aus, was ist die Deadline. Noch keine Optionen, keine Empfehlungen. Nur die Frage.
2. Rollen besetzen. Ein Approver (Head of Product). Drei bis fünf Contributor (Sales-Lead, Customer-Success-Lead, ein Eng-Lead, der Finance-Partner). Informed-Liste (das erweiterte Exec-Team, der Rest des Produkt-Teams).
3. Optionen mit Contributors entwickeln. Der Driver führt eine asynchrone Runde durch (geteiltes Dokument, strukturiertes Tool, 60-Minuten-Workshop), in der Contributors zwei bis vier Optionen vorschlagen und unter Druck setzen. Trade-offs werden explizit gemacht.
4. Empfehlung formulieren. Der Driver schreibt eine Empfehlung, mit Trade-offs und Dissens auf dem Protokoll. Sie geht an Approver und Contributor mit mindestens 48 Stunden Lesezeit.
5. Entscheiden. Der Approver trifft den Call. Er kann der Empfehlung folgen, eine andere Option wählen, oder mit konkreten Fragen zurückgeben. Endlos vertagen geht nicht: wenn er nicht entscheiden kann, geht die Entscheidung an seinen Approver.
6. Informieren und festhalten. Entscheidung, Begründung und Dissens werden geloggt. Die Informed-Liste bekommt eine kurze Notiz. Das Team in neun Monaten kann nachvollziehen, warum.

Gesamtdauer für eine nicht-triviale Entscheidung wie diese: typischerweise ein bis zwei Wochen, mit vielleicht vier Stunden Meeting-Zeit über alle Beteiligten verteilt. Vergleich das mit der Variante, in der derselbe Call in drei Exec-Meetings über sechs Wochen neu aufgerollt wird, weil niemand der Driver war.

Migration von RACI zu DACI

Wenn dein Team schon in RACI lebt, ist die Migration vor allem eine Umetikettierung plus eine strukturelle Änderung. Mappe die Rollen ungefähr so:

• RACI Responsible → DACI Driver, häufig.
• RACI Accountable → DACI Approver. Erzwinge das Gespräch, ob es wirklich eine Person ist.
• RACI Consulted → DACI Contributor. Mach explizit, dass sie keine Stimme haben.
• RACI Informed → DACI Informed. Gleiche Rolle, oft dieselbe Liste.

Die strukturelle Änderung, die sich auszahlt: du hörst auf, das Framework für Ausführung zu verwenden, und nutzt es nur noch für Entscheidungen. Operative Übergaben gehen zurück in RACI (oder in ein Prozessdokument). Entscheidungen bekommen die DACI-Behandlung.

Häufige DACI-Anti-Patterns

Der Wechsel zu DACI löst die zugrundeliegenden Probleme nicht von selbst. Dieselben Teams, die mit RACI gerungen haben, schleppen oft dieselben Gewohnheiten in DACI hinein. Die vier häufigsten:

• Co-Approver. „Lass Head of Product und CTO beide approven." Nein. Such einen aus. Wenn der Call wirklich an der Schnittstelle sitzt, ist Approver die Person, die die Konsequenzen trägt, wenn es schiefgeht, und die andere wird Contributor mit einem klar benannten Vetorecht.
• Der Driver, der heimlich entscheidet. Ein Driver, der eine Empfehlung schreibt und den Approver dann zum Abnicken drängt, agiert als Approver. Entweder umbenennen und ihm die Befugnis geben, oder den eigentlichen Approver in seine Rolle zurückholen.
• Contributor als Veto-Träger. Wenn die unausgesprochene Regel lautet „Contributor müssen zustimmen", hast du die RACI-Konsens-Falle in einer DACI-Hülle nachgebaut. Sei explizit: ihr Job ist, die Empfehlung besser zu machen, nicht sie zu blockieren.
• Keine Deadline. Ein DACI ohne Entscheidungsdatum ist nur ein langes Meeting. Der Driver verantwortet die Deadline. Wenn der Approver das Fenster reissen lässt, ist das selbst eine Entscheidung, die eine Eskalation wert ist.

Die Kurzfassung

Nutze RACI, wenn die Frage „wer macht welchen Teil dieses wiederkehrenden Prozesses" lautet. Nutze DACI, wenn die Frage „was sollten wir tun, und wer schliesst das ab" lautet. Die meisten Entscheidungen, die in Teams ewig im Kreis laufen, sind RACI, das auf ein DACI-Problem geklatscht wurde.

Die nützlichste Übung diese Woche: schau dir die drei grössten offenen Entscheidungen in deinem Team an und frage: wer ist der Driver, wer ist der Approver? Wenn du nicht jeweils einen benennen kannst, hast du gerade gefunden, warum diese Entscheidungen feststecken.