CAFM: Testmigrationen und Datenvalidierung (Reconciliation)

Typische Testmigrationen folgen einem iterativen Ablauf und durchlaufen mehrere Testumgebungen. Zunächst wird im Entwicklungs- oder Staging-System mit Teildatensätzen (z. B. Stichproben aus Produktivdaten oder synthetische Daten) gearbeitet. Diese Testumgebungen sind meist isolierte Kopien des Zielsystems, in denen Transformationen und Mappings erprobt werden. Parallel dazu existiert eine Produktionsumgebung, die im Zuge der Migration nicht tangiert wird. Die Testläufe werden mehrmals wiederholt (ggf. in zunehmender Datenmenge), um die Wiederholbarkeit der ETL-Logik sicherzustellen. Dabei kommen Produktions-Subsets zum Einsatz: Realitätsnahe, aber nicht unbedingt vollständig reale Daten (abgesichertes oder gemischtes Szenario). Nach jedem Durchlauf werden die Ergebnisse abgeglichen – zum Beispiel über Protokolle der geladenen Datensätze oder Prüfsummen. Auswertung und Learnings fließen in die Optimierung ein, bevor der nächste Testlauf startet. Über sogenannte Quality Gates wird entschieden, wann die Migration in die nächste Phase geschaltet wird. Oft wird eine Tranche-Strategie gefahren, bei der zunächst Teilmengen (z. B. ein Gebäudebereich oder ein Sachkonto-Bereich) migriert werden, um dann sukzessive auszuweiten. Diese Vorgehensweise erlaubt eine saubere Fehleranalyse in beherrschbaren Datenmengen. Grundsätzlich gilt: Die Staging-Umgebung spiegelbildet technisch das Zielsystem wider und ist optimal für Validierungstests geeignet.

• Feldprüfung (Field-Level Checks): Überprüfen, ob Pflichtfelder ausgefüllt, Datentypen korrekt und Werte im zulässigen Bereich sind. Beispiele sind Null-Checks, Formatprüfungen (z. B. Postleitzahl im Nummernformat) und Bereichs-Checks (z. B. Fläche > 0, Baujahr innerhalb plausibler Grenzen).

• Summen- und Mengengleichheit (Record Counts/Summen): Vergleich der Gesamtanzahl von Datensätzen in Quelle und Ziel sowie Summen wichtiger Kennzahlen. Ein häufiges Vorgehen ist das Summenvergleichsverfahren: Liegen in der Quell- und Zieltabellen dieselben Zeilenanzahl (ggf. abzüglich erwarteter Löschungen) oder dieselben aggregierten Werte vor (z. B. Summe aller Instandhaltungskosten)? Schon einfache Zählungen und Summen geben einen schnellen Hinweis auf fehlende oder doppelte Datensätze.

• Hash- und Prüfsummen-Checks: Bilden von Hash-Werten oder Checksummen über Datensatzfelder, um Bit-für-Bit-Änderungen zu erkennen. Mittels kryptografischer Hash-Funktionen kann schnell überprüft werden, ob ein Datensatz im Ziel noch bitgenau jenem der Quelle entspricht. Ein gängiger Ansatz ist, für jede Zeile einen Hash über relevante Felder zu speichern und im Zielsystem neu zu berechnen und abzugleichen. Abweichungen zeigen schon kleine Modifikationen oder Übertragungsfehler an.

• Referenzprüfungen (Referential Integrity): Sicherstellen, dass alle Fremdschlüsselbeziehungen intakt sind. Dies umfasst beispielsweise das Prüfen, ob jedem Instandhaltungsauftrag (Work Order) eine gültige Anlagen-ID (Asset) zugeordnet wurde, oder ob die im Zielsystem hinterlegten Verknüpfungen konsistent sind. Fehler entstehen oft, wenn über Excel-Migrationsimports zugehörige Datensätze (z. B. Gebäude, Räume) nicht migriert wurden; dann wäre der Fremdschlüssel im Ziel „verwaist“. Solche Abweichungen offenbaren sich z. B. durch JOIN-Abfragen, die „orphaned“ Records liefern. Bei korrekter Migration muss jede Fremdreferenz auf einen existierenden Primärschlüssel zeigen.

• Plausibilitätsprüfungen (Business Rules): Überprüfung, ob Daten den fachlichen Geschäftsregeln genügen. Dazu zählen Querverweise und logische Abhängigkeiten: Etwa muss das Enddatum einer Instandhaltung nach dem Anfangsdatum liegen, Raumflächen dürfen nicht negativ sein und Gebäudeadressen sollten gültigen PLZ und Ländern entsprechen. Oft werden auch Ad-hoc-Regeln formuliert (z. B. „Alle Aufträge über 100.000 € müssen einen geprüften Freigabe-Status haben“). Plausibilitätsprüfungen entdecken semantische Fehler, die mit rein technischer Validierung nicht auffallen.

Durch diese Methoden werden sowohl die Vollständigkeit (Counting, Checksums) als auch die Korrektheit im Detail geprüft. Es gilt jeweils festzulegen, welche Toleranzen zulässig sind (z. B. akzeptierte Fehlerrate bei nicht-kritischen Feldern). Typischerweise erzeugen die Prüfverfahren Prüfberichte oder Logfiles, die festhalten, wie viele Datensätze fehlerhaft waren, welche Summendifferenzen aufgetreten sind, etc. Solche Reports bieten einen Überblick über divergierende Datenteile und unterstützen die Fehleranalyse.

Die Reconciliation ist die abschließende, ganzheitliche Abgleichsstufe im Migrationsprozess: Sie vergleicht – meist automatisiert – den gesamten migrierten Datensatz mit der Ursprungsversion. Dabei werden definierte Kennzahlen (z. B. Datensatzanzahl, Gesamtsummen, Hash-Totals) herangezogen und alle Abweichungen aufgelistet. Moderne Tools können diesen Abgleich automatisiert durchführen. Ein automatisierter Ansatz hat den Vorteil, schnell große Datenmengen zu prüfen und standardisierte Reports zu erzeugen. Beispielsweise lassen sich Skripte oder spezialisierte Validatoren einsetzen, die per SQL oder ETL-Logik automatisch Datensätze zählen, Hashes vergleichen und Reports generieren. Solche Lösungen sind skalierbar und reduzieren menschliche Fehler.

Im Gegensatz dazu steht die manuelle Überprüfung. Sie beinhaltet beispiels­weise stichprobenartige „Screen-to-Screen“-Vergleiche einzelner Datensätze oder das manuelle Abgleichen von Excellisten. Manuelle Verfahren sind flexibler, aber sehr zeitaufwendig und fehleranfällig – insbesondere bei großen Datenvolumina. Sie eignen sich oft nur für kleinere Mengen oder zur Plausibilitätskontrolle von Einzelfällen.

In der Praxis kombiniert man beides: Ein automatisierter Reconciliation-Lauf erzeugt einen Ergebnisbericht mit Diskrepanzen. Dieser Report wird dann von Fachanwendern manuell ausgewertet und freigegeben. Typische Tools sind hier etwa ERP-/CAFM-Migrationswerkzeuge mit integrierten Abgleichsfunktionen, ETL-Validatoren (z. B. Talend Data Quality, Datagaps ETL Validator) oder selbst erstellte SQL- und Python-Skripte (z. B. mit Pandas). Auch Open-Source-Werkzeuge wie Great Expectations oder Deequ können als Validierungslayer eingesetzt werden. Reconciliation-Reports fassen schließlich alle Ergebnisse zusammen: Sie listen die Gesamtzahlen von Source und Ziel, Differenzen je Objektart sowie Fehlermeldungen auf. Dank automatisierter Reports erhält man schnell eine Übersicht, wo Ungleichheiten aufgetreten sind.

Validierungen sind idealerweise direkt in den ETL-Prozess integriert. Bereits während des Daten-Extrakts und der Transformation werden Quality-Gates eingebaut: Beispielsweise wird nach jedem Transformationstep überprüft, ob technische und fachliche Regeln eingehalten sind. Fehlerhafte Datensätze werden in diesem Fall abgetrennt (z. B. in Error-Tables ausgelagert) und nicht in den nachfolgenden Flow aufgenommen. Alle Prüfergebnisse werden protokolliert (Logging) – etwa in Check-Logfiles oder in separat geführten Prüf-Tabellen. Diese Logs enthalten Zeilenzähler, Anzahl geprüfter fehlerhafter Datensätze sowie Fehlertypen. So lässt sich jederzeit nachvollziehen, wie viele Datensätze einen bestimmten ETL-Schritt passiert haben und wo Ausfälle auftraten.

Moderne ETL-Werkzeuge unterstützen dies oft von Haus aus: Sie bieten eingebaute Prüfungs- und Berichtsfunktionen, die die Korrektheit und Vollständigkeit von Quell-, Transformations- und Ladeprozess dokumentieren. Beim Laden ins Zielsystem werden im sogenannten Load-Checkpoint die Anzahl der geladenen Datensätze mit den Quellmengen verglichen. Abweichungen werden entweder automatisch korrigiert (z. B. durch nochmaligen Nachlauf des fehlerhaften Satzes) oder in Error-Logs abgelegt. In ETL-Logs oder gesonderten Fehlerprotokollen werden schließlich alle ungültigen Datensätze erfasst. Dieses „Steuern“ und Protokollieren ungültiger Daten (z. B. Routing in eine Error Queue) ist wichtig, damit fehlerhafte Daten nicht unentdeckt in die Produktion gelangen.

Ergänzend werden in jedem Testlauf auch allgemeine Migrationsmetriken (KPIs) erhoben und visualisiert. Dazu werden Auslastungen und Laufzeiten der ETL-Jobs gemessen oder Checksum-Abweichungen zusammengefasst. Diese Kennzahlen fließen in Dashboards ein, um die Entwicklung über mehrere Testläufe vergleichbar zu machen.

Ein zentrales Kriterium mehrmaliger Testmigrationen ist ihre Reproduzierbarkeit: Jeder Testlauf sollte auf derselben Datenbasis und nach denselben Regeln ablaufen, damit Ergebnisse vergleichbar sind. Dazu werden Migrationsskripte versionsverwaltet (etwa in Git) und Testdaten wiederholt abgerufen oder neu maskiert. Bei jedem Lauf werden dann automatisch Vergleichsberichte erzeugt. So lassen sich Veränderungen im Datenbestand sofort erkennen. In der Vorbereitung werden zudem feste Reconciliations-Metriken definiert (Datensatzanzahl, Summen, Hashes). Bei jedem Testlauf wird dann geprüft, ob diese Metriken innerhalb definierter Toleranzen bleiben. Auf diese Weise können Projektleiter erkennen, ob etwa eine neue Transformations-Logik zu Abweichungen führt.

Ergänzend werden die Umgebungen synchron gehalten: Produktiv-Datensätze werden nach dem Vorbild der realen Daten maskiert und regelmäßig aktualisiert, damit die Tests stets reale Datenvolumina abbilden. Durch eine präzise Dokumentation der angewendeten Datenmengen und Checklisten (Welcher Datensatz wurde migriert? Welche Prüfungen liefen?) wird sichergestellt, dass sich mehrere Testläufe eindeutig vergleichen lassen. Eine weitere Best Practice ist, die ETL-Logik in jeder Runde erneut zu verifizieren und Versionssprünge zu dokumentieren. Insgesamt ergibt sich so ein wiederholbarer Prozess: Jeder Nachtest liefert dieselben Metriken, sodass Abweichungen auf Prozessänderungen und nicht auf zufällige Schwankungen zurückzuführen sind.

• Korrektheit und Vollständigkeit: Die Anzahl der migrierten Datensätze und Schlüsseldaten muss den Sollwerten (Quellsystem) entsprechen. Es werden u. U. Toleranzen definiert (z. B. < 0,1 % Abweichung bei Nicht-Kritischen Daten).

• Fehlerfreiheit wesentlicher Daten: Für kritische Datenfelder (z. B. Stammdaten wie Anlagen-ID, Vertragsnummern) wird verlangt, dass alle geprüften Datensätze korrekt sind. Entsprechend muss die Fehlerrate (laut Prüfbericht) unter einer festgelegten Grenze liegen.

• Leistung und Laufzeit: Die ETL-Laufzeiten sollen innerhalb der Vorgaben bleiben (keine unerwarteten Performance-Einbrüche).

• Fachbereichs-Abnahmen: Entscheidend sind auch fachliche Freigaben. Die jeweiligen Anwenderbereiche prüfen stichprobenweise, ob die Daten den fachlichen Anforderungen genügen (Usability, Vollständigkeit, Plausibilität). Erst nach Freigabe durch den Fachbereich (Abnahmeprotokoll) und Dokumentation der Tests gilt die Migration als erfolgreich.

Prozessual wird die Abnahme oft über ein Review mit Stakeholdern formalisiert. KPI-Dashboards visualisieren, dass sämtliche Kriterien erfüllt sind, und werden gemeinsam mit den Fachabteilungen besprochen. Laut einer Fachpublikation sollten die KPI-Schwellen (z. B. 100 % Datenvollständigkeit, 0 Fehlerrate bei kritischen Feldern) mit den Abnahmekriterien verknüpft sein: Nur wenn die vorgegebenen Werte erreicht sind, wird eine Freigabe für den Produktionsstart erteilt. Teilweise sind auch Audits durch Wirtschaftsprüfer vorgesehen, etwa um die Einhaltung von Compliance-Anforderungen (DSGVO, GoBD) nachzuweisen. Insgesamt wird eine Datenmigration also erst abgenommen, wenn sowohl technische KPIs als auch fachliche Prüfungen (z. B. durch Benutzerakzeptanztests) auf „grün“ stehen.

Für die Validierung und Reconciliation stehen zahlreiche Werkzeuge zur Verfügung. Bekannte kommerzielle Produkte sind beispielsweise ETL- und Datenqualitäts-Tools wie Talend Data Quality, Informatica Data Validation, SAP Data Services oder das Datagaps ETL Validator-Tool, die vordefinierte Prüfkomponenten und Reporting-Funktionen mitbringen. Auch CAFM-spezifische Migrationstools (z. B. Planon Migration Toolkit, AiLab/ERP-Connect oder Hopp) bieten oft Reconciliation-Module. Als Dokumentations-Tools kann Dataedo (zur Datenkatalogisierung) eingesetzt werden, um Mapping und Validierungsergebnisse zu dokumentieren.

Open-Source-Alternativen und Bibliotheken sind ebenfalls sehr verbreitet. So können Python-Bibliotheken (z. B. Pandas, Great Expectations) für kundenspezifische Prüfskripte verwendet werden. Apache Griffin, Deequ (Amazon) oder Soda SQL sind auf Data-Quality-Checks spezialisierte Frameworks. Oft genügen auch einfache SQL-Tools oder Skripte: Viele Entwicklungs- und Reporting-Umgebungen (z. B. SQL-Server, PostgreSQL, Python) ermöglichen individuelle Abfragen und Summenvergleiche. Praxisbeispiel: Great Expectations ist ein Framework, in dem man Validierungsregeln (Expectations) als Code definiert und automatisch gegen Datensätze prüft.

Diese Werkzeuge erlauben, Validierungsregeln zu implementieren, Prüfberichte zu erstellen und Ergebnisse zu visualisieren. Oft werden in ETL-Tools Prüf-Schritte (Transformations-Komponenten) gezogen, um direkt während des Datenflusses Validierungen auszuführen. Für Explorations- und Ad-hoc-Checks dienen zudem Skripte in Python oder SQL.

Um Prüfergebnisse und Migrationsergebnisse transparent zu halten, wird jeder Validierungsschritt detailliert dokumentiert. Dazu gehören zum einen technische Dokumente (Mapping-Tabelle, Feldumwandlungsregeln, Checklisten der Prüfschritte) und zum anderen Prüfberichte selbst (Fehlerlogs, Reconciliation-Reports). Idealerweise wird für jede Testmigration ein Abnahmeprotokoll angelegt, das alle Kennzahlen und Abweichungen festhält. Ein gutes Vorgehen ist zudem Versionskontrolle der ETL-Logik und Mappings (z. B. in Git), damit jede Änderung zurückverfolgt werden kann.

Sowohl das Datenmapping als auch die Ergebnisse der Datenprüfungen sind audit-relevant. Daher dokumentiert man beispielsweise genau, welche Datensätze migriert wurden und wie Validierungsregeln darauf angewendet wurden. Es werden Screenshots oder Auszugstabellen der Source- und Target-Daten aufbewahrt, um Abweichungen später nachvollziehen zu können. Auch die Zusammenfassung der Reconciliation (Stücklisten, Summen, Hash-Werte) wird archiviert. So entsteht ein vollständiger „Audit-Trail“ über den Migrationsprozess. Diese Dokumentation ermöglicht es später, im Nachhinein Fehlerquellen zu analysieren und dient als Referenz für Folgeprojekte.

• Frühzeitige Planung und Stakeholder-Einbindung: Eine lückenlose Bedarfsanalyse und regelmäßige Abstimmung mit Fachabteilungen verhindern Missverständnisse. In realen Migrationsprojekten hat sich gezeigt, dass durch gründliche Vorbereitung und Projekt-Governance viele Fehlerquellen vermieden werden können.

• Datenbereinigung vor Migration: Unsaubere Ausgangsdaten führen später zu Problemen. Entsprechend wird empfohlen, Dubletten zu entfernen und fehlende Informationen vor den Testmigrationen zu ergänzen. Eine sorgfältige Datenqualitätssicherung vorab minimiert Nacharbeiten.

• Iteratives Testen mit Fallback-Strategien: Migrationsläufe sollten in mehreren Zyklen erfolgen, inklusive „Rollback“-Tests. Ein bekanntes Lessons-Learned besagt, Migrationen während geringer Systemlast durchzuführen und stets eine funktionierende Rückfalloption vorzuhalten. So können neue Mappings risikofrei verifiziert werden, bevor man in die finale Umstellung geht.

• Automatisierung und Kennzahlen-Orientierung: Wiederholbare Abläufe werden automatisiert (z. B. per Skript) und über KPIs gesteuert. Transparente Dashboards und automatisierte Prüfungen sorgen dafür, dass Migrationsergebnisse vergleichbar bleiben. Ein strukturierter Ansatz – etwa iteratives Testen nach dem Pareto-Prinzip (zuerst die 20 % der Objekte, die 80 % des Aufwands ausmachen) – wird häufig empfohlen.

• Kontinuierliche Fachabnahmen: Fachbereiche prüfen schon in Testläufen funktionale Aspekte. Benutzerakzeptanztests und Freigabesitzungen zeigen frühzeitig, ob die migrierten Daten wie gewünscht nutzbar sind. Direkte Rückmeldungen der Endanwender führen dazu, dass notwendige Anpassungen rechtzeitig erfolgen.

Planen Sie frühzeitig, setzen Sie auf automatisierte Validierungsprozesse, dokumentieren Sie jeden Schritt und beziehen Sie alle Beteiligten mit ein. So wird sichergestellt, dass die Migration mit hoher Datenqualität und nachvollziehbaren Ergebnissen erfolgt. Fehlgeschlagene Projekte aus der Praxis lehren, dass unzureichende Tests, fehlende Datenqualität oder Vernachlässigung der Fachsicht zu großen Schäden führen können. Ein diszipliniertes Vorgehen nach den hier beschriebenen Best Practices erhöht die Erfolgschancen entscheidend.