00:00:01,680 --> 00:00:53,300 [Thomas]
Wo ich mich in letzter Zeit relativ viel mit beschäftige, is eben die Aufnahme von Requirements in Unternehmen, auch mit Hilfe von BPM-Workshops beispielsweise, um in Erfahrung zu bringen, wie diverse Fachbereiche beispielsweise arbeiten, wie ein zukünftiger Soll-Prozess aussehen könnte. Und, ähm, was da immer wieder als, als Frage hervorkommt in mir, is quasi, ob sich da nich schon Process Mining sinnvoll einsetzen ließe, auch um mal die Thesen, die behauptet werden, 'n Stück weit zu prüfen und datenbasiert zu evaluieren, ob die kritischen Punkte, die hier vorgebracht werden, auch wirklich so kritisch sind oder ob es, ja, letztlich Befindlichkeiten der Fachbereiche sind. Habt ihr da schon Erfahrungen drin sam-, dran sammeln können und, ähm, auch beispielsweise schon erste Use Cases mit gemacht oder wie seht ihr die Eignung von Process Mining, vor allem zu den Anwendungsfällen? 

00:00:54,580 --> 00:03:04,200 [Lukas]
Ja, also, ähm, wir haben tatsächlich auch unseren, also unseren Ansatz, den wir entwickelt haben, mit dem, mit dem, mit dem kausalen Process Mining, den wir da betreiben. Der basiert eigentlich so'n bisschen auf diesem, auf dieser Thematik, dass eigentlich, ähm, dass man eigentlich immer mit 'ner gewissen Vorahnung, mit 'ner gewissen Vorkenntnis und in meines Erachtens 90 Prozent der Unternehmen auch mit 'ner, mit 'nem gewissen Verständnis von 'nem Prozess, ne. Kann mir also niemand erzählen, der gar keine Ahnung hat vom Prozess. Ähm, irgendwie läuft der, irgendwo is er auch zumindest rudimentär, äh, dokumentiert. Ähm, und unsere Idee damals war ja auch zu sagen, okay, wir nehmen diese Grundbasis, die wir dort haben an Wissen, ähm, und stecken sie in Hypothesen, ja. Äh, letztendlich ist ja das bei uns, wir starten eigentlich mit einer Hypothese, mit einer Prozesshypothese, die am Anfang sehr rudimentär aussehen kann. Ganz simpel. Ähm, ich guck einfach mal, ob so die Hauptprozessschritte irgendwie hintereinander hängen. Ähm, und dann is unsere Idee, zu sagen, wir machen, wir, wir verfeinern das iterativ, ne. Also wir gehen also los mit Hypothese null, ja, und, ähm, lassen dann mal unseren, ähm, Causal Process Mining-Ansatz drüber laufen. Der wird uns dann wahrscheinlich sehr viele Abweichungen zeigen. Der zeigt dann diese, diese tollen Fehlermuster, die man bei uns sieht, ja. Ähm, wo gibt's irgendwelche unerlaubten Reihenfolgefehler? Wo werde ich zurückspringen? Ähm, wo überspringe ich irgendwelche Prüfschritte zum Beispiel? Und dann kann ich mit diesen Informationen hingehen und die Hypothese verfeinern, ne. Dann hab ich also die nächste Version davon. Und, äh, diese, sag ich mal, iterative, äh, Herangehensweise haben wir eigentlich in unseren Ansatz als, als, ja, zentralen Punkt eingebaut. Es gibt ja auch die, die, sag mal, die, die klassische Process-Mining-Welt. Äh, Jan, vielleicht kannst du da gleich auch noch ein bisschen was zu sagen, is eigentlich dieses, auch dieses Pure Discovery. Ja, ich hab mal, ich versuch mal irgendwo 'n Eventlog zu ziehen und dann lass ich mit dem mal, das, jag ich den mal durch 'n Process-Mining-Tool und dann, ähm, kommt dieses Directly Follow, dieser Directly Follows Graph raus, wo ich dann sehr chaotisch die ganzen Pfade sehe. Dann wird, muss aber trotzdem meines Erachtens nach die Frage gestellt werden: Ähm, wie passt jetzt dieses, dieser Spaghetti-Diagramm, was wir da haben, eigentlich mit unseren Prozessen irgendwie überein? Und dann muss ich eigentlich diesen Check im Nachgang auch wieder tun, ne. Also es gibt eigentlich zwei Ansätze meines Erachtens. Entweder man, man fängt mal direkt mit den Daten an und guckt danach im Nachgang oder man integriert das eigentlich direkt am Anfang und geht dann eigentlich iterativ vor. 

00:03:05,440 --> 00:03:40,580 [Thomas]
Find ich, find spannend, wo mich das so'n bisschen oder wo ich da sehr gute Angriffspunkte sehe. Also wenn ich jetzt beispielsweise 'n T BPM Workshop halte, dann hab ich ja genau 'n sehr High-Level-Prozess mit groben Aktivitäten, der da rauspurzelt. Und auf Basis dessen könnte ich ja mal schauen, was oder wie ist dieser Soll-Prozess anders als der derzeitige Ist-Prozess? Wie sieht's auf Basis dessen, was ich modelliert hab, mit Rücksprüngen, Übersprüngen, Verstößen und so weiter und so fort aus, weil das ja auch dann zulässt, dass ich mir Gedanken darüber mache, wo ich Change-Management-technisch ansetzen muss und vielleicht auch 'n Stück weit befähigen muss. 

00:03:40,450 --> 00:04:02,155 [Dominik]
Kann mir vorstellen, dass es zu 'nem geringen Bias, zu 'nem geringen Bias führt, wenn ich erstmals jemandem sag: „Hey, was glaubst du, wie läuft der Prozess ab?“ Und dann in die Analyse gehe, als wenn ich dem das Vorleger sag: „Glaubst du, es läuft so ab?“ Kann mir vorstellen, dass auch spannende Diskussionen dabei entstehen, wenn ich so iterativ vorgehe, weil die Leute sich erst mal Gedanken drüber machen müssen, bevor sie da was vorgelegt bekommen, wo sie sagen: „Check, wird schon irgendwie stimmen.“ 

00:04:03,140 --> 00:05:02,180 [Jan]
Ich mein, das Problem is tatsächlich noch 'n bisschen tiefgreifender. Wenn du, ähm, mit 'nem klassischen Ansatz reingehst, [räuspert sich] dann nimmst du mal an, dass du über den Prozess gar nichts weißt. Du nimmst nur die Daten. Äh, und die klassischen Datenstrukturen, die im Proze..., äh, Process Mining genutzt werden, sind diese Eventlogs. Um so'n Eventlog zu konstruieren, muss ich ganz viel Datensemantik wegschmeißen. Und was ich dann auf Basis von so 'nem Eventlog sehen kann, sind Reihenfolgen. Und Reihenfolgenbeziehungen, Abfolge is nicht gleich Abhängigkeit. Und das is 'n ganz großes Problem. Du kannst viele Dinge sehen, die dann sehr nah beieinander passieren, die überhaupt keine auslösende Charakteristik miteinander verbindet. Und dein klassischer Ansatz zeigt, zeichnet dir dann da 'n hübschen Pfeil. 

00:05:03,240 --> 00:05:03,980 [Lukas]
Verstehe. 

00:05:03,980 --> 00:06:24,152 [Jan]
Und das is wirklich 'n Problem. Äh, wir müssen für unsere Prozesse zuerst einmal verstehen, was sind die Abhängigkeiten? Das heißt, welche Dinge lösen welche anderen Dinge aus oder erfordern, dass andere Dinge abgeschlossen sind, bevor es weitergehen kann. Die Prozesse grad, ähm, in größeren Organisationen sind komplex. Es sind viele Unternehmen, die in verschiedensten Abteilungen einzelne Prozesse abwickeln. Dort passieren Dinge nebenläufig und jeder klassische Geschäftsfall, das weiß jeder, der irgendwann mal Buchführung gelernt hat, äh, ist 'ne zweiseitige Operation. Irgendwas geht rein, was anderes geht raus. Geld geht rein, Ware geht raus. Leistung erbracht, Geld erhalten, ne. Das heißt, du hast in jedem komplexeren Geschäftsprozess zumindest mal diese Zweigliedrigkeit. Und diese Zweigliedrigkeit passiert mit verwobenen Abhängigkeiten untereinander. Mhm, aber auch teilweise nebenläufig. Das heißt, die Leute, die die Rechnung freigeben, die haben nichts direkt mit den Leuten in der Lagerhaltung zu tun. Und diese Nebenläufigkeiten führen dazu, dass ich, äh, wenn ich nur Abfolgen betrachte, also was zeitlich nah beieinander ist, äh, dass ich da all diese Pfeilchen bekomme- 

00:06:24,672 --> 00:06:25,372 [Thomas]
Die nichts miteinander zu tun haben. 

00:06:25,372 --> 00:08:06,652 [Jan]
-die keinen semantischen Gehalt haben, ja. Das ist 'n ganz großes Problem, warum wir bei un..., äh, bei dem kausalen Ansatz zuerst immer verstehen wollen, welche Objekte hängen miteinander auslösend zueinander in Beziehung. Und das definiert dann das Gerüst, auf den ich die Ereignisdaten projizieren kann. Und was ich dann sehe, ist einerseits so zu achtzig Prozents die Ereignisse und deren Beziehungen, die damit konsistent sind und die vielleicht zwanzig, manchmal sind's mehr, manchmal sind's weniger Prozents, die dem widersprechen. Und das sind dann die Dinge, über die ich sprechen muss. Warum ist jetzt hier, äh, etwas freigegeben worden, obwohl keine Purchase Requisition vorher angelegt wurde? Und das sind Dinge, die vielleicht gewünscht sind oder die in irgend 'ner gewissen Situation erforderlich waren oder Dinge, die vielleicht auch einfach falsch sind oder vielleicht sogar betrügerisch im Unternehmen passiert sind. Und das muss dann im Detail diskutiert werden. Das müssen sich dann die Analysten anschauen, äh, entweder aus 'ner Perspektive, dass ich besser werden will. Das wär so halt Performance. Äh, ich will halt meine Effizienz steigern. Oder aus 'ner Compliance-Perspektive, ähm, wo ich darstellen muss, dass ich gewisse Regeln einhalte oder auch aus 'ner Audit-Perspektive, äh, wo ich, äh, belegen muss, äh, als Vorstand, dass alles ordnungsgemäß geschäftlich abgewickelt und dargestellt ist, dass meine Bilanz 'n realistisches Abbild meines Geschäftes ist. Und dafür brauchen wir halt diese kausalen Abhängigkeiten im Prozess, äh, die wir als Basis brauchen, um aus den Ereignissen heraus überhaupt zuerst mal 'n Sinn zu erkennen, was in dem Prozess passiert. 

00:08:07,372 --> 00:09:16,292 [Lukas]
Und vielleicht noch als Ergänzung, was wir dafür nutzen, vielleicht auch interessant. Wir, wir sagen eigentlich, wir nutzen drei Informationsquellen dafür. Quelle eins, ganz unten, sozusagen die Basis, sind Schemainformationen aus der Datenbank. Man kann 'n bisschen was schon herleiten über, wie Datenobjekte zusammenhängen, ne. Man kann also über Kardinalitäten, eins zu n, n zu m, kann man 'n bisschen was ableiten. Ähm, Kopftabelle, ne, Tabelle, die drunter hängt und so weiter. Ähm, als zweite Schicht sozusagen obendrauf dann KI, also ein LLM, was versucht zu interpretieren, welche Geschäftsobjekte machen denn kausal Sinn hintereinander, ja. Also ich, ich brauch erst 'n Auftrag, bevor ich das, den Auftrag kommissionieren kann, ne. Andersrum macht's kausal wenig Sinn. Und dann als dritte Komponente nehmen wir eben den Menschen hinzu. Der kann dann diese, diese vorgeschlagene Hypothese dann noch mal validieren. Das muss er auch in der Regel, weil jedes Unternehmen ist noch mal domänenspezifisch und kann dann noch die, die menschliche Sicht drauflegen, ne. Und diese drei Quellen sind dann eigentlich das, das Grundkonstrukt für unsere, für diese Hypothese, von der ich vorher gesprochen hab. Ähm, und dann lassen wir die Zeitachse drüber laufen oder die, die Zeit, äh, gucken wir sozusagen, wie die Zeitstempel über diese Hypothese passen. So bildet sich das dann bei uns. 

00:09:16,352 --> 00:09:37,192 [Thomas]
Ja, spannend. Du hattest schon angesprochen, klassische Event Logs. Da hab ich noch eine etwas zynische Frage: Wenn ich jetzt dieses Spaghetti Diagram hier aus 'nem Tool rauslasse, welche Aussage kann ich treffen, wenn ich das nur auf Basis von Event Logs erstellt habe? Also das sieht immer ganz toll aus, wenn's 'n riesiges Spaghetti-Diagramm ist. 

00:09:37,192 --> 00:09:38,172 [Lukas]
Kann man auch toll animieren in vielen Fällen. 

00:09:38,172 --> 00:09:49,452 [Thomas]
Kann man auch toll animieren, genau. Und dann kann man sehen, das war der Prozess mit der, äh, kürzesten Durchlauffrequenz, weil er Sachen übersprungen hat. Aber es sagt mir ja nichts letztlich da-- Oder was nützt es mir? 

00:09:49,472 --> 00:10:32,452 [Jan]
Was Leute, was Leute, die Leute machen, ist halt einfach, ähm, sie filtern dann. Sie schmeißen so lange Sachen weg, bis sie halt irgendwas sehen, bis sich irgendwelche Muster rauskristallisieren. Das sind dann meistens dann auch, äh, so die, die typischen oder die stärkeren Abfolgen, die man dann sieht. Ähm, aber es versperrt einem dann halt auch wieder den Blick darauf, äh, zu verstehen, wie dieses typische oder häufige Verhalten sich verhält, äh, zu dem nicht so häufigen Verhalten, ne. Und du weißt halt nicht, ob dann das nicht häufige Verhalten, ähm, ob das als Abweichung zu verstehen ist, äh, oder ob das, ähm, ob das okay ist gemäß der Regeln, die wir uns im Unternehmen vorhalten.