RAKI
RAKI ist eine Verantwortlichkeits- und Kommunikationsmatrix zur klaren Zuordnung von Rollen bei Aufgaben, Entscheidungen und Deliverables (nahe verwandt mit RACI/RAM).
Klassifikation
- KomplexitätMittel
- AuswirkungOrganisatorisch
- EntscheidungstypDesign
- OrganisationsreifeFortgeschritten
Technischer Kontext
Prinzipien & Ziele
Use Cases & Szenarien
Kompromisse
- Mehrere A pro Aufgabe führen zu Konflikten und Entscheidungsstau
- RAKI wird als Bürokratie wahrgenommen, wenn es nicht in echte Arbeitsprozesse integriert ist
- Matrix wird einmal erstellt, aber nicht gepflegt (veraltete Wahrheit)
- A pro Item strikt auf genau eine Instanz begrenzen
- Matrix auf sinnvolle Granularität beschränken (nicht alles aufnehmen)
- Regelmäßige Reviews bei organisatorischen Änderungen einplanen
I/O & Ressourcen
- Aufgaben/Deliverables oder Entscheidungsgegenstände
- Rollen/Teams/Stakeholder
- Rahmenbedingungen (Governance, Prozesse, Schnittstellen)
- RAKI-Matrix (dokumentiert und abgestimmt)
- Klare Kommunikations- und Eskalationswege
- Reduzierte Koordinations- und Abstimmungskosten
Beschreibung
RAKI wird eingesetzt, um für Aufgaben, Entscheidungen oder Artefakte festzulegen, wer ausführt (R), wer die finale Verantwortung trägt (A), wer zu konsultieren ist (K/C) und wer informiert wird (I). Damit reduziert RAKI Unklarheiten, Doppelarbeit und Entscheidungsstau. In der Praxis entspricht RAKI funktional dem verbreiteten RACI-/RAM-Modell (Responsible, Accountable, Consulted, Informed) und wird häufig in Projekten, Governance-Strukturen und Organisationsschnittstellen genutzt.
✔Vorteile
- Reduzierte Unklarheiten und Doppelarbeit
- Schnellere Entscheidungen durch klare Accountability
- Bessere Zusammenarbeit und planbare Kommunikation
✖Limitationen
- RAKI klärt Zuständigkeiten, ersetzt aber keine fachlichen Entscheidungen oder Priorisierung
- Zu feingranulare Matrizen erzeugen Pflegeaufwand und verlieren Akzeptanz
- Ohne klare Rollenbeschreibung bleibt die Matrix interpretationsanfällig
Trade-offs
Metriken
- Entscheidungsdurchlaufzeit
Zeit von der Entscheidungseinreichung bis zur finalen Entscheidung (A).
- Anzahl Eskalationen pro Entscheidung
Wie oft Entscheidungen eskalieren müssen, weil Zuständigkeiten unklar sind.
- Rework durch Verantwortlichkeitsunklarheit
Aufwände, die durch Missverständnisse zu Zuständigkeiten entstehen (z. B. doppelte Umsetzung).
Beispiele & Implementierungen
RAKI für Architekturentscheidungen
Ein Unternehmen nutzt RAKI, um für ADRs festzulegen, wer die Analyse macht (R), wer final entscheidet (A), welche Expert:innen konsultiert werden (K) und welche Teams informiert werden (I).
RAKI für Plattform- und Produkt-Schnittstellen
RAKI macht transparent, wer für gemeinsame Schnittstellen verantwortlich ist und wer bei Changes eingebunden werden muss.
RAKI für agile Teams
RAKI hilft agilen Teams, Verantwortlichkeiten klar zu definieren und Kommunikationswege zu verbessern.
Implementierungsschritte
Scope festlegen: Welche Aufgaben/Deliverables/Entscheidungen sollen abgedeckt werden?
Rollen/Stakeholder sammeln und Rollenverständnis klären
RAKI pro Item zuordnen und Konflikte moderieren (A ist kritisch)
⚠️ Technische Schulden & Engpässe
Tech Debt
- RAKI ist nicht versioniert und wird bei Änderungen nicht aktualisiert
- Entscheidungs- und Kommunikationswege sind implizit statt dokumentiert
- Unklare Ownership führt zu wiederkehrenden Rework-Schleifen
Bekannte Engpässe
Beispiele für Missbrauch
- RAKI als Mikromanagement oder Kontrollinstrument einsetzen
- RAKI ohne echtes Buy-in der Verantwortlichen definieren
- RAKI auf alle Details anwenden und damit Bürokratie erzeugen
Typische Fallen
- Rolle vs. Person vermischen (Matrix sollte rollenbasiert sein)
- R und A verwechseln (Ausführung vs. finale Verantwortung)
- Informed (I) als Mitentscheidung interpretieren
Erforderliche Fähigkeiten
Drivers (Architectural Drivers)
Constraints
- • Bestehende Governance-Strukturen und Gremien
- • Rollen- und Stellenbeschreibungen
- • Zeitbudget für Abstimmung