Eine RACI-Matrix kann eines der teuersten Probleme in Operations sichtbar machen: Alle sind beteiligt, aber niemand trägt eindeutig die Verantwortung für das Ergebnis. Die Arbeit gerät ins Stocken, weil Teams auf Entscheidungen warten, Aufgaben doppelt erledigen oder davon ausgehen, dass jemand anderes bereits den nächsten Schritt abgeschlossen hat.
Die klassische Matrix ist hilfreich, reicht aber nicht aus. Eine Tabelle kann keine laufenden Aufgaben zuweisen, Genehmigungen durchsetzen, versäumte Fristen eskalieren oder belegen, wer eine Entscheidung getroffen hat. Um die Ausführung zu verbessern, müssen Sie klare Rollen direkt mit dem Prozess verknüpfen.
Eine RACI-Matrix definiert vier unterschiedliche Prozessrollen
RACI ist ein Modell zur Zuweisung von Verantwortung. Es zeigt, wie einzelne Personen oder Teams an einem Prozess, Projekt oder einer Entscheidung beteiligt sind. Das Akronym steht für vier Rollen:
Responsible: Die Person oder das Team, die beziehungsweise das die Arbeit ausführt.
Accountable: Die einzelne Person, die für das Ergebnis rechenschaftspflichtig ist.
Consulted: Ein Stakeholder, dessen Einschätzung erforderlich ist, bevor eine Aufgabe oder Entscheidung abgeschlossen wird.
Informed: Ein Stakeholder, der informiert werden muss, aber nicht direkt beteiligt ist.
Die Unterscheidung zwischen Responsible und Accountable ist besonders wichtig. Eine Fachkraft kann für die Prüfung eines Lieferantenantrags zuständig sein, während der Einkaufsleiter die Verantwortung für die endgültige Onboarding-Entscheidung trägt.
Es kann mehrere ausführende Beteiligte geben, normalerweise sollte jedoch jede Aktivität oder jedes Ergebnis nur eine accountable Person haben. Geteilte Verantwortung bedeutet häufig, dass niemand wirklich verantwortlich ist.
RACI ist kein Organigramm
Ein Organigramm stellt Berichts- und Hierarchiestrukturen dar. Eine RACI-Matrix zeigt dagegen, wer innerhalb eines konkreten Arbeitsablaufs welche Aufgaben übernimmt.
Dieser Unterschied ist wichtig, weil operative Prozesse regelmäßig formale Berichtswege überschreiten. Am Kunden-Onboarding können Vertrieb, Finanzen, Rechtsabteilung, Operations und Customer Success beteiligt sein. Die Abteilungshierarchie verrät diesen Teams jedoch nicht, wer Vertragsausnahmen genehmigt, das Konto anlegt, Zahlungsdaten prüft oder den Starttermin kommuniziert.
Eine RACI-Matrix macht diese Erwartungen genau dort transparent, wo Teams voneinander abhängig sind.
RACI ist auch kein Workflow
Eine RACI-Matrix definiert die Beteiligung, beschreibt jedoch weder Reihenfolge und Zeitplanung noch Nachweise oder den Umgang mit Ausnahmen. Sie kann festlegen, dass Finance für eine Bonitätsprüfung zuständig ist, aber nicht:
Wann die Bonitätsprüfung beginnen soll
Welche Informationen Finance benötigt
Wo das Ergebnis dokumentiert werden soll
Was geschieht, wenn der Kunde die Prüfung nicht besteht
Wer bei einer Fristüberschreitung benachrichtigt wird
Ob nachgelagerte Arbeiten auf eine Genehmigung warten müssen
Betrachten Sie RACI als Ownership-Ebene innerhalb des Prozessdesigns, nicht als Ersatz für den Prozess. Wenn teamübergreifende Aufgaben regelmäßig zwischen Abteilungen verloren gehen, sollten Sie zuerst das zugrunde liegende Design der Übergaben verbessern und anschließend mit RACI Unklarheiten an jedem Übergang beseitigen.
Erstellen Sie die Matrix anhand von Ergebnissen, nicht anhand von Stellenbeschreibungen
Schwache RACI-Matrizen führen Abteilungen auf und übernehmen Zuständigkeiten aus Stellenbeschreibungen. Starke Matrizen beginnen mit den Ergebnissen und Entscheidungen, die für den Abschluss eines Prozesses erforderlich sind.
Die Aussage „Finance ist am Kunden-Onboarding beteiligt“ ist beispielsweise zu ungenau. „Finance validiert die Rechnungsdaten vor der Kontoaktivierung“ ist hingegen konkret genug, um die Aufgabe zuzuweisen, auszuführen und zu überprüfen.
Mit der folgenden Methode erstellen Sie eine praxisnahe RACI-Matrix.
1. Prozessgrenzen definieren
Benennen Sie das Ereignis, das den Prozess startet, und das Ergebnis, mit dem er endet. Eine klare Abgrenzung verhindert, dass die Matrix zu einer Bestandsaufnahme sämtlicher Aufgaben aller Abteilungen ausufert.
Für einen Lieferanten-Onboarding-Prozess könnte die Abgrenzung so aussehen:
Start: Eine Abteilung reicht eine Lieferantenanfrage ein.
Ende: Der genehmigte Lieferant ist im Einkaufssystem aktiv und der Anforderer wurde benachrichtigt.
Halten Sie außerdem fest, was außerhalb dieser Grenzen liegt. Vertragsverlängerungen, laufende Leistungsbewertungen und das Offboarding von Lieferanten können verwandte Prozesse sein, müssen aber nicht in dieselbe Matrix aufgenommen werden.
2. Aktivitäten und Entscheidungen in der richtigen Detailtiefe auflisten
Erstellen Sie für jede wesentliche Aktivität, Entscheidung, Genehmigung oder Übergabe eine eigene Zeile. Vermeiden Sie beide Extreme: Eine einzige Zeile für den gesamten Prozess ist zu allgemein, während eine Zeile für jeden Klick unnötigen Pflegeaufwand erzeugt.
Gute Zeilen beschreiben beobachtbare Ergebnisse, zum Beispiel:
Geschäftlichen Bedarf bestätigen
Lieferanteninformationen erfassen
Steuer- und Bankdaten validieren
Sicherheitsprüfung abschließen
Kommerzielle Bedingungen genehmigen
Lieferantendatensatz anlegen
Anforderer benachrichtigen
Wenn eine Aktivität einen anderen Owner, eine eigene Frist oder eine bedeutende Kontrollanforderung hat, verdient sie wahrscheinlich eine eigene Zeile.
3. Rollen festlegen, bevor Personen benannt werden
Verwenden Sie beständige Rollen wie Einkaufsleitung, Finance-Prüfer, Sicherheitsanalyst oder Anforderer aus der Fachabteilung. Persönliche Namen lassen die Matrix veralten, sobald jemand die Position wechselt oder das Unternehmen verlässt.
Während der Ausführung können Sie diese Rollen konkreten Personen oder Teams zuordnen. So trennen Sie ein dauerhaftes Prozessdesign von der aktuellen Personalbesetzung.
4. Zuerst die Accountability zuweisen
Bestimmen Sie zuerst für jede Zeile die accountable Person. Fragen Sie: Wer hat die Befugnis, das Ergebnis abzunehmen, eine Ausnahme zu klären und für einen Fehlschlag einzustehen?
Weisen Sie anschließend die ausführende Person und danach die konsultierten sowie informierten Stakeholder zu. Diese Reihenfolge verhindert ein häufiges Problem: Viele Personen werden einbezogen, aber der tatsächliche Owner bleibt unklar.
5. Die Matrix mit den ausführenden Personen validieren
Ein Workshop ausschließlich mit Führungskräften bildet häufig einen idealisierten Prozess ab. Prüfen Sie den Entwurf gemeinsam mit den operativ Beteiligten und fragen Sie:
Entspricht dies dem tatsächlichen Ablauf?
Kann die accountable Person die erforderliche Entscheidung treffen?
Verfügt die ausführende Person über die notwendigen Zugriffe und Informationen?
Welche Konsultationen schaffen Mehrwert und welche verursachen lediglich Verzögerungen?
Was geschieht, wenn die zugewiesene Person nicht verfügbar ist?
Bei dieser Prüfung werden meist inoffizielle Genehmigungen, verborgene Abhängigkeiten und operatives Wissen sichtbar, das in der formalen Dokumentation nicht enthalten ist.
Nutzen Sie diese RACI-Matrix-Vorlage für einen realen Prozess
Eine einfache RACI-Matrix führt Aktivitäten in Zeilen und Prozessrollen in Spalten auf. Jede Schnittstelle enthält ein R, A, C oder I oder bleibt leer.
Aktivität im Lieferanten-Onboarding | Anforderer | Einkauf | Finance | Sicherheit | Operations |
|---|---|---|---|---|---|
Geschäftlichen Bedarf bestätigen | R | A | I | I | |
Lieferanteninformationen erfassen | C | A/R | I | I | |
Steuer- und Bankdaten validieren | I | C | A/R | ||
Sicherheitsprüfung abschließen | I | C | A/R | ||
Kommerzielle Bedingungen genehmigen | C | A/R | C | I | |
Lieferantendatensatz anlegen | I | A | C | R | |
Anforderer benachrichtigen | I | A | R |
Diese Vorlage ist bewusst einfach gehalten. Sie macht Ownership sichtbar, ohne zu versuchen, jede Anweisung in der Tabelle abzubilden.
Führen Sie vor der Veröffentlichung Ihrer Matrix folgende Qualitätsprüfungen durch:
Jede Zeile hat genau eine accountable Person. Ohne Owner gibt es keinen verlässlichen Eskalationspunkt.
Jede Zeile hat mindestens eine ausführende Partei. Accountability ohne ausführende Person lässt die Arbeit ohne Zuweisung.
Nur wenige Zeilen haben mehrere ausführende Parteien. Wenn mehrere Teams zuständig sind, teilen Sie die Aktivität auf oder bestimmen Sie einen federführenden Ausführenden.
Konsultierte Rollen sind tatsächlich erforderlich. Eine Konsultation sollte Fachwissen beitragen oder Risiken kontrollieren und nicht lediglich eine Höflichkeitseinladung sein.
Informierte Rollen erhalten nützliche Updates. Definieren Sie, was sie wann wissen müssen.
Der Owner besitzt die nötige Befugnis. Machen Sie niemanden für eine Entscheidung verantwortlich, die von einer anderen Abteilung kontrolliert wird.
Ausnahmen haben einen Owner. Standardaufgaben können klar geregelt sein, während ungewöhnliche Fälle zwischen Teams stecken bleiben.
Ergänzen Sie neben der Matrix außerdem mehrere Verwaltungsfelder: Prozess-Owner, Version, Gültigkeitsdatum, Prüfdatum und Genehmigungsstatus. Ein Verantwortungsmodell sollte angepasst werden, wenn sich der Prozess, die Organisation oder das Risikoprofil verändert.
Statische Zuständigkeiten in Ausführungskontrollen überführen
Die größte Schwäche einer herkömmlichen RACI-Tabelle zeigt sich nach ihrer Veröffentlichung. Sie beschreibt das erwartete Verhalten, doch die tägliche Arbeit findet weiterhin über E-Mail, Chat, Formulare, Projektboards und Geschäftsanwendungen statt.
Dadurch wird die Matrix zu einem Referenzdokument, das erst herangezogen wird, wenn bereits etwas schiefgegangen ist. Um das zu verhindern, sollten Sie jede Rolle in eine entsprechende Ausführungskontrolle überführen.
Responsible-Rollen benötigen zugewiesene Schritte
Eine Responsible-Zuweisung sollte beim Start des Prozesses zu einer konkreten Aufgabe werden. Die zugewiesene Person oder das Team benötigt Anweisungen, erforderliche Daten, Frist und Abschlusskriterien an einem zentralen Ort.
In OKiDO kann eine SOP-Vorlage einzelne Schritte einer Person, einem Team oder einer operativen Rolle zuweisen. Wenn aus der SOP ein RUN wird, erhalten alle Beteiligten die Aufgaben für genau diese Ausführung, anstatt sich mithilfe der Matrix daran erinnern zu müssen, was zu tun ist.
Accountable-Rollen benötigen Befugnisse und Transparenz
Accountability bedeutet nicht, lediglich eine Benachrichtigung zu erhalten. Der Owner benötigt ausreichend Einblick, um den Fortschritt zu überwachen, bei blockierten Aufgaben einzugreifen und Ausnahmen zu klären.
Bei risikoreichen Entscheidungen sollte Accountability häufig als Genehmigungs-Gate umgesetzt werden. Nachgelagerte Schritte müssen blockiert bleiben, bis der autorisierte Owner das Ergebnis genehmigt oder ablehnt. Unser Leitfaden zu zuverlässigen Genehmigungs-Workflows erläutert, wie Sie solche Kontrollen gestalten, ohne unnötige Engpässe zu schaffen.
Consulted-Rollen benötigen strukturiertes Feedback
Eine Konsultation sollte mit einer konkreten Frage oder Entscheidung verknüpft sein. Vermeiden Sie es, Personen ohne klare Anfrage zu langen Nachrichtenthreads hinzuzufügen.
Nutzen Sie strukturierte Felder, Kommentare, Entscheidungsbäume oder Prüfaufgaben, um die erforderlichen Informationen einzuholen. Speichern Sie die Antwort zusammen mit der betreffenden Prozessinstanz, damit spätere Prüfer nachvollziehen können, wie die Entscheidung zustande kam.
Informed-Rollen benötigen gezielte Benachrichtigungen
Informiert zu sein sollte nicht bedeuten, jedes Prozessupdate zu erhalten. Definieren Sie das Ereignis, das für den jeweiligen Stakeholder relevant ist, beispielsweise eine Genehmigung, Ablehnung, Fertigstellung, Verzögerung oder Ausnahme.
Gezielte Benachrichtigungen reduzieren die Informationsflut und erhöhen die Wahrscheinlichkeit, dass wichtige Updates Beachtung finden. Außerdem verhindern sie, dass informierte Stakeholder versehentlich zu zusätzlichen Genehmigern werden.
Zugriffsrechte müssen zur Verantwortung passen
Rollenzuweisung und Systemzugriff müssen aufeinander abgestimmt sein. Ein Finance-Prüfer kann eine Validierung ohne Zugriff auf die erforderlichen Datensätze nicht abschließen. Ein lediglich informierter Stakeholder benötigt dagegen möglicherweise keinen Zugriff auf vertrauliche Lieferantendaten.
Verknüpfen Sie Prozessrollen mit Berechtigungen, Zugangsdaten und Systemzugriffen. Für KI-gestützte Arbeit gilt dasselbe Prinzip: Ein KI-Agent sollte nur die Fähigkeiten und Zugangsdaten erhalten, die er für den zugewiesenen Schritt benötigt. Eine ausführlichere Darstellung finden Sie unter rollenbasierte Zugriffssteuerung für Mensch-KI-Operations.
Vermeiden Sie RACI-Fehler, die zusätzliche Bürokratie schaffen
RACI soll die Koordination vereinfachen. Eine schlechte Umsetzung bewirkt das Gegenteil: Sie fügt ein weiteres Verwaltungsdokument hinzu, ohne die tatsächliche Arbeitsweise zu verändern.
RACI jeder kleinen Aktion zuweisen
Nicht jeder Punkt einer Checkliste benötigt vier Rollenbezeichnungen. Wenden Sie die Matrix auf wesentliche Ergebnisse, Entscheidungen, Kontrollen und Übergaben an. Innerhalb einer klar zugewiesenen Aktivität können detaillierte Anweisungen in der SOP verbleiben.
Mit RACI ein Kapazitätsproblem lösen wollen
Klare Rollen können chronische Unterbesetzung nicht beheben. Wenn derselbe accountable Owner über Dutzende Prozesse hinweg überlastet ist, hat die Matrix ein Kapazitätsproblem oder einen Fehler im Organisationsdesign sichtbar gemacht. Gelöst hat sie das Problem nicht.
Nutzen Sie Ausführungsdaten, um Zuweisungsvolumen, Wartezeiten, überfällige Aufgaben und die Dauer von Blockierungen zu messen. Anhand dieser Daten können Sie unklare Ownership von unzureichender Kapazität unterscheiden.
Konsultation mit Konsens verwechseln
Ein konsultierter Stakeholder liefert Input, erhält dadurch aber nicht automatisch ein Vetorecht. Wenn jede konsultierte Rolle zustimmen muss, verfügt der Prozess über eine Genehmigungsstruktur, die ausdrücklich dokumentiert werden sollte.
Legen Sie fest, wer die endgültige Entscheidung trifft und unter welchen Bedingungen eine Eskalation erforderlich ist. Andernfalls wird die Konsultation zu einer endlosen Suche nach Konsens.
Vertretungen und Eskalationswege ignorieren
Ein Prozess darf nicht zum Stillstand kommen, weil die einzige accountable Person nicht verfügbar ist. Definieren Sie Delegationsregeln, Vertretungsrollen und Eskalationsschwellen für zeitkritische Aufgaben.
In einer Ausführungsplattform können Bedingungen wie eine bevorstehende oder überschrittene Frist sowie Blockierungen Benachrichtigungen, Aufgaben oder einen Risikostatus auslösen. Dadurch wird die Zuständigkeit für Notfälle Teil des operativen Prozesses und nicht nur eine Anmerkung am Ende einer Tabelle.
Die Matrix nach Prozessänderungen nicht aktualisieren
Zuständigkeiten verändern sich, wenn Teams neu organisiert, Kontrollen eingeführt, Anwendungen ersetzt oder Teile einer Rolle automatisiert werden. Prüfen Sie die Matrix gemeinsam mit der zugrunde liegenden SOP, anstatt sie als separates Dokument zu pflegen.
Versionierung ist unverzichtbar. Laufende RUNs sollten die Rollenlogik und Prozessversion beibehalten, unter der sie gestartet wurden, während zukünftige RUNs das neu genehmigte Design verwenden. So bleibt genau dokumentiert, was zum jeweiligen Zeitpunkt von den Beteiligten erwartet wurde.
Machen Sie klare Rollen zu einem festen Bestandteil der Ausführung
Eine RACI-Matrix ist wertvoll, weil sie eine direkte Diskussion über Ownership erzwingt. Am besten funktioniert sie, wenn sie fokussiert bleibt: Definieren Sie die Prozessgrenzen, weisen Sie jedem Ergebnis genau einen accountable Owner zu, reduzieren Sie unnötige Konsultationen und validieren Sie das Design gemeinsam mit den Personen, die die Arbeit ausführen.
Doch belassen Sie es nicht bei der Matrix. OKiDO verbindet Prozessdokumentation, rollenbasierte Zuweisungen, Genehmigungen, Fristen, Eskalationsregeln, angebundene Systeme und Audit Trails in derselben operativen Ebene. Nutzen Sie OKiDO, um Ihre RACI-Matrix von einer statischen Übersicht über Rollen und Zuständigkeiten in eine kontrollierte Ausführung für Menschen und KI zu überführen.
