Limitation von BPMN 2.0 im regulierten Umfeld

Unternehmen setzen zunehmen auf BPMN 2.0 als Grundlage für die Dokumentation Ihrer Prozesslandschaft. BPMN 2.0 zeichnet sich durch eine einheitliche Spezifikation und somit eine universelle Lesbarkeit der Prozessmodelle aus. In diesem Artikel möchten wir daher die Frage erörtern, ob die Spezifikation auch im hochregulierten Umfeld Gültigkeit besitzt oder die Art der Modellierung aufgrund der regulatorischen Vorgaben angepasst werden muss. Wir gehen hier insbesondere auf die Vorgaben für Banken aus der MaRisk (10/2021) ein.

Grundlagen zum BPMN 2.0 Standard

Ziele des BPMN 2.0 Standards

Der BPMN (Business Process Model and Notation) 2.0 Standard wurde durch die Object Management Group (OMG) entwickelt um folgende Ziele zu erreichen: Erstens, eine allgemein gültige Notation welche durchgängig von allen im Prozess beteiligten lesbar ist: Vom Business Analysten im ersten Workshop bis hin zum Entwickler welcher den Prozess später in Form von Software implementieren wird. Zweitens, diese Notation in einem maschinenlesbaren Format abzubilden, in diesem Fall in Form von XML Files. Auf diese Art können BPMN 2.0 Prozesse an verschiedenen Stellen in den Systemen und zwischen Unternehmen mittels BPMN-Export und BPMN-Import ausgetauscht werden. Im Gegensatz zu reinen zeichnungsbasierten Prozessmodellen z.B. in Microsoft Visio stellt dies eine erhebliche Arbeitserleichterung dar. 

Nutzung von BPMN 2.0 in der Prozessautomatisierung oder der maschinellen Prozessdurchführung

Es ist naheliegend dass die in BPMN 2.0 erstellten Modelle für die Automatisierung der Prozesse in ERP Softwarelösungen wie SAP verwendet werden. Hierbei gilt es in der Spezifikation der OMG folgendes zu beachten: Es gibt einen Unterschied zwischen der Prozess-Modellierungs-Konformität und der Ausführungskonformität der Prozesse in Process Engines, sowie der Ausführung von Choreografien (mehrere Prozesse mittels Workflows): Die Semantik der Prozessmodellierung muss nicht zwingend mit der Ausführung mittels Execution-Engines und gleichzeitig mit der Choreografie übereinstimmen, da diese Tools auch bei Konformität mit BPMN 2.0 die grafische Syntax nicht voll unterstützen muss. 

Praktisch bedeutet dies dass BPMN 2.0 den Grobrahmen für die Prozessautomatisierung durch Dokumentation der Prozesse legt, jedoch Ergänzungen in Automatisierungstools in Form von Kombination von Aktivitäten zu Workflows (Choreographien) oder Erweiterung der Strukturen stattfinden muss. Vorteilhaft ist dass sich die BPMN XML Dokumente oftmals in Workflow-Engines oder Automatisierungslösungen einlesen lassen, jedoch fehlen oftmals weitergehende Beschreibungen welche der BPMN 2.0 Standard nicht liefern kann. Dies können z.B. mit den Aktivitäten verknüpfte Softwaresysteme sowie deren Datenattributen und Funktionen und Berechnungslogiken sein, welche sich aus der grafischen Prozessbeschreibung sowie den verwendeten Objekten (z.B. Ressource enthält nur id, name; DataInput, DataOutput beschreiben nur das Datenobjekt in Summe) nicht herleiten lassen.

Anforderung der BaFin an die Prozessdokumentation - lassen sich diese in BPMN 2.0 abbilden?

Im Folgenden stellen wir die Anforderungen der BaFin für Banken anhand der MaRisk (Stand: 10/2021) an die Prozessdokumentation dar. Diese gehen weit über die der BPMN 2.0 Spezifikation der OMG zu Grunde gelegten Anforderung der universellen Lesbarkeit hinaus:

MaRisk AT 4.3 Internes Kontrollsystem

Die BaFin fordert hier in Absatz 2 „Prozesse sowie die damit verbundenen Aufgaben, Kompetenzen, Verantwortlichkeiten, Kontrollen sowie Kommunikationswege sind klar zu definieren und aufeinander abzustimmen. (…)“

Dies bedeutet: 

Es reicht nicht allein die Prozesse als Prozessfluss mit BPMN 2.0 grafisch zu dokumentieren. Die Abstimmung der Kompetenzen und Verantwortlichkeiten bedingt ein übergreifendes Rollenkonzept, so dass klar nachvollziehbar ist und eine Auswertbarkeit gegeben ist welche Rollen welche Verantwortlichkeiten in welchen Prozessen wahrnehmen. 

BPMN 2.0 in Reinform stößt hier auf drei Shortcomings: 

Erstens, detaillierte Verantwortlichkeiten im Sinne der RACI (Responsible, Accountable, Consulted, Informed) können für die jeweiligen Prozessschritte nicht erfasst werden. Das Ressource Objekt aus BPMN 2.0 nach OMG Standards enthält nur die Information über den „Responsible“ (=Verantwortlichen) für die jeweilige Aktivität, aus diesen leiten sich dann (toolspezifisch) die SwimLanes ab. 

Zweitens, erweiterte Informationen zu Kontrollen oder mit dem Prozess verbundenen Aufgaben und Maßnahmen lassen sich aufgrund der fehlenden Objekte nicht darstellen oder vernetzen.

Drittens, die reine grafische Darstellung in reinen „Zeichnungstools“ nach BPMN 2.0 Standard ermöglicht die Auswertung der Kompetenzen und Verantwortlichkeiten nicht, da Massenverantwortlichkeiten in Form des „Pool“ Elements erfasst werden können. Pools sollen lt. Definition der OMG Kollaborationen beschreiben, wobei diese keine einheitliche Verantwortlichkeit im Sinne der Regulierungsvorgaben enthalten.

 

MaRisk AT 5 Organisationsrichtlinien

Organisationsrichtlinien oder SfO (schriftlich fixierte Ordnung) werden oftmals direkt in das Prozessmodell integriert, wobei freigegebene Prozesse als Richtlinie gelten. Hierbei gilt nicht nur der Umfang der Richtlinien zu beachten (Ausdetaillierung in AT 5 Abs. 3), sondern auch der Nachweis der Bekanntmachung für die Mitarbeiter in aktueller Fassung sowie der Gültigkeit der Richtlinien. (Abs. 2)

Dies bedeutet: 

Neben der reinen Prozessmodellierung in BPMN 2.0 benötigt das Institut Instrumente um die jeweiligen Prozesse und Vorgaben den „betroffenen Mitarbeitern“ (AT 5 Abs. 2) zur Verfügung gestellt werden. 

Die Umsetzung erfolgt über zwei Schritte: 

Erstens, einen Freigabeworkflow mittels diesem das Institut die aktuelle Fassung“ bestimmt.

Zweitens, die Bekanntmachung bei den relevanten Mitarbeitern bzw. über die jeweiligen Organisationseinheiten.

 

Hier ergeben sich zwei Shortcomings von reinen BPMN 2.0 Modellen:

Erstens, die fehlende Freigabefunktion der Modelle aufgrund der fehlenden RACI und damit das Fehlen der mindestens zweistufigen Freigabe („Vier-Augen-Prinzip“).

Zweitens, die fehlende Informationsmöglichkeit von Gruppen da pro Objekt über die Ressource nicht mehrere Beteiligte mit unterschiedlichen Ausprägungen (z.B. „informed“) darstellbar sind.

 

MaRisk AT 8.2 Änderungen in betrieblichen Strukturen oder Prozessen

Die MaRisk fordert hier dass bereits im Vorfeld von „wesentlichen Veränderungen in der Aufbau- und Ablauforganisation“ die Auswirkungen auf Kontrollverfahren  zu analysieren sind, was u.a. die Zuweisung von Kontrollverfahren auf Prozesse und deren Organisationseinheiten betrifft. Aufgrund der fehlenden Darstellungsmöglichkeit des internen Kontrollsystems (IKS) im BPMN 2.0 Standard, sowie des Fehlens der Organisationsinformationen (d.h. welcher Prozess in welcher Organisation ausgeführt wird) ist diese Tätigkeit nur mit großem händischen Aufwand ausführbar.

 

MaRisk AT 9 Auslagerung

Im Bereich der Auslagerung muss das Institut nach MaRisk AT 9 Abs. 2 bewerten können „(…) welche Auslagerungen und Prozesse aus Risikogesichtspunkten wesentlich sind (…)„, was bedingt dass zu den jeweiligen Prozessen und Aktivitäten eine Risikoanalyse erstellt wird. BPMN 2.0 kenn hier keine Zuweisung von Risiken auf Prozessschritte oder Aktivitäten, da das hierfür notwendige Risikoobjekt nicht vorhanden ist. Ein weiteres Shortcoming stellt die fehlende Vernetzung mit den jeweiligen Auslagerungspartnern dar, da diese oftmals als „Pools“ modelliert werden ohne konkreter den Dienstleister zu benennen.

Dies führt zu erhöhten Aufwänden in der Identifikation der jeweiligen Dienstleister in den relevanten Prozessen, und einer fehlenden aktuellen Übersicht welche Prozesse risikobehaftet sind – bedingt dadurch dass das Prozess- und Risikomodell laufend synchronisiert werden müssen. Weiter gestaltet sich die Einbindung der in MaRisk AT 9 Abs. 2 geforderten „maßgeblichen Organisationseinheiten“ schwierig, da die Prozesse in BPMN 2.0 oftmals nicht Organisationseinheiten zugewiesen werden können.

Fazit zur Umsetzung der BaFin Anforderung in reinen BPMN 2.0 Modellen mittels grafischen Editoren

Die Analyse der Umsetzbarkeit der BaFin Anforderungen mittels rein grafischen BPMN 2.0 Editoren mit den im OMG Standard definierten Elementen führt zu folgendem Ergebnis: 

  1.  

Was bedeuten die BaFin Anforderungen für das Datenmodell eines Prozessmanagementsystems nach BPMN 2.0?

Aufgrund der BaFin Anforderungen ergeben sich erweiterte Anforderungen an die Vernetzungs- und Dokumentationsmöglichkeiten von Prozessen: Essentiell ist die Einbindung in den regulatorischen Dreiklang zwischen Risiken, Prozessen und Kontrollen. Darüber hinaus muss die Ausweisung von Prozessunterstützenden Ressourcen (Assets) sowie des zu Grunde liegenden Informationsverbundes möglich sein. Auslagerungen müssen im Prozesssystem gekennzeichnet werden können, und die jeweiligen Dienstleister pro Prozessschritt benannt werden können. Im Idealfall können pro Prozess nicht nur die Verantwortlichen für den Prozess, sondern auch die relevante Notfallorganisation und der Notfallprozess benannt werden, um die Einbindung in ein BCMS zu erleichtern. 

Die Vernetzung der Datenobjekte stellt sich auf oberster Ebene wie folgt dar:

Lösungsansatz mit der Softwarelösung TopEase BPM

TopEase verfügt als GRC (Governance, Risk & Compliance) Plattform über die Vernetzungsmöglichkeit der einzelnen GRC Disziplinen: Prozesse können somit mittels BPMN 2.0 Standard modelliert werden, und sowohl im Modell selbst als auch auf Prozessebene die regulatorischen Vorgaben umgesetzt werden:

TopEase verfügt im Vergleich zu einfachen grafischen BPMN 2.0 Modellierungswerkzeugen über eine erweiterte RACI zur Erfüllung der regulatorischen Vorgaben: Für jedes einzelne Objekte in den BPMN 2.0 Diagrammen lassen sich somit separate Verantwortlichkeiten für Responsible, Accountable, Informed und Consulted definieren – diese werden mit Rollen und Personen hinterlegt und können auch grafisch als Swim-Lanes dargestellt werden. Durch die Nutzung von Rollen als Datenobjekte können pro Rolle die tatsächlichen Verantwortlichkeiten einmal auf Seite der Prozesse dargestellt werden, aber auch die einzelnen Personen welche die jeweiligen Rollen als Verantwortlichkeit inne haben. 

In Abhängigkeit der eingesetzten TopEase Module lassen sich nicht nur einzelne Objekte wie Risiken und Kontrollen beschreiben, sondern auch ausführen – Kontrollen können somit pro Prozessschritt oder Risiko ausgeführt und dokumentiert werden. Hierdurch entsteht die regulatorische Vernetzung des Dreiklangs zwischen Risiken, Kontrollen und Prozessen.

Fazit

Durch die Nutzung erweiterter Prozessmanagementsoftware wie TopEase wird die Herstellung von regulatorischen Compliance mit Vorgabewerken wie der MaRisk deutlich vereinfacht. 

Die hierfür notwendige Vernetzung von Prozessen mit Risiken und Kontrollen, sowie die Nutzung einer RACI zur Herstellung einer Eindeutigkeit von Verantwortlichkeiten sind nicht im BPMN 2.0 Standard vorgesehen und ergänzen hier die Modellierungsmöglichkeit um die geforderten regulatorischen Vorgaben.

Neben den Swimlanes sollten aus regulatorischen Sicht nicht die Elemente der „Pools“ verwendet werden, da diese kollaborativ eingesetzt werden um z.B. generell die Involvierung einer Dritten Stelle in den Prozess beschreiben, dies ist jedoch aufgrund der Vorgaben nicht ausreichend da z.B. die Auslagerungen gekennzeichnet werden müssen und auf Dienstleisterebene darzustellen sind. 

Eine „einfache grafische Modellierung“ der Prozesse ist somit im hochregulierten Umfeld nicht ausreichend, da eine regelkonforme Steuerung der Prozesslandschaft die Abhängigkeiten zwischen den Prozessen, Risiken, Kontrollen, Dienstleistern und Assets abbilden muss – inklusive der jeweiligen Verantwortlichkeiten.