Vorbereitung von Quelldaten & häufige Herausforderungen

Übersicht

Saubere Quelldaten sind der mit Abstand beste Indikator für ein reibungsloses Process-Mining-Projekt. Wenn Zeitstempel unklar, Fallkennungen (Case Identifiers) nicht vorhanden oder Aktivitätsnamen inkonsistent sind, muss die Mining-Engine die tatsächliche Reihenfolge oder Kausallogik der Ereignisse erraten – oft mit spektakulär falschen Ergebnissen. Die folgenden Richtlinien bündeln Felderfahrung und Forschung, damit du deine Prozessdaten entwerfen oder reparieren kannst, bevor sie in das Noreja-Tool gelangen.

Zeitstempelformate

Warum ISO 8601 (und eine echte DATETIME-Spalte) entscheidend ist

ISO 8601 (YYYY-MM-DDThh:mm:ss[.fff]Z) ist lexikografisch sortierbar, zeitzonenbewusst und kulturunabhängig eindeutig. Die Speicherung in einem richtigen DATETIME/TIMESTAMP -Datentyp – und nicht als VARCHAR – hält Indizes klein, erlaubt Bereichsabfragen und verhindert stille Konvertierungsfehler von Zeichenketten zu Datumswerten.

Typische nicht-ISO-Fälle in relationalen Datenbanken

• Getrennte Spalten für Datum und Uhrzeit (OrderDate, OrderTime), die eigentlich zusammengeführt werden müssten.
• Lokalisierte Texte (z. B. 04/05/25 14:00 – US vs. EU-Interpretation).
• 12-Stunden-Format mit AM/PM (z. B. 7-Jan-25 3:45 PM), das sich als String falsch sortieren lässt.
• Unix-/Epoch-Zeitwerte (z. B. 1730870400), die umgewandelt und mit Zeitzonen versetzt werden müssen.
• Excel-Seriennummern (z. B. 45234.5833) aus CSV-Exporten.
• Komprimierte numerische Zeitstempel (z. B. 20250706) – gut lesbar, schwer zu differenzieren.
• Texte mit Monatsnamen (z. B. 10-APR-25 23.12.17:54), die einfache Parser aushebeln.
• Fehlende Zeitzonenangaben (nur lokale Serverzeit vorhanden).
• Gekappte Präzision (z. B. fehlende Millisekunden).
• NULL-Platzhalter, die künstliche „Lücken“ erzeugen und KPIs zur Durchsatzzeit verfälschen.

Best Practice → Normalisiere alle Zeitstempel auf UTC und behalte den ursprünglichen Rohwert in einer Shadow Column für Prüfzwecke.

Technische vs. fachliche Zeitstempel

Zwei Uhren, zwei Ziele

Technische Zeitstempel werden vom System mit Mikro- oder Millisekundenpräzision geschrieben (z. B. beim Eintreffen einer Nachricht). Fachliche Zeitstempel sind gröber, meist tagesgenau, und spiegeln menschliche Aktionen oder Tagesabschlüsse wider. Wenn letztere auf „volle Tage“ gerundet werden, während erstere in Millisekunden gemessen bleiben, erscheinen gleichzeitig erzeugte Ereignisse in falscher Reihenfolge.

Tücken der Fehlanpassung

• Gleiche gerundete Zeitwerte – Unterschiedliche Aktivitäten teilen sich denselben Zeitstempel (z. B. 2025-07-01 00:00:00), sobald Millisekunden entfallen, sodass das Mining-Tool keine korrekte Reihenfolge ableiten kann.
• Dauerverzerrung – Wartezeiten unter einer Sekunde verschwinden, Über-Nacht-Prozesse erscheinen plötzlich als 24 Stunden lang, wenn nur das Datum gespeichert ist.
• Systemübergreifendes Zusammenführen – Logs aus New York (UTC‑4) und Phoenix (UTC‑7), beide in lokaler Zeit aufgezeichnet, wirken um drei Stunden versetzt – obwohl sie synchron abliefen.

Abhilfe → Speichere immer die höchstmögliche Präzision in UTC und runde nur im Reporting – niemals im Data Warehouse.

Fehlende Primärschlüssel des Datenobjekts

Causal Process Mining benötigt einen stabilen Bezeichner für Datenobjekte, um einzelne Fälle (Instanzen) zu unterscheiden. Fehlt in der Quelltabelle ein Primärschlüssel oder existiert keine natürliche Geschäftsobjekt-ID, ist eine Korrektur erforderlich.

Reparaturstrategien

• Synthese: Hash-Kombination unveränderlicher Spalten (z. B. SHA2(CustomerID || OrderDate || Line#)).
• Sequenzfenster: Nutzung von ROW_NUMBER() OVER (...) je Geschäftsvorgang/Datum zur Erzeugung eines Surrogat-Schlüssels.
• Wahrscheinlichkeitsbasierte Verknüpfung: ML-basierte Zuordnung, wenn kein deterministischer Schlüssel vorhanden ist.

Qualität der Aktivitätenspalte

Ein Aktivitätsname sollte dem Mining-Tool sagen: „Was ist gerade passiert?“ Häufige Probleme:

Quick-Reference-Checkliste

• Speichere Zeitstempel im UTC-Format nach ISO 8601 mit voller Präzision und bewahre die Rohdaten mit auf.
• Trunkiere keine hochauflösenden Logs – runde nur in der Reporting-Schicht.
• Stelle sicher, dass ein eindeutiger Case Identifier (bzw. Objekt-ID) existiert – notfalls künstlich erzeugen.
• Halte Aktivitätsnamen lesbar, konsistent und fehlerfrei.

Führe vor jedem Daten-Import einen Qualitätscheck durch – erkenne und behebe Probleme frühzeitig.