Automatisieren Sie nicht
den Umweg.
Process Radar zeigt, wo es zwischen Ihren Teams hakt, bevor Sie es schneller machen: an welchem Standort, an welcher Übergabe, und wen Sie dazu fragen sollten.
Persönliche Demo an einem Beispiel-Service-Desk. Ihre eigenen Daten erst, wenn Sie weitergehen wollen. Freischaltung meist am selben Tag.
Arbeitet mit Daten aus
Voraussetzung ist die Änderungshistorie für Rolle, Status und Kategorie. Eine Vorab-Abfrage prüft das, bevor Sie exportieren.
Dieselbe Auswertung am Schreibtisch und unterwegs: ein Beispiel-Service-Desk (fiktiv), echte Software, kein Mockup.
Was passiert, wenn Sie nach dem Problem fragen?
Mehr Antworten lösen nichts. Die richtige Antwort schon.
Typische Antworten im Jour fixe – DASS
Jede Antwort klingt plausibel. Keine ist überprüfbar.
Wenn die Frage spezifisch wird – WO & WEN FRAGEN
Keine Ausweichantwort möglich. Die Frage geht an beide Seiten der Übergabe. (Beispiel-Service-Desk, fiktiv)
Process Radar macht aus Ihren Ticket-Daten genau solche Fragen – so spezifisch, dass keine Ausweichantwort mehr trägt.
Die Zeit geht nicht in einem Team verloren,
sondern zwischen Menschen: an einem Standort, an einer Übergabe. Genau das wird gerade automatisiert.
Drei Sätze aus jedem Jour fixe
Ihr Service-Desk-Report ist grün. Warum beschweren sich trotzdem Standorte und Fachbereiche?
Process Radar zeigt, wo in Ihrem Service Desk Zeit liegen bleibt: bei welcher Rolle, an welchem Standort, an welcher Übergabe. Aus der Änderungshistorie, die Ihr ITSM mitschreibt.
1„Der Durchschnitt sagt: alles normal.“
Heute
Berichte zeigen Zeiten je Team. Wo es innerhalb eines Teams dauert, an einem Standort oder in einer Kategorie, verschwindet im Mittelwert.
Mit Process Radar
Dieselbe Arbeit derselben Rolle im Vergleich über alle Standorte und Kategorien, mehrfach validiert. Im Datensatz eines Kunden lagen 16 von 30 Standorten über dem Üblichen, der langsamste beim 3,4-Fachen des Üblichen.
Ihr Nutzen: Sie wissen, wo Sie hinschauen müssen, und können Beschwerden mit Daten beantworten.
2„Jedes Team ist gut. Trotzdem dauert es.“
Heute
Jede Gruppe meldet ihre eigene Zeit korrekt. Was zwischen zwei Gruppen passiert, taucht in keinem Teambericht auf.
Mit Process Radar
Je Rolle: woher die Tickets kommen, wie lange sie bleiben, wohin sie gehen. Dazu: wie viele Tickets zwischen zwei Rollen hin- und hergehen. Bei einem Kunden gingen in einem Jahr 9 % aller Tickets an eine frühere Gruppe zurück.
Ihr Nutzen: Übergabeprobleme werden sichtbar, und beide Teams arbeiten mit derselben Faktenbasis.
3„Zwanzig Verbesserungsideen, Kapazität für zwei.“
Heute
Schwer zu entscheiden, wo man anfängt und ob eine Maßnahme gewirkt hat.
Mit Process Radar
Die Startseite im Tool nennt drei Stellen, jede mit Adressat: größte Mehrzeit, stärkster Anstieg, längster Dauerbrenner. Delegation mit Frage und Frist, Antwort per Link ohne eigenes Konto. Nach der Maßnahme: neuer Lauf, derselbe Befund.
Ihr Nutzen: Eine kurze Liste mit Belegen statt Bauchgefühl.
Montag, 9:15 Uhr. Ihr Jour fixe.
Die SLA-Quote ist auf 74% gefallen. Der Rückstand wächst. Ihr Teamleiter sagt: “Wir brauchen mehr Leute.” Ihr Controlling fragt: “Was genau ist das Problem?”
Sie öffnen drei Reports. Keiner zeigt Ihnen, ob das ein Kapazitätsproblem ist, ein Routing-Fehler, oder ob Team A seine Tickets so schnell weiterleitet, dass Team B in der Arbeit ertrinkt.
Mit Process Radar: Sie öffnen das Briefing und sehen drei Stellen zum Anfangen. Die erste: “Dieselbe Rolle, Field Service & Anlagentechnik, üblich 4,5 Stunden, in Abfüllung Cottbus 30 Stunden bei 34 Vorgängen. Mehrfach validiert.” Sie schicken die Frage an Cottbus: Was ist bei euch anders? Mit Zahl und Frist. (Beispiel-Service-Desk, fiktiv)
Mit KI schneller werden. Aber wo eigentlich?
Erst verstehen. Dann automatisieren.
Automatisiert wird, was im System sichtbar ist. Die Zeit geht aber dazwischen verloren: an einem Standort, an einer Übergabe. Wer das nicht kennt, automatisiert den Umweg mit.
Beobachtet im Beispiel-Service-Desk (fiktiv): 128 Tickets gehen zwischen 1st Level Support und HR-Services hin und her, 73 % der Tickets dieses Paars. Ein KI-Router, der sie schneller an HR-Services schickt, beschleunigt das Pendeln. Erst klären, warum HR-Services sie zurückgibt.
Kein Dashboard. Kein Process Mining.
Keine Umfrage.
BI zeigt Durchschnitte je Team. Process Mining modelliert den ganzen Prozess, mit Projekt. Umfragen fragen nach Gefühl. Process Radar ist die schlanke Process-Mining-Alternative für ITSM: Es vergleicht Gleiches mit Gleichem, zeigt nur Unterschiede, die mehrfach validiert sind, und nennt zu jeder Stelle, wen Sie fragen sollten. Die Gründe klären Sie mit den Menschen dort.
BI-Dashboard
Zeigt Durchschnitte
Jede Zahl ist nachbaubar, wenn jemand weiß, wonach er sucht.
Process Mining
Braucht ein Projekt
3–12 Monate, Data-Science-Team, sechsstelliges Budget.
Process Radar
Zeigt die Stelle
Ort, Ausmaß, mehrfach validiert, und wen Sie fragen.
Process Radar erkennt
Muster aus Ihren ITSM-Ticket-Daten, die in Standard-Reports unsichtbar bleiben – quer über Teams, Kategorien und Standorte.
Ticket-Ping-Pong
Ticket Ping-PongTickets, die zwischen zwei oder drei Teams hin- und herwandern, ohne dass jemand übernimmt.
Falsche Erstzuweisung
Wrong Initial AssignmentTickets landen zuerst bei einem Team, das sie nicht löst – und werden weitergeleitet, bevor irgendetwas geschehen ist.
Kategorie-Routing-Fehler
Category Routing ErrorsEine Ticket-Kategorie landet systematisch bei der falschen Rolle – sichtbar durch erhöhte Bearbeitungsdauer pro Kategorie/Rolle-Paar.
Engpass-Teams
Bottleneck TeamsEine Rolle verarbeitet im Schnitt deutlich langsamer als vergleichbare Rollen – der Stau wird sichtbar an der Übergabe-Statistik.
Kapazitätsasymmetrien
Capacity AsymmetriesTeam A leitet schneller weiter, als Team B aufnehmen kann – Rückstau entsteht, wo niemand ihn verursacht hat.
Kaskadeneffekte
Cascade EffectsEin Stau bei einer Rolle pflanzt sich zeitversetzt durch nachgelagerte Teams fort – sichtbar nur in der Pfad-Analyse.
Wartezeitanteile
Wait Time ShareAnteil der Durchlaufzeit, in der ein Ticket auf etwas wartet statt bearbeitet zu werden – getrennt nach geplanter Wartezeit und Park-Verhalten.
Park-Verhalten (Hold)
Hold/Park BehaviorTickets werden auf 'Warten' gesetzt und bleiben dort – Process Radar trennt geplante Wartezeit von Selbstschutz-Parken.
Bevorzugte Ticket-Auswahl (Cherry-Picking)
Cherry-Picking by CategoryEine Rolle bearbeitet bestimmte Kategorien schnell und meidet andere – der Bias wird im Kategorie-Vergleich sichtbar.
Weiterleitung statt Lösung
Handover instead of ResolutionEine Rolle leitet überproportional viele Tickets weiter, statt sie zu lösen – Hinweis auf Quatschaufgaben oder Verantwortungslücken.
Vom Export zur ersten Stelle
Kein Workshop. Kein Prozessmodell. Aber ein Datencheck vorab.
Daten prüfen und liefern
Eine Vorab-Abfrage prüft, ob die Änderungshistorie für Rolle, Status und Kategorie vorliegt. Dann Export per Matrix42-SQL-Vorlage oder CSV.
Zuordnen und vergleichen
Gemeinsam ordnen wir Status und Wartegruppen zu. Dann vergleicht Process Radar dieselbe Arbeit derselben Rolle über Standorte, Kategorien und Übergaben und behält, was mehrfach validiert ist.
Fragen, dann ändern
Sie sehen wenige Stellen, jede mit Ort, Ausmaß und Ansprechpartner. Sie schicken die Frage mit Frist. Erst danach entscheiden Sie, was Sie automatisieren.
10 Minuten / Woche
Jede Rolle bekommt, was sie braucht
Unterschiedliche Perspektiven auf dasselbe Problem – ohne unterschiedliche Tools.
IT-Leiter / Head of IT
Klarheit, Kontrolle, Delegation
- Wenige Stellen statt 150 Einzelbefunde
- Delegation mit einem Klick – Kontext inklusive
- Trend-Erkennung: wird es besser oder schlimmer?
- Mehrzeit in Stunden, je Stelle mit Zeitfenster
Teamleiter / Analyst
Kontext, strukturierte Aufgaben
- Delegation enthält Daten, nicht nur Anweisungen
- Strukturierte Rückmeldung ohne eigenes Konto
- Drill-Down in betroffene Ticket-Kategorien
- Keine eigene Datenauswertung nötig
Qualitätsmanager
Systematik, keine Einzelfälle
- Strukturelle Schwachstellen statt Einzeltickets
- Kaskadeneffekte zwischen Teams sichtbar
- Wiederholungsmuster über Zeiträume
- Kein Budget für Process-Mining nötig
Was andere Lösungen nicht können
Process Radar schließt die Lücke zwischen operativem ITSM-Reporting und strategischem Process Mining.
Typischer Ansatz
BI-Dashboards zeigen, dass Team B langsam ist.
Mit Process Radar
Process Radar zeigt: Dieselben Tickets brauchen je nach Herkunft 3,4 oder 28 Stunden (Beispiel-Service-Desk, fiktiv). Die Frage gehört an die Übergabe davor, nicht nur an Team B.
Typischer Ansatz
Klassisches Reporting zeigt die Vergangenheit.
Mit Process Radar
Process Radar erkennt Trends und zeigt, ob eine Situation sich verschlechtert – bevor sie eskaliert.
Typischer Ansatz
Process Mining braucht Monate und Spezialisten.
Mit Process Radar
Process Radar zeigt die Stellen aus vorhandenen Ticket-Daten. Keine Modellierung, kein Projekt, keine Data Scientists.
Typischer Ansatz
Jedes Tool produziert mehr Daten. Niemand hat weniger Fragen.
Mit Process Radar
Process Radar verdichtet 150+ Befunde zu wenigen Situationen und nennt drei Stellen zum Anfangen, jede mit Beleg.
Häufige Fragen
Warum ist der SLA-Report grün, obwohl Nutzer sich beschweren?
Weil der Report einen Mittelwert je Team zeigt, und der verdeckt Standorte wie diesen: Bei einem Kunden dauerte dieselbe Arbeit an einem Standort 3,4-mal so lange wie üblich. Process Radar vergleicht dieselbe Arbeit derselben Rolle über alle Standorte und Kategorien und behält nur Unterschiede, die mehrfach validiert sind. SLA-Felder liest Process Radar nicht: Es zeigt, wo die Zeit hängt, nicht die SLA-Quote.
Wie finde ich Ticket-Ping-Pong zwischen Support-Gruppen?
Aus der Änderungshistorie Ihres ITSM: Bei einem Kunden gingen so gezählt in einem Jahr 9 % aller Tickets an eine frühere Gruppe zurück. Jeder Wechsel der zuständigen Gruppe steht dort mit Zeitstempel, und ein Ticket, das von Gruppe A zu B und wieder zu A wandert, ist eine Rückgabe. Process Radar zählt diese Rückgaben je Gruppenpaar und zeigt, in welcher Kombination aus Standort und Kategorie sie sich häufen. Gezählt wird in Tickets, nicht in geschätzten Stunden.
Welche Tickets tragen die meiste Bearbeitungszeit?
Meist wenige lange Fälle: Bei einem Kunden trugen 10 % der Bearbeitungsschritte einer Service-Desk-Rolle 61 % ihrer Arbeitszeit. Process Radar nennt dieses längste Zehntel und die Merkmale, die dort gehäuft vorkommen, etwa bestimmte Standorte. Dazu zeigt es alte offene Tickets, die seit mindestens 30 Tagen niemand geändert hat.
Welche Daten braucht man aus Matrix42?
Tickets und die Änderungshistorie für zuständige Rolle, Status und Kategorie, wahlweise für 3 bis 24 Monate. Wichtig: In Matrix42 ist die Historie je Attribut standardmäßig abgeschaltet (DisableHistory). Ist sie für die Rolle aus, fehlen die Übergaben, und rückwirkend lässt sich das nicht nachholen. Process Radar liefert eine SQL-Vorlage und eine Vorab-Abfrage, die den Schalter je Attribut anzeigt.
Ist das Mitarbeiter-Überwachung?
Nein. Kleinste Einheit ist die Rolle, nie die Person. Process Radar zeigt, an welchem Ort Zeit liegen bleibt. Die Gründe klären Sie mit den Menschen dort.
Was brauche ich, um zu starten?
Tickets und die Änderungshistorie für Rolle, Status und Kategorie. Für Matrix42 gibt es eine SQL-Vorlage mit Vorab-Abfrage, sonst einen CSV-Export der Tabellen Tickets und Ticket-History. Konnektoren für Matrix42, Jira Service Management und ServiceNow sind gebaut und gegen Testsysteme geprüft; der Einsatz beim Kunden wird vorab abgestimmt. Keine Installation.
Wann sehe ich die ersten Stellen?
Nach dem Datencheck und der Zuordnung von Status und Wartegruppen. Danach liest sich das Briefing in etwa 10 Minuten pro Woche.
Ersetzt das unser ITSM-Tool?
Nein. Process Radar ist eine Analyseschicht über Ihrem bestehenden System. Es arbeitet mit Tickets und Änderungshistorie aus Ihrem ITSM. Keine Datenmodell-Änderungen, keine Prozessanpassungen.
Sicherheit und Datenschutz
DSGVO-konform
Alle Daten werden in der EU verarbeitet und gespeichert. Keine Weitergabe an Dritte.
Sie bestimmen den Datenfluss
Ob SQL-Vorlage, CSV-Export oder API: Sie entscheiden, welche Daten Process Radar sieht. Kein Vollzugriff auf Ihr ITSM-System, nur die Ticket-Daten, die Sie freigeben.
Verschlüsselt
Alle Verbindungen TLS-verschlüsselt. Connector-Daten AES-256. Mandantentrennung auf Datenbankebene.
Demo
Sehen Sie an einem Beispiel-Service-Desk, wie eine Stelle aussieht.
Fordern Sie Ihren persönlichen Demo-Zugang an. Sie sehen die Stellen, die Delegation und die Frage an die Menschen dort. Freischaltung meist am selben Tag.
Demo anfordernKostenlos. Keine Verpflichtung. Freischaltung meist am selben Tag.
Erst verstehen. Dann automatisieren.
Wir zeigen Ihnen an einem Beispiel-Service-Desk, wie so eine Stelle aussieht: der Ort, die Zahl und die Frage an die Menschen dort. Ihre eigenen Daten kommen danach, wenn Sie weitergehen wollen.
Demo anfordernPersönliche Demo · Freischaltung am selben Tag · Kostenlos und unverbindlich