Celonis Alternative für ITSM: Warum IT-Prozesse einen anderen Ansatz brauchen
Celonis ist der Marktführer im Process Mining. Die Stärke liegt bei ERP-Prozessen. Für ITSM-Prozesse gibt es eine Alternative – nicht mehr Technologie, sondern gezielter eingesetzte Diagnostik.
Process Mining wurde für andere Datenstrukturen entwickelt
Process Mining entstand im Kontext von ERP-Systemen. Procure-to-Pay, Order-to-Cash, SAP-Transaktionen – Prozesse mit definierten Schritten und klaren Soll-Abläufen. Die Methode: Process Discovery. Das Ergebnis: BPMN-Modelle, die zeigen, welche Prozessvarianten existieren.
ITSM-Daten haben eine andere Struktur. Ein SAP-Prozess hat feste Schritte: Bestellung anlegen, Freigabe erteilen, Ware empfangen, Rechnung buchen. Ein ITSM-Ticket hat das nicht. Es wird erstellt, einer Rolle zugewiesen und wandert – mal linear, mal im Kreis.
73 Prozent der Tickets laufen über denselben Pfad. Die restlichen 27 Prozent verteilen sich auf bis zu 14 verschiedene Routen. Im ERP ist eine Abweichung vom Standardprozess eine Konformitätsverletzung. Im ITSM ist variable Weiterleitung der Normalfall – sie gehört zum Arbeitsprinzip.
Wenn ein Netzwerk-Ticket vom Service Desk an Network Operations geht und zurückkommt, ist das kein Prozessfehler. Es ist eine Zuständigkeitsfrage. Process-Discovery-Modelle zeigen diese Varianz, aber sie ordnen sie nicht ein. Die Visualisierung wird bei 14 Pfadvarianten komplex – und die entscheidende Frage bleibt offen.
Die relevante Frage im ITSM ist nicht: „Welche Variante nimmt das Ticket?" Sondern: „Welche Rolle staut? Warum? Seit wann?" Die Analyseeinheit ist die Rolle, nicht die Prozessinstanz. Wer eine Alternative sucht, braucht einen Ansatz, der auf diese Fragen zugeschnitten ist.
Das bedeutet nicht, dass Process Mining für ITSM generell ungeeignet ist. Es bedeutet, dass die Stärken der Methode – Variantenanalyse, Konformitätsprüfung, Soll-Ist-Vergleich – bei ITSM-Daten weniger Hebelwirkung entfalten als bei ERP-Daten. Die Frage ist nicht besser oder schlechter. Die Frage ist: passend oder unpassend für das konkrete Problem.
ITSM-Prozessanalyse braucht Diagnostik, nicht Modellierung
Standard-Dashboards zeigen Metriken: MTTR, SLA-Einhaltung, Ticket-Volumen. Process Mining zeigt Varianten und Konformität. Beides beantwortet die Frage „Was passiert?" Keine der beiden Methoden beantwortet „Warum?"
IT-Teams brauchen keine weiteren Modelle. Sie brauchen Diagnosen. Konkrete Befunde: Diese Rolle staut. Diese Kategorie wird gemieden. Bei diesem Vorgänger verdoppelt sich die Bearbeitungszeit. Diese Kombination aus Rolle und Standort erzeugt eine Abweichung um den Faktor 3,25.
Der Unterschied zur Alternative liegt in der Analyseeinheit. Process Mining analysiert die Prozessinstanz – ein einzelnes Ticket von Erstellung bis Abschluss. Finding-basierte Diagnostik analysiert die Rolle: Wie verhält sich ein Team über tausende Tickets hinweg? Wo gibt es systematische Muster?
Ein Beispiel: 803 Tickets durchlaufen eine Rolle mit einem Median von 78 Stunden. Der Normalwert vergleichbarer Rollen liegt bei 24 Stunden. Der Abweichungsfaktor beträgt 3,25. Das ist kein einzelnes langsames Ticket. Das ist ein strukturelles Muster – sichtbar nur durch rollenbasierte Analyse.
Ein BPMN-Modell zeigt, dass Tickets durch diese Rolle fließen. Es zeigt nicht, dass sie dort im Median dreimal länger liegen als bei Vergleichsrollen.
Hinter solchen Mustern stecken nachvollziehbare Ursachen. Der Zufluss übersteigt die Kapazität. Bestimmte Kategorien werden gemieden. Teams optimieren lokal, erzeugen aber Rückstau anderswo. Das sind keine Schuldzuweisungen – das sind Mensch-Prozess-Brüche, die in Daten sichtbar werden. Process Mining misst den Prozess. Die Alternative misst, was Menschen im Prozess tun.
Wer die tatsächliche Alternative zu Process Mining für ITSM sucht, braucht keine bessere Prozessvisualisierung. Sondern automatisierte Befunderkennung.
Zwei CSV-Dateien statt Systemintegration
Process-Mining-Plattformen setzen auf Konnektoren zu Quellsystemen – SAP, Oracle, Salesforce und andere. Die Integration erfordert je nach Umgebung Projektbudget, Datenmapping und Berechtigungskonzepte. Der Zeitrahmen variiert: von wenigen Wochen bis zu mehreren Monaten.
Process Radar als Alternative braucht zwei CSV-Dateien. Tickets (Stammdaten mit Erstellungs- und Abschlussdatum) und TicketHistory (Statusänderungen und Rollenzuweisungen). Jedes gängige ITSM-Tool kann diese Daten exportieren: Matrix42, Jira Service Management, ServiceNow, TOPdesk. Die erste Analyse steht in 15 Minuten – ohne Projektbudget, ohne Consulting.
Die Pipeline verarbeitet die Daten automatisch in 11 Schritten. Vom CSV-Import über Normalisierung und Intervall-Konstruktion bis zu Hold-Zeit-Berechnung, Finding-Generierung und Scoring. Am Ende stehen priorisierte Befunde mit Schweregrad – kein generisches Prozessmodell.
23 Finding-Typen werden automatisch geprüft. Von Rollenengpässen über Ping-Pong-Muster bis zu Kaskadeneffekten über mehrere Teams hinweg. Jeder Befund enthält konkrete Zahlen: Abweichungsfaktor, Anzahl betroffener Tickets, zeitlicher Impact in Stunden.
Jedes Finding durchläuft ein dreistufiges Scoring. Die Einstufung basiert auf Impact-Stunden und Abweichungsfaktor: Kritisch ab 100 Stunden Impact oder 3-facher Abweichung. Bemerkenswert ab 20 Stunden oder 2-facher Abweichung. Beobachtet für alles darunter. Deterministische Berechnung. Reproduzierbare Ergebnisse.
Gegenüberstellung: Process Mining vs. Finding-basierte Diagnostik
| Aspekt | Process Mining (z. B. Celonis) | Finding-basierte Diagnostik (Process Radar) | |---|---|---| | Typischer Fokus | ERP-Prozesse (P2P, O2C) | ITSM-Prozesse (Tickets, Routing) | | Datenquelle | Konnektoren zu SAP, Oracle u. a. | 2 CSV-Dateien (Tickets + History) | | Methode | Process Discovery + Conformance | Automatische Finding-Generierung | | Analyseeinheit | Prozessinstanz (das Ticket) | Rolle (das Team) | | Setup-Zeit | Je nach Integration variabel | 15 Minuten | | Ergebnis | Prozessmodell (BPMN) | Priorisierte Findings + Handlungsempfehlungen |
Diese Gegenüberstellung basiert auf öffentlich verfügbaren Produktinformationen (Stand: April 2026). Als Anbieter von Process Radar ist unsere Perspektive nicht neutral. Für verbindliche Informationen zu anderen Anbietern besuchen Sie deren Website.
Was die Alternative für ITSM-Teams sichtbar macht
Die 23 Finding-Typen decken fünf Mensch-Prozess-Brüche ab. Kein technisches Versagen. Nachvollziehbares menschliches Verhalten, das im Aggregat strukturelle Probleme erzeugt. Jeder Bruch hat eine Ursache – und die liegt selten beim einzelnen Mitarbeiter.
Rollenengpässe. Eine Rolle empfängt mehr Tickets als sie verarbeiten kann. Der Backlog wächst, die Verweildauer steigt. Finding F1 erkennt den Aufstau automatisch – ab einem Abweichungsfaktor von 1,5 gegenüber dem Peer-Median. Bei 803 Tickets mit 4,1-fachem Median ist das keine statistische Randnotiz. Das ist ein Kapazitätsengpass, der strukturelle Maßnahmen braucht.
Routing-Schleifen. Tickets wandern zwischen Rollen hin und her. A schickt an B, B schickt zurück an A. Finding F7 erkennt dieses Ping-Pong-Muster und berechnet die Rate pro Standort und Kategorie. Ab 10 Prozent aller Tickets ist es ein Befund. Ab 30 Prozent kritisch. In typischen ITSM-Umgebungen liegt die Rate bei 15 bis 25 Prozent – deutlich höher als die meisten IT-Leiter vermuten. Jede Umleitung verlängert die Durchlaufzeit im Median um 40 Prozent. Details zu diesem Muster: Ticket-Routing optimieren.
Kaskadeneffekte. Eine überlastete Rolle erzeugt Rückstau bei nachgelagerten Rollen. Der Engpass pflanzt sich fort – oft über drei oder vier Stationen. Finding F_CASCADE erkennt die zeitliche Korrelation zwischen Rollen. Wenn Rolle A eine Verzögerung von zwei Wochen aufbaut, trifft der Rückstau Rolle B mit einer Woche Verzögerung. Ab einer Korrelation von 0,5 zwischen zwei Rollen wird das Finding ausgelöst.
Wartezeit-Dominanz. Tickets stehen nicht in Bearbeitung, sondern auf „On Hold" oder „Waiting for Customer". Finding F5 erkennt Rollen, bei denen mehr als 30 Prozent der Verweildauer im Hold-Status verbracht wird. Die effektive Bearbeitungszeit wird automatisch berechnet: Gesamtzeit minus Hold-Segmente. So wird sichtbar, ob ein Team langsam arbeitet oder ob externe Abhängigkeiten bremsen.
Vorgänger-Abhängigkeiten. Die Bearbeitungszeit einer Rolle hängt davon ab, welches Team vorher zuständig war. Tickets von Team A brauchen bei Team C im Median 30 Stunden. Tickets von Team B nur 10 Stunden. Finding F_PREDECESSOR zeigt: Das Problem liegt nicht bei Team C. Sondern an der Qualität der Übergabe – und diese Alternative macht den Zusammenhang sichtbar.
Jeder Befund erhält eine Schweregrad-Einstufung. Drei Stufen: kritisch, bemerkenswert, beobachtet. Die Schwellen sind transparent: Kritisch ab 100 Stunden Impact oder 3-facher Abweichung. Bemerkenswert ab 20 Stunden oder 2-facher Abweichung. Das Scoring ist deterministisch und reproduzierbar – keine Interpretation nötig, nur die richtigen Kennzahlen.
Für wen die Alternative die bessere Wahl ist
Process Radar ist kein Process-Mining-Tool. Es ist ein anderer Analyseansatz für ein anderes Problemfeld. Die richtige Wahl hängt von drei Fragen ab.
Welche Daten? ERP-Transaktionslogs mit definierten Prozessschritten passen zu Process Mining. ITSM-Ticket-Daten mit variablen Routing-Pfaden und Rollenzuweisungen passen zur Alternative. Der Einstieg bei Process Radar: zwei CSV-Dateien exportieren, hochladen, fertig.
Welches Team? Unternehmen mit dedizierten Process-Mining-Teams und Consulting-Budget finden in etablierten Plattformen ein mächtiges Werkzeug. IT-Leiter, die ohne Projektaufwand ihre Engpässe sehen wollen, starten mit Process Radar in 15 Minuten. Kein Berater nötig. Kein Datenmapping. Kein Berechtigungskonzept.
Welches Ergebnis? Wer Prozessvarianten visualisieren und BPMN-Modelle erzeugen will, braucht Process Mining. Wer priorisierte Befunde mit konkreten Handlungsempfehlungen will, braucht Finding-basierte Diagnostik.
Der typische Fit für Process Radar: Mittelständische IT-Organisationen mit 5.000 bis 100.000 Tickets pro Jahr. Teams ohne dediziertes Process-Mining-Team. IT-Leiter, die Engpässe verstehen wollen – nicht Prozessmodelle bauen.
Auch das Gegenbeispiel ist wichtig. Wenn Ihr Hauptproblem in ERP-Prozessen liegt – Rechnungslauf, Beschaffung, Logistik – ist Process Mining die richtige Methode. Wenn Sie bereits ein Process-Mining-Team haben und ITSM als weiteren Anwendungsfall ergänzen wollen, kann das ebenfalls sinnvoll sein. Die Alternative wird dann relevant, wenn Sie schnell und ohne Projekt starten wollen.
Die ehrliche Einordnung: Process Mining ist die richtige Methode für ERP-Workflows mit klaren Soll-Prozessen. Für ITSM-Prozesse ist die Alternative ein Werkzeug, das genau für dieses Problemfeld gebaut wurde. Nicht mehr. Aber auch nicht weniger.
2 CSV-Dateien als Datenquelle · 23 Finding-Typen automatisch geprüft · 15 Min. bis zur ersten Analyse
Laden Sie Ihre Ticket-Daten hoch. Die erste Analyse ist kostenlos. Kostenlos starten →