--- title: "Vorbereitung von Quelldaten & häufige Herausforderungen" url: "https://docs.noreja.com/de/article/vorbereitung-von-quelldaten-haufige-herausforderungen" language: "de" last_updated: "2026-02-22T14:06:56.571Z" --- # Vorbereitung von Quelldaten & häufige Herausforderungen Die Qualität der Quelldaten ist der wichtigste Erfolgsfaktor für ein reibungsloses Process-Mining-Projekt. Unklare Zeitstempel, fehlende Case-IDs oder inkonsistente Aktivitätsbezeichnungen zwingen Mining-Algorithmen dazu, kausale Abläufe zu erraten – häufig mit fehlerhaften oder verzerrten Ergebnissen. Eine saubere Normalisierung, präzise Zeitstempel, stabile Objektidentifikatoren und klar definierte Aktivitäten sind daher keine technischen Details, sondern grundlegende Voraussetzungen für eine verlässliche kausale Prozessanalyse. Die folgenden Best Practices bündeln Forschungserkenntnisse und Praxiserfahrung, um Ihre Datenbasis optimal auf Noreja vorzubereiten. ## Ü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: | Fehlerart | Symptom | Auswirkung | | --- | --- | --- | | Tippfehler / Aliase | *Ship*, *Shipping*, *SHIPPED* | Erhöht massiv die Variantenanzahl | | NULL / leere Felder | „Unbenannte Aktivität“ | Bricht Konformitätsprüfungen | | Gemischte Granularität | *Invoice Posted* vs *Send Invoice Email* | Erzeugt Spaghetti-Modelle mit vielen Varianten | | Überladene Felder | *Status* enthält Lebenszyklus + Einheit | Erschwert Trennung und Analyse | ## 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.