Rollen, Verantwortlichkeiten und gelebte Praxis

Von der Modellierung bis zur gelebten Praxis – wie klare Zuständigkeiten, Mandate und Schnittstellen Prozesse steuerbar machen.

Ein Prozessmodell ohne klare Rollen ist wie ein Gebäude ohne Eigentümer: Alles ist hergerichtet, aber niemand zieht ein, niemand trägt Verantwortung, niemand handelt, wenn etwas bröckelt.

In unserem letzten Beitrag haben wir die typischen Stolpersteine im Prozessmanagement beleuchtet, darunter den „Elfenbeinturm-Effekt“ und die „Verantwortung im Niemandsland“.

Entscheidend ist dabei nicht nur, wer etwas tut, sondern auch, wer entscheidet, wer bei Abweichungen eingreift und in welchem Rhythmus Rollen und Prozesse überprüft werden.

Heute gehen wir einen Schritt tiefer: Wer trägt eigentlich konkret Verantwortung? Und wie macht man diese Verantwortung im Prozess sichtbar?

Verantwortung sichtbar machen: Swimlane vs. RACI

In der Prozessmodellierung gibt es zwei zentrale Instrumente, um Rollen und Verantwortung abzubilden. Sie ergänzen sich, ersetzen sich aber nicht.

Die Swimlane (die „Schwimmbahn“ im Prozessdiagramm) zeigt auf den ersten Blick: Wer führt eine Aktivität aus? Sie strukturiert den Prozess horizontal nach Verantwortungsträgern, sei es Abteilungen, Rollen oder Einzelpersonen. Eine gut belegte Swimlane macht sofort erkennbar, wo im Prozess welche Einheit aktiv wird.

RACI geht einen Schritt weiter und differenziert die Art der Beteiligung:

Responsible: Wer führt die Aufgabe aus (wer steht in der Swimlane)?
Accountable: Wer trägt die Gesamtverantwortung und entscheidet?
Consulted: Wer wird vor der Entscheidung eingebunden?
Informed: Wer wird nach der Entscheidung informiert?

Während die Swimlane den Ablauf strukturiert, liefert RACI die Steuerungslogik dahinter.

Wichtig ist dabei: Die Rolle, die eine Tätigkeit ausführt, ist nicht automatisch auch die Rolle mit der letzten Entscheidungsverantwortung. Gerade in Matrixorganisationen sollten „Responsible“ und „Accountable“ bewusst getrennt werden.

Ein Prozessverantwortlicher ist in der Swimlane vielleicht gar nicht als ausführende Rolle sichtbar. Über RACI wird aber klar, dass er für bestimmte Entscheidungen das letzte Wort hat.

Der Prozess-Owner ist dabei nicht zwingend die disziplinarische Führungskraft. Er braucht aber ein klares Mandat für Priorisierung, Eskalation und die Weiterentwicklung des Prozesses.

In vielen Modellierungs-Tools lässt sich RACI direkt an den einzelnen Aktivitäten hinterlegen, wodurch die Verantwortungsmatrix nahtlos in den Prozessablauf integriert wird.

Beide Instrumente zusammen geben das vollständige Bild.

In der Praxis muss nicht jede einzelne Aktivität mit einem vollständigen RACI versehen werden. Besonders relevant ist die klare Zuordnung bei Entscheidungen, Freigaben, Eskalationen und kritischen Schnittstellen.

Verantwortung braucht Mandat

Eine benannte Rolle allein reicht nicht. Prozessverantwortung entfaltet erst dann Wirkung, wenn sie mit konkreten Befugnissen, einem realistischen Zeitbudget und klaren Eskalationswegen hinterlegt ist. Wer für einen Prozess verantwortlich sein soll, muss auch Änderungen anstoßen, Konflikte adressieren und Entscheidungen herbeiführen können.

Klare Abgrenzung zwischen Swimlanes

Wo der Sequenzfluss von einer Swimlane in eine andere übergeht, entsteht eine Schnittstelle, d.h. die ausführende Verantwortung für einen bestimmten Arbeitsschritt wechselt. Und genau hier liegen die häufigsten Reibungsverluste.

Typische Probleme

Überlappungen: Zwei Bereiche beanspruchen dieselbe Aktivität für sich.
Graue Bereiche: Keiner fühlt sich zuständig, die Aufgabe „fällt zwischen die Stühle“.
Undurchsichtige Übergaben: Informationen oder Verantwortung wechseln die Lane, ohne dass dies explizit modelliert wird.

Praktischer Ansatz

Definieren Sie bei jedem Lane-Wechsel klar: Was wird übergeben? In welcher Form?

Kritische Übergaben sollten explizit modelliert oder zumindest eindeutig als Schnittstelle beschrieben werden. Zusätzlich sollte festgelegt werden an wen übergeben wird, in welchem System oder Format, mit welcher erwarteten Qualität, bis wann die Übergabe erfolgen muss und wie Abweichungen eskaliert werden.

Verantwortung über Prozessgrenzen hinweg

Prozesse sind selten Inseln

Ein Prozess endet oft dort, wo ein anderer beginnt oder sie überlappen sich zeitlich. Wer ist verantwortlich, wenn Prozess A in Prozess B übergeht?

Hier hilft eine klare Prozesslandkarte als übergeordneter Rahmen. Sie zeigt, welche Prozesse aufeinander aufbauen, welche Eingaben und Ergebnisse sie austauschen.

Auf dieser Basis lassen sich Verantwortlichkeiten für Schnittstellen definieren:

Wer liefert welchen Input für den Folgeprozess und in welcher Qualität?
Wer prüft Qualität und Vollständigkeit?
Wer eskaliert, wenn Schnittstellen hängen?

Zusätzlich sollte klar sein, wer die Gesamtverantwortung für die Funktionsfähigkeit der Schnittstelle trägt – also wer regelmäßig prüft, ob Übergaben, Durchlaufzeiten und Qualitätsanforderungen tatsächlich eingehalten werden.

Ohne diese Klärung entstehen Reibungsverluste, verzögerte Durchlaufzeiten und Schuldzuweisungen zwischen Prozessverantwortlichen.

Gerade an Prozessgrenzen braucht es zudem feste Review-Zyklen.

Review-Zyklen machen Verantwortung wirksam

Rollen und Verantwortlichkeiten sind nicht statisch. Sie sollten in festen Intervallen und zusätzlich anlassbezogen überprüft werden, etwa bei Organisationsänderungen, neuen regulatorischen Anforderungen, Auditerkenntnissen oder Systemumstellungen. Ein schlanker Review-Takt erhöht die Verbindlichkeit und verhindert, dass Rollenbeschreibungen veralten.

Externe Verantwortlichkeiten

Nicht alle Beteiligten an einem Prozess sind intern. Kunden liefern Antragsunterlagen, externe Dienstleister führen Teilprozesse aus, Regulatoren fordern Meldungen ein. Wie modelliert man Verantwortung, die man nicht direkt steuern kann?

In einer BPMN-nahen Darstellung werden externe Beteiligte eher als eigener Pool bzw. als Blackbox-Pool modelliert. In vereinfachten Darstellungen kann auch eine externe Bahn genutzt werden, um die Schnittstelle sichtbar zu machen. Sie macht sichtbar, wo der Prozess auf externe Inputs wartet und wer außerhalb der eigenen Organisation handeln muss.

Wichtig ist dabei

Klare Definition der erwarteten Leistung oder Information
Vereinbarung von Service Levels oder Reaktionszeiten, wo möglich
Modellierung von Eskalationspfaden, wenn externe Beteiligte nicht liefern

Externe Verantwortlichkeit lässt sich nicht im gleichen Maße steuern wie interne – aber sie lässt sich sichtbar machen, managen und gegebenenfalls ersetzen oder absichern.

Auch wenn Leistungen extern erbracht werden, braucht es intern immer eine verantwortliche Rolle für Auswahl, Überwachung, Eskalation und Nachverfolgung des externen Beitrags.

Gleichwohl sollte eine solche Swimlane als Blackbox behandelt werden. Wir modellieren dort keine dedizierten Aktivitäten des externen Partners, da wir diese ja nicht steuern können. Stattdessen dient die Swimlane dazu, die Schnittstelle als solche transparent zu machen und die zu übergebenden Artefakte zu dokumentieren: Was geht wann raus? Was kommt wann zurück?

Was innerhalb des externen Pools passiert, ist Gegenstand der Dienstleistersteuerung und findet sich in Service Level Agreements (SLA) wieder. Dort werden Erwartungen, Reaktionszeiten und Qualitätskriterien vereinbart. Im Prozessmodell selbst bleibt es bei der klaren Dokumentation der Schnittstelle und der verantwortungsvollen Übergabe.

Zusätzlich sollten erwartete Artefakte, Qualitätskriterien, Rückmeldepflichten und mögliche Ausweich- oder Ersatzprozesse beschrieben werden, falls der externe Beitrag ausbleibt.

Fazit und Ausblick

Klare Rollen und Verantwortlichkeiten sind das Rückgrat jedes funktionierenden Prozessmanagements. Swimlanes und RACI sind dabei komplementäre Werkzeuge: Die eine strukturiert den Ablauf, die andere präzisiert die Beteiligung. Wer sowohl interne als auch externe Schnittstellen klar definiert und über Prozessgrenzen hinweg koordiniert, schafft die Grundlage für echte Steuerbarkeit – nicht nur auf dem Papier, sondern in der gelebten Praxis. Ein Prozess ist erst dann wirklich steuerbar, wenn Ausführung, Entscheidung, Eskalation und Review eindeutig zugeordnet sind.

Im nächsten Beitrag unserer Reihe widmen wir uns einem Feld, in dem klare Verantwortlichkeiten besonders kritisch sind: dem Zusammenspiel von Prozessmanagement und Regulatorik. Wie integrieren sich Anforderungen aus bspw. DORA und MaRisk sinnvoll in die Prozesslandschaft, ohne doppelte Dokumentation zu erzeugen?

Besonders relevant wird das dort, wo regulatorische Anforderungen nicht nur dokumentiert, sondern klar Rollen, Kontrollen und Prozessschritten zugeordnet werden müssen.