Konzeption einer Business Process Analytics-Plattform

Siegbert Kern

In diesem Beitrag wird ein Konzept und der Prototyp einer BPA-Plattform zur Auswertung und Analyse von Prozessdaten vorgestellt. Hierbei handelt es sich um das Ergebnis einer gemeinsamen Forschungsarbeit der CDI AG mit der Westfälischen Hochschule in Gelsenkirchen. Die konzipierte BPA-Plattform unterstützt den ganzheitlichen Ansatz der BPA mit Vergangenheits-, Echtzeitanalysen und Prognosen über zukünftige Entwicklungen. Die prozessrelevanten Kennzahlen werden in direkter Verbindung mit dem BPMN-Prozessmodell grafisch modelliert, gespeichert, ausgewertet und dargestellt. Die Konzeption der BPA-Plattform sieht die herstellerunabhängige Verarbeitung von Ereignisdaten unterschiedlicher Business Process Engines vor. Im ersten Schritt wurden im Prototyp Echtzeitanalysen mit grafischer Ergebnisdarstellung in BPMN-Prozessmodellen realisiert.

Die Zielsetzung von BPMN 2.0 ist, eine standardisierte Prozessnotation bereitzustellen, mit der Prozesse grafisch beschrieben werden können, die auch für die Prozessautomatisierung verwendet werden kann. Hierdurch wird eine Aufführbarkeit von BPMN-Prozessmodellen ermöglicht. Dafür sind Process Engines entwickelt worden. Eine Process Engine steuert die Abläufe, wie sie in den Prozessmodellen definiert sind und kommuniziert über Nachrichtenkanäle mit den zur Ausführung erforderlichen Anwendungen und Diensten [1]. Es sind Softwaresysteme, die statt dem klassischen Programmcode Prozessmodelle als zentrales Implementierungsartefakt nutzen [2].

Die Bedeutung der Prozessorientierung nimmt immer mehr zu und wird unter dem Begriff Business Process Management subsumiert. Zum einen wird dies dadurch deutlich, dass immer mehr Unternehmen eine prozessuale Betrachtung ihrer Organisation vornehmen, wie es in Studien zur Bedeutung von Prozessmanagement in Unternehmen zum Ausdruck kommt [3, 4]. Zum anderen verfolgen, neben einer Reihe von Anbietern von Process- und Workflow Engines (z. B. Camunda), auch große Standardsoftwareanbieter (z. B. SAP mit dem Produkt SAP NetWeaver Business Process Management oder Oracle mit Oracle BPM Suite) diesen modellgetriebenen Softwareentwicklungsansatz. Die Standardsoftwareanbieter sehen ihre Produkte eher als Ergänzung zu den Built-in Prozessen ihrer Software, um damit explizit Prozessoptimierung zu betreiben. Zukünftig werden immer mehr Geschäftsprozesse durch modellgetriebene, prozessorientierte Anwendungssysteme unterstützt.

Die Unternehmen verbinden mit dem Business Process Management drei wesentliche Ziele [3]:

  1. Verringerung der Prozesslaufzeiten
  2. Prozesskosteneinsparungen
  3. Reduzierung von Fehlerquoten

 

Marktstudien zeigen, dass die meisten Unternehmen nur punktuell Messungen durchführen, um festzustellen, ob ihre Maßnahmen zur Prozessverbesserung die gewünschten Ziele auch erreicht haben. Eine kontinuierliche Prozessanalyse und -optimierung sowie ein Prozesscontrolling wird in den Unternehmen bisher nachrangig behandelt [3]. Gleichzeitig sorgen die steigenden Anforderungen in den Unternehmen dafür, den Blick intensiver auf die Geschäftsprozesse zu richten, um mehr darüber zu erfahren, welchen Beitrag diese für das Erreichen der Unternehmensziele leisten und was Verbesserungen zukünftig bewirken können. Dies setzt voraus, dass systematisch für die Prozesse aussagekräftige Prozesskennzahlen entwickelt und möglichst automatisiert erhoben werden. Nur dadurch wird es möglich, das Leistungsvermögen implementierter Prozesse zu überwachen und zu analysieren und so möglichst frühzeitig Engpässe, Schwachstellen, Veränderungen und Fehler zu erkennen. Hierbei existiert mit Business Prozess Analytics (BPA) ein ganzheitlicher Ansatz zu einer vergangenheits-, echtzeit- und zukunftsorientierten Betrachtung von Prozessdaten.
 

Business Process Analytics

BPA hat das Ziel, allen Prozessbeteiligten und Entscheidungsträgern einen Einblick in die Effizienz und Effektivität von Geschäftsprozessen zu geben. Es kann in die drei Teilgebiete Process Controlling (PC), Business Activity Monitoring (BAM) und Process Intelligence (PI) untergliedert werden [5]. Die zugrundeliegenden Konzepte sind nicht neu, sondern im Kontext der Themen Corporate Performance Management oder auch Business Intelligence sehr wohl bekannt. Die Besonderheit liegt auf der Prozessfokussierung und weniger auf die Geschäftsobjekte.

PC richtet den Blick auf die Vergangenheit. Es werden Prozessdaten gesammelt, ausgewertet und analysiert, um Trends und systematische Schwachstellen zu erkennen. Das BAM hat das Ziel, die Prozessdaten in Echtzeit zu analysieren. Während der Ausführung der Prozesse werden die relevanten Prozessdaten sofort gesammelt und ausgewertet [6]. Dies erfolgt mit dem Real Time Monitoring and Alerting, der die Prozessergebnisse in Form von Kennzahlen bzw. Key Performance Indicators (KPI) den Prozessverantwortlichen sofort anzeigt und sie bei Abweichungen von Zielwerten alarmiert. PI ist zukunftsorientiert und versucht die Auswirkungen von Prozessanpassungen, die auf Basis der Erkenntnisse von BAM vorgenommen werden, vorherzusagen. Dafür werden Methoden der Simulation und der Prognose eingesetzt.

Die Basisdaten für BPA sind Ereignisse, die bei der Durchführung von Prozessen entstehen (z. B. nimmt ein Bearbeiter ein Work Item aus dem Arbeitsvorrat). Diese Ereignisse repräsentieren originäre Statusänderungen einer Prozessinstanz. Eine Prozessinstanz entsteht, wenn ein Prozess in der Realität gestartet wird, und existiert fort, solange der Prozess in der Realität durchlaufen wird [7]. Um Geschäftsprozesse analysieren zu können, ist es erforderlich, die während der Existenz von Prozessinstanzen entstehenden Ereignisse zu speichern. Oftmals werden diese Ereignisse mit Statusänderungen der Geschäftsobjekte ergänzt oder auch kombiniert, die innerhalb einer Prozessinstanz, d.  h. im Kontext des Geschäftsprozesses, bearbeitet werden.

Um aus Ereignisdaten für Prozessverantwortliche und das Management aussagekräftige Kennzahlen zur Leistungsbeurteilung von Geschäftsprozessen zu bilden, bedarf es einer auf sich aufbauenden Struktur von Indikatoren. Eine solche Struktur enthält angelehnt an Friedenstab [8] die folgenden Bausteine:

1. Process Performance Indicator (PPI) – Prozesskennzahlen

PPI sind Kennzahlen, die sich auf eine oder mehrere Prozessinstanzen beziehen, die bei der Prozessausführung bestimmt werden können. Hierbei können die folgenden Typen einer Basis-PPI unterschieden werden:

  • Dauer eines Ausführungsschrittes oder einer Phase,
  • Häufigkeit einer Ausführung, eines Events und
  • Werte aus den bearbeiteten Geschäftsobjekten.

Diese Basis-PPI können abhängig von definierten Bedingungen gemessen und algorithmisch miteinander kombiniert und zu komplexeren PPI aggregiert werden.
 

2. Key Performance Indicator (KPI) – relevante Leistungskennzahlen des Prozesses

Auf der Grundlage von PPI können die für die Verantwortlichen relevanten KPI definiert werden, mithilfe derer Entscheidungen besser getroffen werden können. KPI können durch Eingrenzungen auf eine Menge von Prozessinstanzen sowie durch Gewichtung der in die KPI eingehenden PPI gebildet werden.


3. Target – Schwellwerte für KPI zur Beurteilung der Kennzahl

Ein wesentliches Element ist die Steuerung auf Basis von Schwellwerten (auch in Form von Intervallen), bei deren Unter- oder Überschreitung Aktionen ausgelöst werden. Diesen Schwellwerten können wiederum Farben (z. B. grün, gelb, rot) und Symbole (z. B. Ampel) zugeordnet werden. Mit einem Target kann die Zielerreichung der KPI leicht erkennbar dargestellt und Meldungen an Verantwortliche automatisiert erstellt werden.

Die KPI können in vier Kategorien unterschieden werden:

  • KPI-Time: Prozessdauer (z. B. durchschnittliche Dauer von Bestellannahmen bis zur Lieferung)
  • KPI-Quality: Prozessqualität (z. B. Stornoquote von Kundenaufträgen)
  • KPI-Cost: Prozesskosten (z. B. angefallene Prozesskosten über einen Zeitraum)
  • KPI-Flexibility: Prozessflexibilität (z. B. Anzahl und Anteile der angebotenen Versanddienstleistungen)

Die einzelnen KPI für einen Prozess oder Teilprozess können wiederum durch Gewichtung zu einem Gesamtprozess-KPI auf Basis der erzielten Schwellwerte zusammengeführt werden. Die vorgestellten PPI und KPI bilden die Basis für BPA.
 

Konzeption der BPA-Plattform

Das Konzept der entwickelten BPA-Plattform hat drei wesentliche Ziele:

  1. Die Implementierung eines modellgetriebenen durchgängigen Ansatzes vom KPI-Modell auf Basis eines BPMN-Modells bis zur Echtzeitanzeige von KPI in einem BPMN-Modell.
  2. Eine BPA-Plattform, die auf Basis der ermittelten Ereignisdaten alle Teilgebiete, wie PC, BAM und PI abdecken und
  3. herstellerunabhängig von Process Engines Ereignisdaten aufnehmen und verarbeiten kann.

Anforderungen an die BPA-Plattform:

  1. Speicherung von grafisch modellierten Targets, KPI und PPI und den dafür notwendigen Rechenvorschriften in XML
  2. Speicherung von BPMN-Modellen mit Bezug auf die definierten Targets, KPI und PPI in einem laut BPMN-Spezifikation standardisierten XML-Schema. Hierbei sollen auch mehrere zusammenhängende Prozessebenen abgebildet und gespeichert werden können, von Wertschöpfungsdiagrammen bis zu Prozessmodellen mit BPMN.
  3. Verarbeitung von Ereignisdaten aus einer Process Engine in Echtzeit
  4. Grafische Anzeige von Targets und KPI in Echtzeit innerhalb eines BPMN-Modells
  5. Grafische Anzeige auf mobilen Endgeräten
  6. Entwicklung einer BPA-Plattform unabhängig von spezifischen Process Engines und BPMN-Modeller
Bild 1: Aufbau und Integration der BPA-Plattform.


Im Bild 1 sind der Aufbau und die Integration der BPA-Plattform dargestellt. Als Benutzerschnittstelle wurde eine BPA-User App für die grafische Echtzeitanzeige der definierten KPI in Verbindung mit dem jeweiligen BPMN-Prozessmodell entwickelt. Die Modell- und Ergebnisdaten werden von der BPA-Plattform online auf die User App übertragen. Die BPMN-Modelle werden in einem BPMN-Modeller erstellt und in einer standardisierten XML-Struktur an die BPA-Plattform übertragen. Für BPA-Modelle existiert noch keine standardisierte Modellierungssprache. Eine BPA-Modellierung sollte auf den entwickelten und umgesetzten Prozessmodellen aufsetzen. Deshalb wäre es sinnvoll, einen BPA-Modeller in einen BPMN-Modeller zu integrieren. Aufgrund der fehlenden Standardisierung und erforderlichen Integration von BPMN- und BPA-Modeller wurde bei der Entwicklung des Prototyps darauf verzichtet, einen solchen BPA-Modeller zu entwickeln. Jedoch wurden für die BPA-Modellelemente XML-Strukturen entwickelt, die sich an die BPMN XML-Strukturen anlehnen. Damit wurde die Möglichkeit geschaffen, für ein Prozessmodell die dafür definierten BPA-Modellelemente in der BPA-Plattform abzuspeichern und für die erforderlichen Berechnungen zu nutzen. Die während der Prozessdurchführung in der Process Engine entstehenden Ereignisse sollen über eine Schnittstelle Real-time von der BPA-Plattform übernommen werden. Im Prototyp ist eine solche Schnittstelle vorgesehen, jedoch wird für den Prototyp die BPA-Plattform durch einen eigens dafür entwickelten Event Generator versorgt. Der Event Generator ist zugleich wichtiger Bestandteil der BPA-Plattform. Damit ist es möglich, im Rahmen von PI modellierte Prozesse und KPI-Ergebnisse zu simulieren.
 

Bild 2: BPA-Modell für den Beispielprozess „Kundenauftrag“.

Die BPA-Plattform enthält vier Module:

  1. Process Repository (zur Verwaltung von Geschäftsprozessmodellen)
  2. Process Warehouse (zur Speicherung der Targets, KPI und PPI sowie der Rechenvorschriften zur Ermittlung der Indikatoren und zu deren Berechnung auf Basis eingehender Ereignisse, Schnittstelle zu Process Engines)
  3. User App-BPA-Cockpit (zur grafischen Darstellung der Prozessmodelle und den dazugehörigen Ergebnissen der relevanten KPI)
  4. Event Generator (zur Ereigniserzeugung und Simulation)


Prototyp der BPA-Plattform

Für den Beispielprozess „Kundenauftrag“ (Bild 2) wurden PPI und KPI modelliert, in definierten XML-Schema gespeichert und auf Basis der erzeugten Events die KPI-Ergebnisse berechnet und grafisch im User App-BPA-Cockpit angezeigt.

Im Beispielprozess trifft ein Kundenauftrag ein, der zunächst erfasst und danach auf Bonität geprüft wird. Sofern die Bonität des Kunden nicht ausreichend ist, wird der Kundenauftrag zurückgewiesen. Bei positiver Bonität des Kunden wird die Verfügbarkeit der bestellten Waren überprüft. Sofern der Kundenauftrag lieferbar ist, wird eine Auftragsbestätigung erstellt, falls nicht zurückgewiesen. Der Beispielprozess enthält vier Teilprozesse, die in weiteren Prozessmodellen detailliert beschrieben sind. Es wurden jeweils ein KPI-Time, KPI-Quality, KPI-Cost und KPI-Flexibility definiert (Bild 2).

Beispielhaft wird die KPI-Time erläutert. Basis für die KPI-Time ist eine PPI vom Typ Dauer, im Beispiel die Durchlaufzeit des Kundenauftrages für eine Instanz. Dafür wurden ein Beginnmarker bei der Kundenauftragserfassung und ein Endmarker beim Endereignis des Prozesses modelliert. Um die durchschnittliche Durchlaufzeit zu ermitteln, wird für die PPI ein Aggregat mit der Ausprägung „durchschnittlich“ modelliert. Zu diesem Aggregat wurde ein Filter definiert, der bestimmt, welche Instanzen für die Berechnung der durchschnittlichen Durchlaufzeit herangezogen werden. Im Beispiel sind das alle Instanzen der letzten 24 Stunden, d. h. die durchschnittliche Durchlaufzeit wird aus allen Instanzen dieses Prozessabschnitts der letzten 24 Stunden berechnet. Das Aggregat mit dem definierten Filter ist einer KPI zugewiesen. Zur vollständigen Definition des KPI wurde ein Target modelliert. Damit wird die Ampelfarbe für das KPI bestimmt. In diesem Beispiel wird die Ampel der KPI grün, wenn die durchschnittliche Durchlaufzeit ≤ 5 min beträgt, gelb bei einer durchschnittlichen Durchlaufzeit > 5 min und ≤ 7 min, rot bei einer durchschnittlichen Durchlaufzeit > 7 min.

Für die BPA-Modelle wurden XML-Schemata entwickelt, die die BPA-Modellelemente, die Berechnungsvorschriften, die Beziehungen zwischen den BPA-Modellelementen und die Beziehungen zwischen BPA-Modellelementen und BPMN-Modellelementen enthalten. Mithilfe des XML-Schemas können diese Informationen im Process-Repository mit Bezug zum Prozess abgespeichert werden.

Auf Basis der für den Beispielprozess „Kundenauftrag“ modellierten BPMN- und den dazugehörigen BPA-Modellen wurde im Event Generator ein Simulationsszenario erstellt. Mit den im Szenario festgelegten Parametern für die Simulation, den Definitionen der zu erzeugenden Ereignisse und deren Wertebereiche wurden mehrere Simulationsläufe durchgeführt. Die in den Simulationsläufen generierten Ereignisse wurden dem Process Warehouse kontinuierlich übergeben. Mithilfe der im Process Repository gespeicherten Process- und BPA-Modelle sowie den Ereignisdaten ermittelt das Process Warehouse für die durchgeführten Simulationsläufe permanent die Ergebnisse für die definierten KPI. Der Prozessverantwortliche kann diese KPI-Ergebnisse über das BPA-Cockpit jederzeit abrufen.

Bild 3: User App-BPA-Cockpit für den Beispielprozess „Kundenauftrag“.

Im Bild 3 ist das Ergebnis eines Simulationslaufs für den Prozess „Kundenauftrag“ im BPA-Cockpit beispielhaft veranschaulicht. Zum einen ist die Gesamt-KPI mit der Ampel gelb und zum anderen die KPI für Time, Quality, Cost und Flexibility dargestellt. Im BPMN-Prozessmodell wird für die jeweiligen Teilprozesse die Gesamt-KPI mit ihren Ergebnissen dargestellt. Um die Ursachen dieser Ergebnisse analysieren zu können, besteht die Möglichkeit, die Teilprozesse und deren Detailergebnisse durch Drill-Down näher zu betrachten. In den Teilprozessen sind in gleicher Form die Ergebnisse der KPI bezogen auf Time, Quality, Cost und Flexibility abgebildet.    

 

Schlüsselwörter:

Business Process Analytics, Key Performance Indicator, Process Performance Indicator, BPMN, Modellierung, BPA-Plattform

Literatur:

[1] Gabler Wirtschaftslexikon: http://wirtschaftslexikon.gabler.de/Definition/process-engine.html, abg. am 28.05.2013.
[2] Signavio: http://www.signavio.com/de/news/bpmn-2-0-prozessautomatisierung-mit-jbpm... abg. am 27.05.2013.
[3] Bearing Point: Business Process Management-Studie 2012 - Stärkung der Prozessorientierung im Unternehmen durch nachhaltige Optimierung der Prozess- und IT-Landschaft, Bearing Point GmbH, Frankfurt 2012.
[4] zur Muehlen, M.; Shapiro, R.: Business Process Analytics. In: Rosemann, M.; vom Brocke, J.: Handbook on Business Process Management, Vol. 2, Springer Verlag, Berlin et al. 2009, S. 137 - 160.
[5] PWC: Zukunftsthema Geschäftsprozessmanagement - Eine Studie zum Status quo des Geschäftsprozessmanagements in deutschen und österreichischen Unternehmen, PricewaterhouseCoopers AG Wirtschaftsprüfungsgesellschaft, Frankfurt 2011.
[6] Wetzstein, B.; Ma, Z.; Leymann, F.: Towards Measuring Key Performance Indicators of Semantic Business Processes. In: Proceedings of the 11th International Conference on Business Information Systems (BIS). Innsbruck 2008, S. 227 - 238.
[7] Freund, J.; Rücker, B.: Praxishandbuch BPMN 2.0, 2. Aufl., Carl Hanser Verlag, München, Wien 2010.
[8] Friedenstab, J.-P.: Design of an Integrated Modeling Language for Event-Driven Business Activity Monitoring, Master Thesis at the Chair for Information Systems and Information Management, Westfälische Wilhelms-Universität, Münster 2011.