Process Mining – Warum, wofür, wie? - Teil 2
Potentielle Fallstricke – just to make you aware
Nach dieser kurzen technischen Einführung sei gesagt: Ja, wir finden Process Mining auch super. Schließlich bieten wir Software an, die Ihnen ermöglicht Daten dafür zu extrahieren, und wir erstellen Ihnen automatisiert Event Logs.
Womit wir aber schon bei möglichen Fallstricken sind, die Sie kennen sollten.
- Sie sehen nur, was Sie kennen (bzw. modellieren)
- Vorsicht vor dem Spaghettimonster – Zu viel Insight, no Action
- Schraubenzieher und Nagel – das Werkzeug passend zur Aufgabe wählen
Was es damit auf sich hat, erkläre ich hier etwas detaillierter:
Sie sehen nur was Sie sehen (bzw. modellieren)
Es kann der Eindruck entstehen (bzw. manchmal wird er bewusst vermittelt), dass man wie durch Zauberhand alle Prozesse im Unternehmen plötzlich basierend auf Echtdaten im Ist-Zustand vor sich visualisiert vorliegen hat. Da tritt jedoch oft etwas Ernüchterung ein, denn dies ist nicht der Fall:
Wie oben kurz erläutert, ist eine Vorbedingung für die Nutzung entsprechender Tools die Erstellung bzw. Modellierung eines Event Logs. Dieses wird dann emotionslos von der Process Mining Software visualisiert. Das bedeutet aber im Umkehrschluss, wenn ich datenseitig etwas nicht kenne, und nicht ins Event Log aufnehme, wird es auch nicht visualisiert. Wenn Sie etwa einen Einkaufsprozess haben, der sich über System A, B und C erstreckt, und die Daten aus System B nicht in das Event Log aufnehmen, dann fehlen diese (und alle Events, Cases etc.) auch im Prozessgraphen. Ebenso können Informationen fehlen oder falsch dargestellt werden, wenn man sich auf falsche Case IDs stürzt oder die Attribute, die die Events definieren, unglücklich gewählt hat. Vielleicht fällt es bei der späteren Betrachtung des Prozessgraphen auf, dass es datenseitig Logiklücken gibt – ein Selbstläufer ist es aber nicht.
Bei der Ermittlung aller Ist-Prozesse ist Process Mining kein Selbstläufer; die Prozessvisualisierung ist nur so gut wie das Event Log auf dem es basiert.
Vorsicht vor dem Spaghettimonster – zu viel Insight no Action
In Sachen Datenanalyse wird ja häufig gefordert, dass man dem Schritt „from insight to action“ schaffen muss, damit Zählbares bewirkt wird, und nicht einfach im Datenanalyseäther verpufft.
Auf Process Mining bezogen, ist das bei beispielhaften Graphen der einfacheren Art auch noch einfach vorstellbar:
Von Bestellung bis Rechnung (PAF Beispiel)
Allerdings ist auch hier die Welt in der Regel komplex. Solche Graphen kommen bei größeren Unternehmen eigentlich nur dann zu Stande, wenn man die Zahl der vorkommenden Prozessvarianten über die Optionen bzw. den Variantenschieber entsprechend reduziert; sich also nicht alle Pfade die vorgekommen sind einblenden lässt, sondern nur den relevanten Teil der Pfade (z.B. die 10% der Relevantesten). Blendet man dagegen alle Pfadvarianten ein, die vorgekommen sind, dann sieht das schnell mal so oder ähnlich aus:
Spaghettimonster bei Ansicht aller Pfade
Die Grafik stammt aus dem Blogpost meines Kollegen, den ich bereits erwähnt hatte. Ich konnte mir quasi das Kochen der Spaghetti sparen.
Als ob die Komplexität nun nicht schon groß genug wäre, stecken ja hinter den Pfaden nun auch noch Geschäftsvorfälle, die sich wiederum in einzelne Transaktionen (Teilprozessschritte) aufteilen: Ein Bestellvorgang teilt sich auf in Bestellnummer 123, die Wareneingänge A, B und C, die Rechnungseingänge X und Y, das Teilstorno S und den Zahlungsausgang Z (wobei die Buchstaben jeweils für eigene Belege bzw. Dokumente stehen, die man vielleicht im System nachvollziehen möchte. Diese sind aber oft nicht auf den ersten Blick ersichtlich oder manchmal vielleicht zwar mit den entsprechenden Belegnummern aufgeführt, aber mit zu wenig Attributen ausgestattet, um auf den ersten Blick Gründe für unüblich wirkenden Prozesse zu erkennen und entsprechend Handlungen zu definieren, die diese verbessern.
Die Erkenntnisse aus diesen komplexen Visualisierungen mit manchmal schwierigem Durchstieg auf die dahinter liegenden Einzeltransaktionen im Quellsystem machen es also zu einer Herausforderung, die Ergebnisse zu verstehen, sowie konkreten Handlungsbedarf daraus abzuleiten und entsprechend auch in Aktionen umzusetzen.
Aus einem Prozessgraphen direkt konkrete Handlungen abzuleiten kann eine Herausforderung sein; von der effizienten Identifikation von Einzeltransaktionen ganz zu schweigen.
Schraubenzieher und Nagel – das Werkzeug passend zur Aufgabe wählen
Process Mining ist hervorragend geeignet, um Prozesse visualisieren. Es ist jedoch schwierig bis unmöglich, alle möglichen analytischen Fragestellungen damit per se zu erschlagen. Ein Beispiel: Man könnte meinen, dass sich Doppelzahlungen mittels Process Mining gut identifizieren lassen könnten – man möge doch einfach nach Fällen suchen, in denen von einer Rechnung zweimal eine Zahlung im Prozess angesteuert wird. So funktioniert das aber nicht: Doppelzahlungen entstehen, indem mehrfach Rechnungen ins System gebucht und jeweils eine eigene Zahlung der doppelt eingebuchten Rechnung (oder Gutschrift) vorgenommen wird. Auch Stammdatenduplikate bei Kunden oder Lieferanten, Fuzzy Ähnlichkeiten bei Bankverbindungsänderungen etc. lassen sich nicht, kaum oder bestenfalls über Umwege mittels Process Mining analysieren.
Hier sind klassische Reports, basierend auf deterministischen Filtern und transaktionsbezogenen Analysen geeigneter. Mit Letzteren könnte man im Gegenzug zwar auch über Umwege Prozessabläufe analysieren, wird aber bei der Interpretation und Visualisierung an seine Grenzen stoßen. Deshalb gilt es, das richtige Werkzeug für die richtige Aufgabe zu wählen. Oft trifft man auf komplementäre Ansätze, denn Process Mining und transaktionsbezogene Analysen ergänzen sich in der Regel hervorragend. Als Beispiel sind zum Beispiel die Bereiche Interne Revision oder Wirtschaftsprüfung zu nennen. Hier ist die Konstellation schlagkräftig, dass sich vor einem Audit mittels Process Mining ein Überblick über die Prozesse zu verschafft wird, um dann zielgerichteter mittels transaktionsbasierter Analysen einzelne Prozessbereiche zu Beleuchten. Das macht auch Sinn – im Werkzeugkasten eines versierten Handwerkers finden sich auch eine Auswahl an Tools für verschiedene Zwecke.
Process Mining ist prima für prozessbasierte Fragestellungen (klingt logisch); andere analytische Fragestellungen sind besser im Bereich transaktionsbasierter Analysen aufgehoben. Die Mischung aus beiden Ansätzen kann sehr schlagkräftig sein.
Zwischenfazit – Braucht man Process Mining?
Nachdem wir ein rudimentäres technisches Verständnis in Sachen Eventlogs aufgebaut und einige potenzielle Fallstricke besprochen haben, mag sich bei kritischen Lesern die Frage stellen, ob man Process Mining denn überhaupt zwingend in Betracht ziehen sollte.
Die Antwort ist ganz klar, ja. Process Mining bietet Ihnen zusätzlich zu transaktionsbasierten Analysen eine komplementäre Sicht auf Ihre Daten mit Schwerpunkt auf Ihren Prozessen. Die Transparenz, die damit geschaffen werden kann, ist – alle Fallstricke in Ehren – einmalig und aus dem erweiterten Kreis der Datenanalyse nicht mehr wegzudenken. Wichtig ist, dass man einerseits der Datenbeschaffung und Aufbereitung die Bedeutung zumisst, die dieser Bereich hat, und es nicht als Selbstläufer versteht. Zweitens sind die Fragestellungen, die man beantworten möchte, in Hinblick auf Ihre Eignung für Process Mining jeweils abzuwägen. Manchen Anforderungen im Bereich Audit, Risikomanagement, IKS oder im allgemeinen Reporting wird man mit anderen Tools ggf. einfach besser gerecht. Umgekehrt zu versuchen, Prozessanalysen in transaktionsbasierten Tools abzubilden wird ebenso wenig von Erfolg gekrönt sein. Drittens ist es wichtig, sich bereits zu Beginn darüber im Klaren zu werden, was das Ziel des Einsatzes von Process Mining ist: Wie schafft man es, von den Fragestellungen hin zu definierten Aktionen zu kommen?
Process Mining sollte heutzutage zum Standardrepertoire im Datenanalyseportfolio eines Unternehmens gehören. Erfolgreich wird es, wenn Datenbeschaffung + Aufbereitung korrekt sind, das Tool zu den Fragestellungen passt und die Ergebnisse „actionable“ genug sind.