Process Mining im IT-Service-Management

Im IT Service Management ist eine der wichtigen Fragestellungen, wie man die Serviceprozesse im Sinne des ITIL Continuous Service Improvement (CSI) fortlaufend verbessern kann.
Das ServiceNow System bietet IT Service Managern bereits sehr viele Analyse- und Reporting-Möglichkeiten (z.B. Anzahl und Status von Tickets nach verschiedenen Kriterien wie Zeitraum, Assetklasse, Ticketart, Priorität und SLA-Einhaltung). Um aber einen Prozess wirklich zu verstehen, mögliche Probleme in den Abläufen zu erkennen und damit kontinuierlich verbessern zu können, reicht eine Kennzahl in einem Dashboard leider nicht aus, sondern auch die Geschichte hinter einer Kennzahl muss verstanden werden. Die ARIS Process Mining Software-as-a-Service Lösung der Software AG ermöglicht genau das und darüber hinaus auch noch die Identifizierung möglicher Automatisierungspotenziale.

Process Mining bietet also eine wertvolle Unterstützung, um zu verstehen, wie die Prozesse im IT Service Management tatsächlich ablaufen – von der Teleskop-Ansicht bis hin zur zu Mikroskop-Ansicht – und was man wie im Sinne des ITIL-orientierten Continuous Service Improvement verbessern kann.

Als grundlegende Strukturierung im Process Mining bietet sich unter anderem die Perspektive der End-To-End-Prozesse an.

Tatsächlicher Gegenstand der Process Mining Analyse ist aber in der Praxis oft nicht ein gesamter End-to-End-Prozess sondern lediglich bestimmte Varianten oder Teilbereiche, bei denen Optimierungsbedarf und/oder Optimierungspotenzial besteht. Bei einem „Order-to-Cash“ End-to-End-Prozess kann dies z.B. die Prozessvariante bezogen auf ein bestimmtes Produkt- oder Marktsegment sein – und bei einem „Hire-to-Retire“ End-to-End-Prozess würde man vielleicht nur einzelne Prozess-Teilbereiche, wie z.B. den Recruiting-Prozess, betrachten.

Ein entsprechender Betrachtungsbereich, also eine Variante oder ein Teilbereich eines End-To-End-Prozesses, wird in ARIS Process Mining als jeweils eigenes Projekt dargestellt, wobei jedem Projekt ein eigenständiger Datenbereich zugeordnet ist, ohne jegliche Verbindung zu den jeweils anderen Projekten.

Beim IT Service Management befinden wir uns im sog. End-to-End-Prozess „Issue-to-Resolve“. Die Gliederung orientiert sich hier idealerweise am ITIL-Regelwerk, welches die Untergliederung der Prozessvarianten in Changes, Incidents und Requests vorgibt. Auch bzgl. weiterer Aspekte gibt es beim End-to-End-Prozess Issue-to-Resolve gewisse Besonderheiten.

Während bei den meisten End-To-End-Prozessen ein relevanter Anteil der Wertschöpfung durch die Interaktion innerhalb eines „Anwendungssystems“ stattfindet und sehr häufig mehrere verschiedene Anwendungssysteme innerhalb eines Prozesses involviert sind, verhält sich dies beim End-To-End-Prozess „Issue-To-Resolve“ im Regelfall etwas anders. Die Wertschöpfung an sich findet hier nicht im IT-Service-Management-System statt sondern am jeweiligen Asset bzw. Configuration Item. Das bedeutet, dass das IT-Servicemanagement-System – im vorliegenden Beispiel also ServiceNow – im Wesentlichen nur „zwischen“ den verschiedenen Arbeitsschritten verwendet wird, wenn es darum geht, ein Ticket in die Bearbeitung zu übernehmen, den Status eines Tickets zu verändern, das Ticket an eine Bearbeitungsgruppe zuzuweisen oder bzgl. des Tickets zu kommunizieren. Das IT Service Management System dient also in erster Linie als Protokollierungs- und Kommunikationsplattform. Dementsprechend ergeben sich auch die im System für das Process Mining verwendbaren digitalen Fußspuren, was in erster Linie die „Ticketstati-Wechsel“ und die „Bearbeitungsgruppen-Zuweisungen“ sind.

Eine weitere Besonderheit gegenüber anderen End-to-End-Prozessen, die auch gleichzeitig eine deutliche Komplexitätsreduzierung bedeutet, besteht darin, dass sehr häufig der komplette Issue-to-Resolve-Prozess innerhalb eines einzigen Anwendungssystems, wie z.B. ServiceNow, abgewickelt wird. D.h. es werden i.d.R. nur Daten aus einem einzigen Anwendungssystem benötigt um den gesamten Prozess – in unserem Beispiel den Change-Prozess – zu betrachten.

Betrachten wir uns im nächsten Schritt nun die Daten, die der Process Mining Analyse zugrunde liegen. Hier wird der Punkt „Data Collection“ ausgewählt:

Für die Erstellung einer Process Mining Analyse oder die Aktualisierung einer bestehenden Analyse mit neuen Daten ist ein Import von entsprechenden CSV-Dateien in das System erforderlich.

Bezüglich der zeitlichen Strukturierung ist im IT Service Management eine Analyse auf Monatsbasis sinnvoll, unter anderem da die Einhaltung von Service Levels gegenüber Kunden ebenfalls auf Monatsbasis ermittelt und berichtet wird.

Im vorliegenden Beispiel werden monatlich 5 Dateien importiert. Die wichtigste Datei ist dabei der Event-Log, da diese für alle Change-Tickets jeweils die Case-IDs und alle Aktivitäten mit entsprechendem Zeitstempel enthält. Für die Generierung dieses Event-Logs aus ServiceNow heraus ist vorab zu definieren, welche Arten von Events für die Process-Mining-Analyse relevant sind. Im vorliegenden Beispiel wurden sowohl der Wechsel des Ticketstatus als auch der Wechsel der Zuweisungsgruppe als für die Analyse relevante Events identifiziert und definiert.

Weitere Informationen, die jeweils über die Case-ID, in unserem Fall also die Change-Ticket-Nummer, gemappt werden, können mittels Erweiterungstabellen hinzugefügt werden. Im vorliegenden Beispiel sind dies die Asset-Klasse, der jeweilige Kunde, das jeweilige Service-Level-Ziel und die jeweilige Bearbeitungszeit, die sich aus der Summe der auf den einzelnen Change-Tasks aufgelaufenen Aufwandszeiten ergibt. Mittels der Erweiterungstabellen können bei Bedarf beliebige weitere analyserelevante Ticket-bezogene Informationen hinzugefügt werden, wie z.B. die Prioritätsstufe, die z.B. beim Incident-Prozess von Interesse ist.

Darüber hinaus lassen sich durch die Möglichkeit von arithmetischen Berechnungen innerhalb der Datensätze auch zusätzliche Daten ermitteln, die für die Prozesssteuerung wichtig sind, wie z.B. Prozesskosten als Ergebnis aus der Multiplikation von Bearbeitungszeit und Personalkostensatz.

Wir gehen nun zurück auf unsere Startseite und wählen unsere Issue-To-Resolve Prozessvariante „Changes“

Im ersten Schritt wird nun der Zeitraum der Analyse bestimmt und dem Eintrag „Changes“ nun die Daten des Monats Juni 2020 zugeordnet:

Basierend auf den zugewiesenen Daten lassen sich nun verschiedene Analysen erstellen.

Die Analysen selbst stellen dabei unterschiedliche Betrachtungsschwerpunkte für verschiedene Stakeholder, wie Business Unit Manager, Compliance Manager bzw. Auditoren, Prozess Manager und Service Manager dar. In unserem Beispiel betrachten wir nun die „Business Unit Management“ Perspektive, die einen umfassenden Überblick über alle wesentlichen Aspekte der Prozessanalyse gibt.

Die initiale Sicht in unserer Analyse „Business Unit Management“ ist der Process Explorer. Die in ServiceNow gespeicherten Prozessschritte werden zusammengefügt und der Prozess, wie er tatsächlich abläuft, wird visualisiert. Dadurch wird das in den Daten enthaltene implizite und ansonsten verborgene Prozesswissen greifbar und der Prozess wird rein auf Basis digitaler Fußspuren rekonstruiert.

Im Unterschied zu dem ebenfalls in ARIS verfügbaren EPK- bzw. BPMN-Modell, sehen wir hier, wie der Change Management Prozess in der Realität abläuft, d.h. welche Prozessschritte bei welchem Ticket in welcher Reihenfolge ablaufen.

Der Prozess, wie er als Erstes dargestellt wird, sollte idealerweise der Variante des Prozessablaufs entsprechen, welche man häufig auch als „Happy Path“ oder „Goldstandard“ bezeichnet. Je höher dabei der prozentuale Anteil der angezeigten Aktivitäten und Verbindungen desto besser, da dies entsprechend wenig Abweichungen von diesem Goldstandard-Prozess impliziert.

Durch Erhöhung des Anteils der dargestellten Aktivitäten werden sukzessive weitere Prozessvarianten sichtbar und mögliche Probleme transparent.

Ein Problem, das hier nun sichtbar wird, ist ein Change, der ohne vorherige Genehmigung implementiert wurde. Diesen Fall wollen wir uns genauer betrachten.

Durch einfaches Anklicken dieses Pfades lässt sich entsprechend filtern – hier anhand dieser Filterung zu erkennen – und damit auch sofort ermitteln, um welches Ticket es sich dabei handelt – zu sehen in der App „CASE-DATA“.

Es handelt sich also konkret um das Ticket „CHG0031485“ und nach Lösen der Filterung sind in dieser App nun wieder alle Cases sichtbar.

Auch der Anteil der angezeigten Verbindungen lässt sich sukzessive erhöhen, was bei 100% in der Regel zu einem „Spaghetti-Chart“ führt.

Mittels „Reset“ gehen wir wieder auf unseren Goldstandard-Prozess zurück und betrachten als nächstes nun weitere Apps.

In unserer „Business Unit Management“ Analyse stehen hier folgende Analyse-Apps zur Verfügung.

• Die Durchlaufzeit als Zeitraum zwischen den Kundenkontaktpunkten, also von der Change-Anforderung bis zur Change-Erfüllung
• Die Qualität gemessen an der Fehlerquote aufgrund von Nicht-Abnahmen, Terminverfehlungen und Reklamationen
• Die SLA-Konformität als Ergebnis der Service Level Einhaltung, also der Differenz zwischen dem Service-Level-Ziel und der Durchlaufzeit
• Die Effektivität gemessen an der Erfolgsquote auf Basis von Blindleistungen in Form von Nicht-Genehmigungen und Prozessabbrüchen
• Die Kosteneffizienz auf Basis der Prozesskosten
• Die ITIL-Konformität durch Berücksichtigung nicht ITIL-konformer Prozessabweichungen

Im Detail betrachten wir nun zunächst die App zur Analyse der Durchlaufzeit.

Die zentrale Kennzahl hierbei ist die durchschnittliche Durchlaufzeit über alle Change-Tickets im Betrachtungszeitraum hinweg. Dieser Zeitraum beträgt aktuell 3,56 Wochen beträgt. Im Säulendiagramm ist hier die Gesamt-Durchlaufzeit je Change zusammen mit der jeweils höchsten Einzelaktivitäts-Liegezeit dargestellt.

Auf einen Blick erkennt man hier etwaige Ausreißer und kann sich diese mittels Filterung im Detail betrachten.

Durch Markierung der entsprechenden Säule in der Grafik, können wir uns nun den Change mit der höchsten Durchlaufzeit anschauen. Hierdurch wird der entsprechende Filter über alle Apps hinweg gesetzt und der entsprechende Prozessablauf erscheint. Im Process Explorer sehen wir nun diesen Prozessablauf. Da es offensichtlich ein Problem bzgl. der Durchlaufzeit gibt, schalten wir auf die entsprechende Kennzahlensicht um.

Nun kann man an der farblich hervorgehobenen Verbindung erkennen, dass das Ticket mit einer Zeitverzögerung von 2,83 Monaten an eine andere Zuweisungsgruppe weitergeleitet wurde.

Wir hebe den Filter wieder auf, gelangen zurück zu unserem Standard-Prozess und betrachten nun die App „Kosteneffizienz“.

Als wesentlicher Indikator steht hier auch wieder eine Zahl im Fokus – in diesem Fall die durchschnittlichen Prozesskosten pro Change. Die in dieser App zur Verfügung stehenden grafischen Auswertungen sind im Einzelnen

• die Prozesskosten pro Change
• die durchschnittlichen Prozesskosten pro Kunde
• die Gesamt-Prozesskosten pro Kunde
• die durchschnittlichen Prozesskosten pro Asset-Klasse
• und die Gesamt-Prozesskosten pro Asset-Klasse

Die Apps lassen sich insgesamt sehr einfach und intuitiv erstellen und gestalten, was ARIS Process Mining zu einem sehr flexiblen Werkzeug macht, mit dem sich ITIL Continuous Service Improvement zielgerichtet und effektiv in der täglichen Praxis umsetzen lässt.