Celonis-Alternative für ITSM: Warum IT-Prozesse einen anderen Ansatz brauchen
Zusammenfassung: Celonis ist die führende Process-Mining-Plattform für ERP-Prozesse — Procure-to-Pay, Order-to-Cash, SAP-Transaktionslogs. Für ITSM-Daten ist Process Mining die falsche Methode: Tickets haben keine festen Soll-Abläufe, variable Weiterleitung gehört zum Arbeitsprinzip. Process Radar ist die Process-Mining-Alternative für ITSM und damit eine schlanke Form der ITSM-Prozessanalyse: Finding-basierte Diagnostik statt Process Discovery, Rollen-Routing statt Prozessinstanz, Stunden statt Monate. Beide Ansätze ergänzen sich — sie konkurrieren nicht.
Celonis ist die führende Process-Mining-Plattform. Ihre Stärke: ERP-Prozesse mit festen Soll-Abläufen – Procure-to-Pay, Order-to-Cash, SAP-Transaktionslogs. Process Radar ersetzt Celonis nicht, sondern besetzt einen anderen Raum. Gegenstand: Rollen-Routing in ITSM-Daten. Methode: Finding-basierte Diagnostik statt Process Discovery. Wer beides analysiert, kombiniert die Ansätze, statt sich für einen zu entscheiden.
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 für ITSM einen passenden Ansatz sucht, braucht eine Methode, die auf diese Fragen zugeschnitten ist – und ergänzt damit Process Mining, wo es um ERP-Prozesse geht.
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 zwischen beiden Methoden 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. Finding-basierte Diagnostik misst, was Menschen im Prozess tun.
Wer für ITSM die passende Methode sucht, braucht keine bessere Prozessvisualisierung. Sondern automatisierte Befunderkennung. Für ERP-Workflows bleibt Process Mining die richtige Wahl – die beiden Ansätze ergänzen sich, statt sich zu ersetzen.
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 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. Details zum Export-Weg pro System und den typischen Stolpersteinen: Ticket-CSV-Export analysieren.
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 rollenbasierte Diagnostik im ITSM 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. Der Prozess-Engpass 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. Der Ping-Pong-Effekt erkennt dieses 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. Die Stau-Kaskade 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 signifikanten Korrelation zwischen zwei Rollen wird das Finding ausgelöst.
Wartezeit-Dominanz. Tickets stehen nicht in Bearbeitung, sondern auf „On Hold" oder „Waiting for Customer". Das Wartezeit-Problem 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. Das Übergabe-Problem zeigt: Das Problem liegt nicht bei Team C. Sondern an der Qualität der Übergabe – und Process Radar 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.
Beide Ansätze ergänzen sich, statt sich zu ersetzen
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 rollenbasierten Diagnostik. 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.
Die beiden Ansätze schließen sich nicht aus. Wer ERP mit Celonis und ITSM mit Process Radar analysiert, nutzt jede Methode dort, wo sie greift. Das ist die häufigste Konstellation in der Praxis: Process-Excellence-Teams decken ihre ERP-Workflows ab, während IT-Leiter ihre Service-Desk-Strukturen parallel diagnostizieren. Keine Kannibalisierung. Keine Doppelinvestition. Zwei Werkzeuge für zwei Problemfelder.
Die ehrliche Einordnung: Process Mining ist die richtige Methode für ERP-Workflows mit klaren Soll-Prozessen. Für ITSM-Prozesse ist Process Radar ein Werkzeug, das genau für dieses Problemfeld gebaut wurde. Nicht mehr. Aber auch nicht weniger. Detailvergleich Process Radar vs. Process Mining →
Wann Process Radar nicht passt
Nicht jede Organisation hat denselben Bedarf. Vier Szenarien, in denen Process Mining oder ein anderes Werkzeug die bessere Wahl ist.
Wenn ERP-Prozesse das Hauptthema sind. Procure-to-Pay, Order-to-Cash, Rechnungslauf, Beschaffungsfreigaben — dort haben Transaktionen feste Soll-Schritte. Process Mining mit Conformance Checking zeigt Abweichungen vom Soll. Process Radar analysiert Rollen-Routing in Ticket-Daten, nicht ERP-Transaktionen.
Wenn Sie BPMN-Modelle brauchen. Compliance-Audits, Zertifizierungen und Dokumentationspflichten verlangen oft formale Prozessmodelle. Process Radar erzeugt keine BPMN. Es erzeugt priorisierte Befunde mit Handlungsempfehlungen — das ist eine andere Artefakt-Klasse.
Wenn die Ticket-Menge unter 5.000 pro Jahr liegt. Finding-basierte Diagnostik lebt von statistischen Mustern über tausende Datenpunkte. Bei sehr kleinen Volumina werden die Befunde volatil — einzelne Ausreißer verzerren die Statistik stärker als strukturelle Muster. In diesem Fall reichen Excel-Auswertung und Gespräche mit den Teams.
Wenn ein dediziertes Process-Mining-Team bereits etabliert ist. Teams mit Celonis-, Signavio- oder UiPath-Process-Mining-Setup plus Data-Engineering-Ressourcen ergänzen ITSM selten durch ein zweites Werkzeug. Wenn das bestehende Team auch ITSM abdecken kann, ist das oft die wirtschaftlichere Entscheidung — auch wenn die Methode für ITSM weniger passgenau ist.
Für alle anderen Fälle — mittelständische IT-Organisationen mit 5.000 bis 100.000 Tickets pro Jahr, ohne dediziertes Process-Mining-Team — ist Process Radar genau richtig dimensioniert. Die ehrliche Abgrenzung macht die Entscheidung leichter, nicht schwerer.
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 →