Manuelle Workaround-Mustererkennung

Das echte Ausmaß des Problems

Jedes Unternehmen ab einer gewissen Größe hat sie: informelle Prozesse, die neben dem offiziellen System laufen. Manchmal fangen sie als pragmatische Lösung für eine Systemlücke an — eine Excel-Liste für Sonderfälle, ein WhatsApp-Kanal für schnelle Freigaben, ein E-Mail-Roundtrip, weil das Ticketsystem den konkreten Anwendungsfall nicht abdeckt. Über Monate werden sie zur Gewohnheit. Über Jahre werden sie unsichtbar.

Laut einer Erhebung von Beezy (2022) sind 58 Prozent der Mitarbeitenden mit den offiziell bereitgestellten Tools unzufrieden. Eine Statista-Untersuchung (2020) zeigt: 42 Prozent nutzen regelmäßig private E-Mail-Konten für arbeitsbezogene Kommunikation, 38 Prozent verwenden nicht freigegebene Messaging-Plattformen. Das ist kein Regelverstoß aus Trotz — es ist ein Symptom dafür, dass die formalen Systeme die tatsächliche Arbeit nicht vollständig abbilden.

Gartner schätzt, dass Shadow-IT (also alle IT-Nutzung außerhalb des offiziell genehmigten Rahmens) in großen Unternehmen 30 bis 40 Prozent des IT-Budgets ausmacht. Aber das eigentliche Problem ist nicht der Budgetanteil — es ist die Prozessschuld.

Workarounds haben drei kritische Eigenschaften:

• Sie sind für die Führungsebene unsichtbar. Im ERP sieht ein Prozess korrekt aus. Die Parallelstruktur daneben taucht in keinem Report auf.
• Sie wachsen still. Wenn ein Team einen Workaround entwickelt, lernen neue Mitarbeitende ihn in der Einarbeitung — als “so machen wir das”. Das Wissen, dass es einen offiziellen Weg gäbe, geht verloren.
• Sie haben Systemcharakter. Eine Studie aus dem Jahr 2023, veröffentlicht in “Computers in Industry” von einem Forscherteam rund um Rebuge und Ferreira, zeigt: In mittelständischen Unternehmen entstehen Workarounds fast immer dort, wo das offizielle System entweder zu langsam, zu starr oder für den konkreten Anwendungsfall schlicht falsch konfiguriert ist. Das System erzeugt den Workaround — nicht die Person.

Mit vs. ohne KI — ein ehrlicher Vergleich

Die klassische Alternative ist der manuelle Prozessaudit: Workshops, Interviews, Prozesslandkarten. Das kostet bei einem mittelgroßen Unternehmen leicht vier bis sechs Wochen Beraterzeit. Das Ergebnis spiegelt, was Mitarbeitende bereit sind zu erzählen — nicht unbedingt, was wirklich passiert. Process Mining hingegen fragt nicht, es liest.

Einschätzung auf einen Blick

Zeitersparnis — mittel (3/5) Process Mining spart nicht tägliche Routinearbeit — es spart die Zeit, die man bislang damit verbracht hat, das Warum eines Prozessproblems durch Interviews und Bauchgefühl zu ermitteln. Eine Prozessanalyse, die früher Wochen dauerte, dauert mit Log-Daten Tage. Der laufende Zeiteinsatz ist moderat: Wer das System quartalsweise betreibt, braucht einige Tage für Auswertung und Handlungsableitung. Unter den verglichenen Anwendungsfällen liegt das im Mittelfeld.

Kosteneinsparung — niedrig (2/5) Die Einsparung entsteht nicht durch das Erkennen der Workarounds — sondern durch das anschließende Beheben der zugrunde liegenden Systemlücken. Das ist ein zweiter Schritt mit eigenem Budget und eigenem Projektrisiko. Direkte Kostensenkung durch das Erkennungssystem selbst ist kaum isolierbar — anders als bei der Rechnungsverarbeitung, wo man Verarbeitungskosten pro Rechnung direkt messen kann. Entsprechend niedrig die Einschätzung im Branchenvergleich.

Schnelle Umsetzung — niedrig (2/5) Wer keinen strukturierten Event Log aus dem ERP hat, fängt mit Datenaufbereitung an — das dauert. Selbst mit sauberem Log braucht ein Pilot realistisch acht bis vierzehn Wochen: Log-Extraktion, Datenbereinigung, Tool-Konfiguration, erste Auswertungsrunde, Interpretation mit Fachbereichen. Die Grundvoraussetzung — ein digitalisierter Prozess mit Zeitstempeln — ist nicht bei jedem Unternehmen erfüllt. Das macht den Einstieg schwerer als bei Meeting-Protokollen oder ähnlichen Tools, die sofort starten.

ROI-Sicherheit — niedrig (2/5) Der Befund ist klar und quantifizierbar: Du weißt, wie viele Fälle den Workaround durchlaufen und wie viel Zeit dabei verloren geht. Was du nicht sicher weißt: Wie viel davon ist tatsächlich einzusparen, wenn du das System korrigierst? Prozessänderungen erzeugen oft neue Reibung. Der Kausalzusammenhang zwischen “Workaround gefunden” und “Euro gespart” ist schwer herzustellen — weswegen dieser Anwendungsfall trotz klarer Befunde eine niedrige ROI-Sicherheit hat.

Skalierbarkeit — hoch (4/5) Das ist die Stärke des Ansatzes: Wenn der Pilot mit einem Kernprozess (z.B. Bestellung) läuft, kostet das Hinzufügen von Reklamationen, Onboarding oder Budgetfreigaben nur den Aufwand für den Log-Export — nicht das gesamte Projekt noch einmal. Die Process-Mining-Infrastruktur amortisiert sich über die Zahl der analysierten Prozesse.

Richtwerte — stark abhängig davon, ob dein ERP strukturierte Event Logs produziert und ob ein IT-Ansprechpartner für den Log-Export verfügbar ist.

Was Process Mining konkret macht

Process Mining ist keine KI im Sinne eines lernenden Modells — es ist Machine Learning angewandt auf Prozessdaten. Das Grundprinzip ist denkbar einfach:

Jedes digitale System, das Vorgänge verwaltet — ein ERP wie SAP, ein Ticketsystem wie Jira, ein CRM wie Salesforce — schreibt mit, was wann von wem getan wurde. Diese Aufzeichnung heißt Event Log: eine Tabelle mit Fallnummer (z.B. Bestellnummer), Aktivität (Schritt im Prozess) und Zeitstempel. Manchmal noch mit Ressource (wer hat den Schritt ausgeführt) und Attributen (Betrag, Kategorie, Priorität).

Process Mining liest diesen Event Log und baut daraus automatisch ein Prozessmodell — nicht das Modell, das im Handbuch steht, sondern das Modell, das tatsächlich gelebt wird. Was das System dabei sichtbar macht:

Varianten. In einem Bestellprozess mit 5.000 Fällen gibt es vielleicht 3 offizielle Varianten — aber das System findet 47 tatsächliche Abläufe. Die Varianten, die häufig vorkommen und viel Zeit kosten, sind die Kandidaten für Workarounds.

Schleifen. Ein Vorgang, der zwischen zwei Schritten pendelt, ist ein Alarmsignal: entweder Fehlerkorrektur, oder ein inoffizieller Genehmigungsschritt, der im offiziellen Prozess nicht existiert, aber konsistent ausgeführt wird.

Ressource-Anomalien. Wenn ein bestimmter Mitarbeitender immer dann auftaucht, wenn ein Vorgang aus dem offiziellen Flow herausfällt, deutet das auf eine informelle “Notlösung-Funktion” hin — die Person, die alle Sonderfälle löst, weil das System sie nicht abfangen kann.

Zeitliche Muster. Verzögerungen, die regelmäßig zwischen bestimmten Schritten auftreten, können auf externe Prozesse hinweisen — z.B. eine E-Mail-Kommunikation, die das System nicht kennt, aber die vor dem nächsten Schritt immer stattfindet.

Was das System nicht sieht: Prozesse, die ausschließlich außerhalb des Systems stattfinden — reine WhatsApp-Kommunikation, telefonische Absprachen, Papier-Formulare. Es sieht nur den digitalen Schatten eines Prozesses, nicht den Prozess selbst.

Was dein System-Event-Log können muss

Dies ist der kritische Punkt, der diesen Anwendungsfall von einfacheren KI-Projekten unterscheidet: Ohne einen strukturierten Event Log gibt es nichts zu analysieren.

Ein Event Log existiert automatisch in jedem System, das Transaktionen verwaltet — aber nicht jedes System macht ihn zugänglich. Was du brauchst:

Minimum-Anforderungen an den Event Log:

• Eindeutige Fall-ID für jeden Vorgang (Bestellnummer, Ticketnummer, Vertragsnummer)
• Aktivitätsname oder Status-Übergang (z.B. “Freigabe erteilt”, “Rechnung gebucht”)
• Zeitstempel für jeden Schritt

Typische Quellen, die diese Daten liefern:

• SAP (Tabellen CDHDR/CDPOS für Änderungshistorie, VBAK/VBAP für Aufträge)
• Jira (Export als CSV mit Issue-History)
• Salesforce (Object History Reports)
• Servicenow, Freshdesk, Zendesk (Ticket-Activity-Logs)
• Microsoft Dynamics (Audit-Log)
• Eigene Datenbanken mit Zeitstempel-Feldern

Was häufig fehlt und Aufwand erzeugt:

• Systeme ohne Zeitstempel auf Statüsübergängen (nur “Erstellt am” und “Geschlossen am”, ohne Zwischenschritte)
• ERP-Daten, die auf mehrere Tabellen verteilt sind und manuell zusammengeführt werden müssen
• Prozesse, die über mehrere Systeme laufen und keinen systemübergreifenden Fall-Identifier haben

Bevor du ein Process-Mining-Projekt startest, lohnt eine ehrliche Vorfrage: Kannst du aus deinem Hauptsystem eine CSV-Tabelle exportieren, die mindestens Fall-ID, Aktivität und Zeitstempel enthält? Wenn nein — klär zuerst, ob das System eine Audit-Funktion hat, die eingeschaltet werden kann. Wenn auch das nicht möglich ist, ist Process Mining für diesen Prozess (noch) nicht der richtige Ansatz.

Konkrete Werkzeuge — was wann passt

Der Markt für Process Mining teilt sich grob in drei Kategorien: Einstiegs-Tools für explorative Analysen, Midmarket-Plattformen mit EU-Hosting und Selbsthosting-Option sowie Enterprise-Plattformen mit nativer ERP-Anbindung.

Fluxicon Disco — für den ersten Versuch Disco ist das Werkzeug, das Prozessanalysten weltweit für schnelle explorative Analysen einsetzen. Kein ERP-Konnektor nötig — du lädst eine CSV-Datei hoch und bekommst in Sekunden ein Prozessmodell. Für einen ersten Workaround-Scan eines einzelnen Prozesses ist das der schnellste Weg. Preis: auf Anfrage (Perpetual-Lizenz), kostenlose akademische Lizenz verfügbar. Einschränkung: kein Echtzeit-Monitoring, kein Cloud-Collaboration-Feature.

Apromore — für datenschutzsensible Unternehmen Die Community Edition von Apromore ist Open Source und selbst hostbar — DSGVO-konform in der eigenen Infrastruktur. Für Unternehmen mit sensiblen Prozessdaten (Personalentscheidungen, Finanzdaten) ist das ein klarer Vorteil gegenüber Cloud-Diensten. Die Benutzeroberfläche ist weniger poliert als Celonis, aber methodisch vollständig. Enterprise-Cloud ab ca. 1.250 $/Monat.

Celonis — ab ca. 50–100 Personen mit SAP Celonis ist der Marktführer im Process Mining — mit vordefinierten Konnektoren für SAP, Oracle und Salesforce, KI-gestützter Root-Cause-Analyse und direkter Integration von Prozessverbesserungsempfehlungen in operative Systeme. Für den Mittelstand mit SAP-Umgebung ist Celonis das leistungsfähigste Tool. Realistische Kosten für ein erstes Analyseprojekt: 50.000–100.000 Euro. Eine dokumentierte SME-Evaluation kam auf ca. 80.000 Euro jährlich für Lizenz und dedizierten Analysten. Das ist kein Einsteiger-Budget.

Wann welcher Ansatz:

• Erster Pilot, kleines Budget, ein Prozess → Fluxicon Disco
• Datenschutz im Vordergrund, IT-Infrastruktur vorhanden → Apromore Community Edition
• SAP-Umgebung, dediziertes Analysebudget, mehrere Prozesse gleichzeitig → Celonis

Datenschutz und Datenhaltung

Event Logs aus ERP- oder HR-Systemen können personenbezogene Daten enthalten — auch wenn das auf den ersten Blick nicht offensichtlich ist. Eine Tabelle mit “Mitarbeiterin K. hat Vorgang 47382 am 14:23 Uhr freigegeben” ist personenbezogen im Sinne der DSGVO. Sobald du diesen Log in ein Cloud-Tool lädst, bist du in der Auftragsverarbeitung und brauchst einen AVV.

Apromore Community Edition (selbst gehostet): kein externer Datentransfer, volle Kontrolle. Ist für datenschutzsensible Analysen die sicherste Option.

Celonis: EU-Datenhaltung konfigurierbar. Celonis SE hat seinen Hauptsitz in München — der EU-AVV ist standardisiert und über das Kundenportal zugänglich. Trotzdem: IT-Sicherheitsbeauftragte und Betriebsrat einbeziehen, bevor Mitarbeitende-Aktivitätsdaten exportiert werden.

Fluxicon Disco: Desktop-Tool, das lokal läuft. Daten verlassen das Gerät nicht, solange keine Cloud-Sync-Funktion aktiviert wird. Für Erstanalysen technisch die sauberste DSGVO-Option.

Wichtig für alle Varianten: Bevor du Event Logs analysierst, prüfe mit dem Datenschutzbeauftragten, ob die Analyse von Mitarbeitenden-Aktivitäten auf Einzelfallebene einer gesonderten Betriebsvereinbarung bedarf. In vielen Unternehmen ist Process Mining mit Ressourcen-Analyse mitbestimmungspflichtig nach § 87 BetrVG — nicht weil die KI “überwacht”, sondern weil aus den Daten Rückschlüsse auf individuelle Arbeitsleistung möglich sind.

Was es kostet — realistisch gerechnet

Einmalige Aufwände

• IT-seitiger Log-Export aus ERP/CRM: typisch 3–8 Tage, wenn ein SAP-Basis-Admin verfügbar ist. Bei Nicht-SAP-Systemen oft kürzer — Export als CSV direkt aus dem System.
• Datenbereinigung und Log-Aufbereitung: 2–5 Tage je nach Datenqualität
• Tool-Einrichtung und erste Analyse: 3–5 Tage
• Interpretation mit Fachbereichen (Workshops): 2–3 Tage

Summe Erstaufwand: intern 10–20 Tage. Extern (Berater für Erstprojekt): 15.000–40.000 Euro, je nach Prozessanzahl und Tool.

Laufende Kosten (nach Pilotphase)

• Fluxicon Disco: auf Anfrage (Perpetual-Lizenz, einmalig)
• Apromore Community Edition: kostenlos, Betriebsaufwand für Selbsthosting
• Celonis: ca. 80.000 Euro/Jahr (dokumentierte SME-Evaluation) bis Enterprise-Tarife; nicht für kleine Mittelständler geeignet

Was du dagegenrechnen kannst Wenn dein Pilot einen Kernprozess mit 5.000 Jahresfällen analysiert und dabei herausfindet, dass 25 Prozent der Fälle eine unnotwendige Schleife laufen, die im Schnitt zwei Stunden kostet — dann reden wir von 2.500 Stunden Jahresverschwendung. Bei einem internen Stundensatz von 35 Euro sind das 87.500 Euro. Das ist die potenzielle Einsparung, wenn der Prozess korrigiert wird. Der Pilot selbst kostet einen Bruchteil davon.

Das “wenn” ist wichtig: Die Einsparung tritt nicht durch das Erkennen ein, sondern durch das Beheben. Plane das als zweites Projekt — nicht als Ergebnis dieses einen.

Drei typische Einstiegsfehler

1. Den Event Log als Blackbox behandeln. Viele Projekte scheitern daran, dass das IT-Team einen Log-Export produziert — und das Process-Mining-Tool damit losläuft, ohne dass jemand die Daten vorher verstanden hat. Das Ergebnis: Das Modell zeigt Varianten, die keine Workarounds sind, sondern Datenerfassungsfehler. Eine Bestellung, die dreimal “erstellt” wurde, weil das Formular dreimal abgeschickt wurde, sieht im Process Mining wie ein dreistufiger Prozess aus. Bevor du analysierst, braucht jemand mit Prozesswissen (nicht nur IT-Wissen) das Log-Schema — und muss es mit echten Vorgängen validieren.

2. Workarounds eliminieren wollen, ohne zu verstehen warum sie existieren. Process Mining zeigt das Was, nicht das Warum. Wenn 30 Prozent der Bestellungen eine nicht dokumentierte zweite Budgetprüfung laufen, ist die naheliegende Reaktion: “Das schaffen wir ab.” Aber vielleicht laufen genau die Bestellungen durch diese Schleife, bei denen der Einkauf eine Plausibilitätsprüfung braucht, die das System nicht vorgesehen hat. Wer den Workaround ohne Rücksprache entfernt, erzeugt im besten Fall einen neuen — im schlechtesten Fall Fehlerkosten. Jeder gefundene Workaround braucht ein Interview: Warum machen wir das so?

3. Den Scope zu weit setzen. “Wir analysieren alle Kernprozesse auf einmal” ist der zuverlässigste Weg, ein Process-Mining-Projekt zu versenken. Jeder Prozess braucht einen eigenen Log-Export, eigene Datenbereinigung, eigene Workshop-Runden. Wer mit drei Prozessen gleichzeitig beginnt, hat nach vier Monaten drei halbfertige Analysen und kein einziges klares Ergebnis. Starte mit einem Prozess, den du vollständig verstehst und dessen Datenquelle du kennst. Lass das Ergebnis für sich sprechen — dann ist die Skalierung auf weitere Prozesse deutlich leichter zu begründen. Begleitfehler: System einrichten, Berichte produzieren — aber niemand zieht Konsequenzen. Leg vor dem Start fest: Wer ist für die Befund-Runde verantwortlich? Wie oft? Was passiert danach?

Was mit der Einführung wirklich passiert — und was nicht

Die technische Arbeit — Log-Export, Tool-Einrichtung, erste Analyse — ist in der Regel der einfachere Teil. Die Reibung entsteht woanders.

Die Prozessinhaber reagieren defensiv. Wenn ein Process-Mining-Befund zeigt, dass der Bestellprozess in Abteilung B systematisch einen nicht dokumentierten Umweg nimmt, hört sich das für den Abteilungsleiter oft wie Kritik an. “Mein Team macht das falsch” — auch wenn das gar nicht die Intention war. Das ist kein Problem der Methode, sondern der Kommunikation. Framing hilft: Process Mining zeigt nicht, ob jemand falsch arbeitet — es zeigt, ob ein System falsch konfiguriert ist. Der Workaround ist das Symptom, nicht die Ursache.

IT und Fachbereich reden aneinander vorbei. Der Event Log enthält Felder, die ein IT-Admin sofort versteht, aber ein Prozessverantwortlicher nicht einordnen kann. Die Auswertung braucht jemanden, der beides kann — oder zumindest beide Seiten als Tandem. In der Praxis fehlt diese Brückenperson oft. Ohne sie werden Befunde falsch interpretiert oder gar nicht erst kommuniziert.

Die ersten Befunde erzeugen Erwartungsdruck. Wenn der Pilot zeigt, dass 25 Prozent der Fälle einen kostspieligen Workaround nutzen, kommt sofort die Frage: “Und wann ist das behoben?” Die Antwort — “Das hängt vom nächsten ERP-Anpassungsprojekt ab, das sechs Monate dauert” — frustriert alle Beteiligten. Kommuniziere von Anfang an: Process Mining ist Diagnose, nicht Therapie. Das Beheben ist ein separates Projekt.

Was hilft: Einen Lenkungskreis aus IT-Leitung, Prozessverantwortlichen und Datenschutzbeauftragtem vor dem ersten Log-Export aufsetzen. Nicht danach — vorher. Und einen klaren Rhythmus für Befund-Runden etablieren: Ein Quartal zwischen Analyse und Entscheidung ist realistisch. Wer halbjährlich analysiert, hat am Ende des Jahres zwei verwertbare Befundrunden.

Realistischer Zeitplan mit Risikohinweisen

Erfahrungsgemäß verdoppelt sich dieser Zeitplan, wenn der Log-Export nicht reibungslos klappt oder der Datenschutzprozess Eskalationsschleifen erfordert. Plane bei erstmaligem Einsatz mindestens 16 Wochen ein.

Häufige Einwände — und was dahintersteckt

“Wir wissen schon, wo unsere Prozessprobleme liegen.” Vielleicht. Aber die Erfahrung aus Prozessaudits zeigt: Was Führungskräfte über ihre Prozesse denken und was tatsächlich auf Einzelfall-Ebene passiert, weicht in fast jedem Unternehmen erheblich voneinander ab. “Wir haben eine Schleife im Freigabeprozess — die kennen wir” und “27% aller Vorgänge laufen genau diese Schleife mit im Schnitt 1,8 Tagen Verzögerung” sind zwei sehr unterschiedliche Wissensebenen. Die erste reicht für Bauchgefühl-Entscheidungen. Die zweite für Budgetanträge und Projektpriorisierung.

“Unsere Mitarbeitenden werden sich überwacht fühlen.” Das ist ein legitimer Einwand — und er sollte ernst genommen, nicht wegdiskutiert werden. Die Antwort ist Transparenz: Was wird analysiert (Prozessschritte auf Fallnummer-Ebene), was nicht (individuelle Leistungsbewertung, Zeiterfassung). Wenn der Betriebsrat von Anfang an eingebunden ist und die Analyse-Rahmenbedingungen mitdefiniert — z.B. keine Darstellung auf Einzelpersonen-Ebene in der Berichtsrunde — löst sich der meiste Widerstand auf. Was nicht hilft: die Analyse heimlich starten und nachträglich erklären.

“Das ist zu teuer für das, was wir bekommen.” Bei Celonis: berechtigter Einwand für Unternehmen unter 50 Mitarbeitenden oder ohne SAP-Umgebung. Bei Fluxicon Disco oder Apromore Community Edition: weniger. Wenn du einen IT-Mitarbeitenden hast, der einen CSV-Export aus dem ERP machen kann, ist der Werkzeugkostenanteil für den Piloten überschaubar. Der teurere Teil ist die interne Zeit für Interpretation und Workshops — und die musst du sowieso investieren, wenn du den Prozess verstehen willst, egal mit welchem Werkzeug.

Woran du merkst, dass das zu dir passt

• Du vermutest, dass ein oder mehrere Kernprozesse in der Praxis anders laufen als dokumentiert — aber du kannst es nicht belegen
• Die Durchlaufzeit für einen Standardvorgang schwankt erheblich ohne offensichtlichen Grund (manchmal zwei Tage, manchmal acht)
• Neue Mitarbeitende lernen “wie man es wirklich macht” informell — nicht aus dem Handbuch, sondern von erfahrenen Kolleginnen und Kollegen
• Es gibt Sonderfälle, die immer zu derselben Person eskaliert werden, weil das System sie nicht regulär abhandeln kann
• Du willst ein neues ERP einführen oder ein bestehendes updaten — und willst wissen, welche Workarounds im Ist-Prozess stecken, bevor du das Soll-Modell definierst (hier lohnt Process Mining besonders)

Drei harte Ausschlusskriterien:

1. Unter ca. 15–20 Mitarbeitenden oder weniger als 500 Jahresfälle im zu analysierenden Prozess. Der Event Log ist zu dünn, um statistisch belastbare Muster zu erkennen. Bei kleinen Teams reicht ein Gespräch mit den Beteiligten — da braucht es kein Software-Projekt.

2. Der Prozess findet primär analog oder in nicht protokollierten Kanälen statt. Wenn die wesentlichen Entscheidungsschritte in Telefongesprächen, physischen Meetings oder WhatsApp-Gruppen ohne Systemanbindung stattfinden, gibt es keinen Event Log — und damit auch nichts zu analysieren. Process Mining arbeitet mit digitalen Spuren, nicht mit dem, was tatsächlich gesprochen wurde.

3. Kein IT-Mitarbeitender oder Administrator für den Log-Export verfügbar. Ein strukturierter Event Log aus SAP, Dynamics oder Salesforce zu extrahieren erfordert jemanden, der die Datenbankstruktur des Systems kennt. Wer darauf keinen Zugriff hat und kein Budget für externe Unterstützung, wird an diesem Schritt hängen — oft unbegrenzt. Das Projekt braucht einen IT-seitigen Ansprechpartner als festen Bestandteil des Teams.

Das kannst du heute noch tun

Der einfachste erste Schritt kostet nichts außer 30 Minuten IT-Zeit: Frag deinen SAP-, Jira- oder Dynamics-Administrator, ob er einen Export der letzten 1.000 Fälle eines Kernprozesses als CSV liefern kann — mit Fallnummer, Status/Aktivität und Zeitstempel. Wenn ja, lade die Datei in Fluxicon Disco (30-Tage-Trial) und schau dir an, wie viele verschiedene Ablaufvarianten tatsächlich existieren. Die Zahl überrascht fast immer.

Wenn du noch einen Schritt früher ansetzen willst: Nutze folgende Frage als Quick-Check mit deinem Team.

Quellen & Methodik

• Workaround-Analyse in KMU mit Process Mining: Rebuge und Ferreira (2023), “Using process mining for workarounds analysis in context: Learning from a small and medium-sized company case”, veröffentlicht in Computers in Industry, ScienceDirect. Kernbefund: SMEs fehlt oft ein dokumentiertes de-jure-Prozessmodell als Referenzpunkt — ohne dieses lassen sich Abweichungen im Event Log nicht als “Workaround” klassifizieren.

• Workarounds und Shadow IT: White, Martin S. (2023), “Workarounds and shadow IT — balancing innovation and risk”, Journal of Information Science / Information Research, Sage Journals. Kernbefund: Mitarbeitende setzen Workarounds bewusst und zielgerichtet ein, um Systemlücken zu kompensieren — das ist kein Disziplinproblem, sondern ein Systemdesignproblem.

• Shadow IT Nutzungsraten: Statista (2020): 42% der Mitarbeitenden nutzen private E-Mail-Konten für Arbeitskommunikation. Beezy (2022): 58% nicht zufrieden mit offiziell bereitgestellten Tools.

• Datenqualität als Hauptproblem: Carmona et al. (2022), “A Practitioner’s View on Process Mining Adoption, Event Log Engineering and Data Challenges”, Springer Nature (Lecture Notes in Computer Science). 78% der befragten Praktiker berichten von Datenproblemen als Haupthindernis; 69% nennen die Abgrenzung von Prozessinstanzen als besondere Schwierigkeit.

• Celonis-Kostenschätzung: Dokumentierter Evaluationsfall aus Nutzerbericht (Process Radar Blog, 2024): ca. 80.000 Euro/Jahr für Lizenz plus dedizierten Analysten; SAP Signavio ab ca. 50.000 Euro/Jahr für mittlere Installationen laut mehreren Consulting-Berichten (Stand April 2026).

• Gartner-Warnung: Gartner, Forecast Analysis: Process Mining, Worldwide (2023): “Through 2026, insufficient business process management maturity will prevent 90% of organizations from reaching desired business outcomes from end-to-end process mining initiatives.”

• § 87 BetrVG Mitbestimmung: Betriebsverfassungsgesetz, gültige Fassung — Mitbestimmungspflicht bei technischen Einrichtungen, die Mitarbeitende-Verhalten überwachen können.

Du fragst dich, ob dein ERP die nötigen Log-Daten liefert — und welcher Pilot in eurem Betrieb realistisch wäre? Meld dich — das klären wir gemeinsam, ohne dass du sofort ein Projekt starten musst.