Was bedeutet BPM für BI?

In viele Unternehmen hält Prozessmanagement Einzug, zum Beispiel mit BPMN – mehr dazu in unseren Blog. Doch was bedeutet das fürs Data Warehouse bzw. für vorhandene Business Intelligence-Installationen? Wie integriert man dort die neuen Prozessdaten, und wie gelangt man zu einer „Business Process Intelligence“-Lösung?

Wichtig ist zunächst die Erkenntnis: Geschäftsprozesse hat jedes Unternehmen – egal ob sie explizit modelliert werden oder nicht, egal ob die Prozessmodelle in einer Prozesssteuerungsplattform ausgeführt werden oder nur zur Dokumentation dienen. Und diese Geschäftsprozesse hinterlassen Daten in den operativen Systemen, die dann dispositiv ausgewertet werden können.

Sobald aber Prozessmodelle tatsächlich über sogenannte Process Engines zur Ausführung gelangen, erzeugt dies zusätzliche Daten, deren Auswertung für verschiedene Zwecke interessant ist. Beispielsweise wird in diesen Daten erkennbar, welche Prozessschritte wie häufig, mit welcher Dauer und von wem ausgeführt wurden. Mit anderen Worten, an die Seite der – zuvor schon vorhandenen – inhaltlichen Daten treten Prozess-Ausführungsdaten und diese geben Aufschluss über die Effizienz der Prozesse, wie der folgende Screenshot aus dem „viadee Process Warehouse“ zeigt:


Hier ist direkt erkennbar, wie oft welcher Prozessschritt durchlaufen wurde und die Visualisierung zeigt bspw. besonders häufig genutzte Teile des Prozesses an. Es handelt sich um eine Visualisierung direkt am Prozessmodell – diese ergänzt also klassische BI-Frontends.
Solche Prozess-Ausführungsdaten sollten in das Data Warehouse integriert werden. Weiter unten sehen wir uns an, wie das beispielsweise in einem Sternschema aussehen kann. Zunächst betrachten wir jedoch eine wichtige Erweiterung.

Die Ausführungsdaten haben für jedes Prozessmodell die gleiche Struktur, so dass ein generischer Ansatz zur Ablage im DWH verwendet werden kann. Interessant ist aber gerade auch die Verbindung zu den „fachlichen“ Daten, die in einem konkreten Prozessmodell verarbeitet werden – und diese sind je nach Prozess unterschiedlicher Natur. In einem Rechnungslegungsprozess kann zum Beispiel die Rechnungsnummer die Rolle eines fachlichen Schlüssels spielen; die Prozesssteuerungsplattform wird zu jeder Ausführung des Prozesses die dabei verwendete Rechnungsnummer als „Prozesskontext“ abspeichern, neben weiteren Daten wie etwa dem Rechnungsbetrag. In einem Prozess, der die Bearbeitung von Schadensfällen in einer Versicherung steuert, wird eher die Versicherungsscheinnummer oder die Adresse des Kunden Teil des Prozesskontextes sein. Es hängt von der Prozessmodellierung ab und von den IT-Services, die durch den Prozess angesteuert werden, welcher Teil der operativen Daten auch im Prozesskontext auftaucht.

Für das Reporting bzw. die Entscheidungsunterstützung sind aber diese Kontextdaten von besonderer Wichtigkeit, erlauben sie doch – in Kombination mit den sonstigen DWH-Daten – die Beantwortung viel weitergehender Fragestellungen als nur die Ausführungsdaten alleine. Beispiele dafür sind: Benötigen Rechnungen eines bestimmten Lieferanten besonders lange Prozessdurchlaufzeiten? Sind es vielleicht nur Kunden aus einer einzelnen Region, die in bestimmten Prozessschritten häufiger als andere verarbeitet werden?

Idealerweise sollten solche Fragen ebenfalls direkt anhand der Visualisierung des Prozessmodells untersucht werden können, wie der folgende Screenshot zeigt, in dem links ein Panel mit Navigationsmöglichkeiten des DWH ergänzt ist:



Über das Panel ist etwa ein „Drill-down“ zur nächsten Hierarchieebene möglich:


In diesem Beispiel wurden also 3 der 8 Ausführungen des Prozessschrittes „Schaden anlegen“ für Kunden aus Deutschland durchgeführt und im nächsten Drill-down-Schritt kann überprüft werden, wie viele davon in den Regionen „Nord“ bzw. „Süd“ wohnen. Wichtig dabei: Die Zuordnung zur geografischen Region stammt nicht aus dem Prozesskontext, sondern aus dem Data Warehouse! Die geografische Region kommt im Prozess nicht vor. Stattdessen bildet die Variable „Kundennummer“ aus dem Prozesskontext die Brücke zum DWH. Zur Realisierung dieser Idee müssen also beide Datenquellen integriert werden.

Im Folgenden gehen wir beispielhaft von einem Szenario aus, in dem ein DWH bereits vorhanden ist und die Sternschema-Modellierung verwendet. Nun kommt eine Process Engine als weitere Datenquelle hinzu und liefert einerseits Prozess-Ausführungsdaten, andererseits je Prozessausführung einen Prozesskontext, dessen Struktur vom ausgeführten Prozess abhängt. Die Prozess-Ausführungsdaten können generisch in einem eigenen Sternschema abgelegt werden:


Die Dimension „Prozessdefinition“ speichert die verschiedenen Prozessmodelle (Rechnungslegungsprozess, Schadenfallbearbeitung, etc.). In der Dimension „Prozesselement“ sind die einzelnen Prozessschritte wie „Rechnung bezahlen“ oder „Schaden erfassen“ abgelegt. Bei Prozessschritten, die manuell ausgeführt werden, speichert die Dimension „User“, wer den Prozessschritt ausgeführt hat. Die Kennzahlen (Fakten) geben je Prozesselement an, wie häufig es ausgeführt wurde und wie viel Zeit dafür benötigt wurde. Die Dimension „Zeit“ fehlt hier, sie gibt an, wann die Prozessausführung stattfand.

Auf Basis dieses Sternschemas können bereits Visualisierungen wie die im obigen ersten Screenshot realisiert werden. Zu diesen Prozess-Ausführungsdaten kommt nun je nach Prozess der Prozesskontext hinzu, der die Brücke zum DWH bilden kann. Dazu wird das obige Schema um eine weitere Dimension ergänzt – je nach Prozess ist diese Brückendimension unterschiedlich. Damit werden Drill-down-Möglichkeiten geschaffen wie oben im zweiten und dritten Screenshot gezeigt. Für einen Prozess, der eine Kundennummer verarbeitet, könnte die Ergänzung wie folgt aussehen:


Die ergänzende Dimension muss je nach Prozess eigens gebildet und durch eine eigene ETL-Strecke versorgt werden – Aufwand, der jedoch im Vergleich zur Entwicklung des eigentlichen Prozesses und seiner Anbindung an IT-Services sicherlich gering ausfällt.

Übrigens können auf die gleiche Weise natürlich auch prozessspezifische Fakten ergänzt werden. Ein Beispiel dafür wäre „Anzahl Kunden“ (für die der jeweilige Prozessschritt durchlaufen wurde) – eine Kennzahl, die sich von „Anzahl Ausführungen“ (des Prozessschrittes) durchaus unterscheiden kann. Das „viadee Process Warehouse“ bietet die Möglichkeit, solche Kennzahlen interaktiv am Prozessmodell zu definieren.

Der Vorteil der oben beispielhaft gezeigten Modellierungsweise ist, dass die Zusatzdimension – im Beispiel: „Kunde“ – gerade die sowieso im DWH vorhandene Dimension sein kann, die bereits mit dem restlichen DWH verbunden ist. So werden die oben dargestellten integrierten Auswertungen möglich, etwa nach Wohnregion des Kunden, auch wenn der Wohnort nicht im Prozesskontext vorhanden ist.

Außerdem können so auch Metadaten des DWH, wie etwa Hierarchieinformationen, für die Visualisierung wiederverwendet werden – so wie bei der geografischen Navigation in den obigen Screenshots: Die Navigation basiert auf den Hierarchien, die in der BI-Landschaft des Unternehmens bereits definiert wurden, weil sie etwa für klassisches OLAP ebenfalls benötigt werden. Diese Metadaten geben im Beispiel an, dass die Regionen „Nord“ und „Süd“ zum Land „Deutschland“ gehören, womit die Navigation über verschiedene Ebenen der geografischen Hierarchie möglich wird. Die Metadaten wurden über einen Webservice des DWH für die Visualisierung am Prozessmodell veröffentlicht. Sie können also zentral definiert und in verschiedenen Frontends wiederverwendet werden.

Zusammengefasst ergibt sich durch die obige Vorgehensweise eine Architektur, bei der die Process Engine als weitere Datenquelle des DWH gesehen wird und die Visualisierung am Prozessmodell als weiteres Frontend, das neben die klassischen Berichte und OLAP-Werkzeuge tritt und für alle Analysten weitgehende Auswertungsmöglichkeiten im Kontext der modellierten Prozesse bietet.

Sie haben weitere Fragen zur Integration von BI und BPM? Sprechen Sie uns an!

Autor

Dr. Timm Euler war bis September 2020 Senior-Berater bei der viadee IT-Unternehmensberatung und Leiter des F&E-Bereichs Business Intelligence.

Er interessiert sich für alles rund um Big Data, Data Warehousing und Data Mining.