{ "site": "DATANALYSIS", "id": "DATA-N2-20261110", "locale": "de", "status": "release_ready", "version": "1.3.0", "robots": "index, follow", "preparedAt": "2026-11-10", "updatedAt": "2026-11-10", "publishedAt": "2026-11-10", "title": "Wenn Daten ihre Bedeutung ändern: Änderungen zwischen Anwendungen vorbereiten", "subtitle": "Die Änderung eines Datenflusses zwischen Anwendungen vorbereiten", "description": "Die Änderungsprüfung eines Datenflusses zwischen Anwendungen vorbereiten: Definition, Einheit, Konsumenten, Tests, Übergang und Wiederherstellung, mit Arbeitsblatt.", "lede": "Ein Update kann korrekt ausgerollt werden, die Verarbeitungen können pünktlich enden, und die Beträge, mit denen die Finanzabteilung arbeitet, können trotzdem falsch werden. Bevor Sie gemeinsam genutzte Daten ändern, müssen Sie daher prüfen, wie die empfangenden Anwendungen sie verstehen werden. Hier ist eine Methode, um diese Prüfung zu organisieren, mit einem Arbeitsblatt für einen konkreten Datenfluss.", "sections": [ { "id": "gueltige-zahl", "heading": "Eine gültige Zahl kann falsch interpretiert werden", "blocks": [ { "p": "Nehmen wir ein fiktives Beispiel. Eine Fakturierungsanwendung übermittelt den Bruttobetrag einer Rechnung im Feld `invoice_total`. Für eine Rechnung über 48,50 Euro sendet sie den numerischen Wert `48.50`. Nach einer Änderung sendet sie `4850`, nun in Cent ausgedrückt. Der Feldname bleibt gleich, und das Schema erlaubt weiterhin eine Zahl." }, { "p": "Eine Prüfung, die nur das Vorhandensein des Feldes und seinen Typ kontrolliert, kann beide Werte akzeptieren. Liest die nachfolgende Verarbeitung jedoch weiterhin Euro, erhält sie 4.850 Euro. In diesem Beispiel ist der interpretierte Betrag hundertmal zu hoch. Die Währung EUR reicht nicht aus, um die Mehrdeutigkeit aufzulösen: Man muss auch die Darstellungseinheit kennen." }, { "p": "Ein Abgleich mit der Quellrechnung oder eine gut gewählte fachliche Regel kann diese Abweichung erkennen. Das Problem ist der Umfang der tatsächlich ausgeführten Prüfung. Ein technischer Status „abgeschlossen“ sagt uns, dass die Verarbeitung gelaufen ist; ob der Betrag stimmt, hängt auch von den vorgesehenen Prüfungen ab." }, { "p": "Die dbt-Dokumentation beschreibt diese Schwierigkeit: Eine Berechnung kann die Ergebnisse einer Spalte ändern, während Name und Typ gleich bleiben. Das Team, das das Modell pflegt, muss die Folgen für seine Nutzer beurteilen. [1]" } ] }, { "id": "verwendungen", "heading": "Verwendungen finden, bevor das Feld geändert wird", "blocks": [ { "p": "Um die Änderung vorzubereiten, schlagen wir vor, von einem Datenelement auszugehen und seinem Weg zu folgen. Wer erzeugt es? Welche Verarbeitungen transformieren es? Welche Anwendungen, Exporte oder Entscheidungen hängen davon ab? Eine Abhängigkeitsansicht ist ein guter Ausgangspunkt, ihre Abdeckung muss aber überprüft werden. Eine exportierte und anschließend manuell weiterverarbeitete Datei kann der technischen Kartierung entgehen." }, { "p": "Stellen wir uns in unserem Beispiel zwei Konsumenten vor: ein Finanz-Monitoring-Dashboard und einen Export für das Forderungsmanagement. Das erste zeigt die Summen an; der zweite dient dazu, eine Liste zu bearbeitender Rechnungen vorzubereiten. Die Änderung muss in beiden Verwendungen getestet werden. Nur das Eintreffen der Daten im Data Warehouse zu validieren, würde die endgültige Lesart ungeprüft lassen." }, { "p": "Halten Sie für jeden Konsumenten eine verantwortliche Person, die anzupassende Verarbeitung und einen erwarteten Nachweis fest. Die verantwortliche Person der Quellanwendung bestätigt die neue Darstellung. Das Integrationsteam prüft die Transformation. Die verantwortliche Person jeder Verwendung bestätigt das erzielte Ergebnis. Eine Person steuert den Übergang und kennt die noch offenen Punkte." }, { "p": "Diese Liste sollte dem Datenfluss angemessen bleiben. Für selten genutzte Daten können wenige Zeilen genügen. Bei einem Betrag, der an mehrere Systeme verteilt wird, sollte eine Abhängigkeit ohne verantwortliche Person geklärt werden, bevor die Umstellung terminiert wird." } ] }, { "id": "definition", "heading": "Definition und Erwartungen explizit machen", "blocks": [ { "p": "Ein Datenvertrag ist eine Vereinbarung zwischen denen, die Daten erzeugen, und denen, die sie nutzen. Confluent unterscheidet in dieser Vereinbarung Struktur, Einschränkungen, Metadaten, Regeln und Weiterentwicklung. [2] Für unsere Prüfung behalten wir die Informationen, mit denen sich entscheiden lässt, ob die Änderung akzeptabel ist." }, { "table": { "caption": "Zu klärende Punkte, angewendet auf das fiktive Beispiel", "head": [ "Zu klärender Punkt", "Anwendung auf unser fiktives Beispiel" ], "rows": [ [ "Fachliche Definition", "Bruttobetrag der Rechnung, eine Rechnung pro Datensatz." ], [ "Einheit und Währung", "Euro vor der Änderung; Euro-Cent danach." ], [ "Sonderfälle", "Negative Gutschriften, Nullbetrag, Stornierung und fehlender Wert, nach expliziten Regeln zu behandeln." ], [ "Versionen und Zeitraum", "Empfangene Version, Wirksamkeitsdatum und Behandlung historischer Rechnungen." ], [ "Konsumenten", "Finanz-Monitoring und Export für das Forderungsmanagement, jeweils mit einer verantwortlichen Person." ], [ "Prüfungen und Reaktion", "Abgleich mit den Quellrechnungen; Stopp oder Ausleitung des Datenflusses bei ungeklärter Abweichung." ] ] } }, { "p": "Dieser Inhalt kann in einem Referenzverzeichnis, einem Code-Repository oder einer versionierten Spezifikation geführt werden. Der Ablageort muss es den betroffenen Teams ermöglichen, ihn zu finden und die Änderung nachzuvollziehen. Das Dokument muss sich anschließend in ausgeführte Prüfungen und zugewiesene Freigaben übersetzen. Eine schriftliche Regel, die nie an einer Abnahme oder Überwachung teilnimmt, erkennt keine Abweichung." }, { "p": "Der Open Data Contract Standard unterscheidet zudem textlich beschriebene Regeln von ausführbaren Regeln, zum Beispiel in SQL oder mit einer Datenqualitäts-Engine. [3] Diese Unterscheidung hilft zu erkennen, was bereits geprüft wird und was noch umzusetzen ist." } ] }, { "id": "gemeinsame-einheit", "heading": "Das Ergebnis in einer gemeinsamen Einheit testen", "blocks": [ { "p": "Ein nützlicher Test vergleicht Werte mit derselben Bedeutung. Beträgt der neue Wert `4850` Cent, ist sein normalisierter Betrag `48.50` Euro. Dieser Betrag ist mit der Referenz in Euro zu vergleichen. Ein direkter Vergleich der beiden Rohzahlen würde eine erwartete Warnung erzeugen, ohne die Umrechnung zu prüfen." }, { "p": "Wählen Sie einen kleinen Satz von Rechnungen mit bekannten erwarteten Ergebnissen. Nehmen Sie die fachlich zulässigen Fälle auf: eine normale Rechnung, eine Gutschrift, einen Nullbetrag und die relevanten Situationen von Stornierung oder fehlendem Wert. Halten Sie für jeden Fall die Eingabedaten, die verwendete Version, das erwartete Ergebnis und das in jedem Konsumenten beobachtete Ergebnis fest." }, { "table": { "caption": "Prüfungen und erwartete Ergebnisse im fiktiven Beispiel", "head": [ "Prüfung", "Erwartetes Ergebnis in unserem Beispiel" ], "rows": [ [ "Rechnung über 48,50 Euro", "`4850` Cent werden nach der Normalisierung zu `48.50` Euro." ], [ "Gutschrift über 12 Euro", "Sind Gutschriften negativ, wird `-1200` zu `-12.00` Euro." ], [ "Fehlende Einheit oder unbekannte Version", "Die Verarbeitung wendet die vereinbarte Regel an und meldet den Fall; sie errät die Einheit nicht." ], [ "Gleicher Rechnungsstapel", "Die normalisierte Summe entspricht der Referenz, mit einer dokumentierten Rundungsregel." ], [ "Erneutes Einspielen eines Stapels", "Das Ergebnis enthält kein zusätzliches Duplikat." ] ] } }, { "p": "Die Summe ist nützlich, kann aber Fehler verdecken, die sich gegenseitig ausgleichen. Prüfen Sie auch die Zeilen, ihre Anzahl und ihre Identität. Eine Toleranz braucht einen fachlichen Grund, zum Beispiel eine definierte Rundung; ein Schwellenwert, der nur gewählt wird, um die Abnahme zu bestehen, macht die Prüfung wenig aussagekräftig." }, { "p": "Legen Sie bei Beträgen außerdem fest, wo gerundet wird und wie viele Nachkommastellen erhalten bleiben. Dieselbe Berechnung auf Zeilenebene oder nach der Aggregation kann unterschiedliche Ergebnisse liefern. Diese Entscheidung muss von den betroffenen Konsumenten geteilt werden." } ] }, { "id": "uebergang", "heading": "Den Übergang nach den Abhängigkeiten wählen", "blocks": [ { "p": "Wenn alle Konsumenten gemeinsam angepasst werden können, kann eine koordinierte Umstellung passen. Dann müssen die Reihenfolge der Eingriffe, die Tests nach dem Deployment und die Entscheidung festgelegt werden, falls einer davon fehlschlägt. Ein kurzes Zeitfenster entbindet nicht davon, zu wissen, wer die Verarbeitung stoppen kann." }, { "p": "Haben die Teams unterschiedliche Zeitpläne, kann eine Phase der Koexistenz nötig sein. In unserem Beispiel könnte die Quelle eine neue Version oder ein neues Feld mit expliziter Einheit bereitstellen. Die Konsumenten migrieren dann nach einem bekannten Zeitplan. Es gilt zu vermeiden, dass dasselbe Datenelement nacheinander „Euro“ und dann „Cent“ bedeutet, ohne die beiden Darstellungen zuverlässig unterscheiden zu können." }, { "p": "dbt erlaubt für versionierte Modelle, parallele Versionen beizubehalten und ein Abkündigungsdatum festzulegen. Die Dokumentation weist auch auf die Kosten dieser Koexistenz hin. [1] Das Prinzip ist über dieses Werkzeug hinaus nützlich: Jede beibehaltene Version braucht identifizierte Nutzer und eine Bedingung für ihre Entfernung. Kopien ohne Zeitplan zu vervielfachen, verschiebt das Problem nur." }, { "p": "Der Übergang muss auch die Historie behandeln. Bleiben bereits erfasste Rechnungen in der alten Darstellung? Werden sie umgerechnet? Wie erkennt man einen alten Stapel, der nach der Umstellung erneut eingespielt wird? Ein Verarbeitungsdatum allein kann unzureichend sein, wenn der Stapel ältere Daten enthält. Eine explizite Version oder eine andere eindeutige Regel muss die Interpretation leiten." } ] }, { "id": "wiederherstellung", "heading": "Die Wiederherstellung vor der Freigabe vorbereiten", "blocks": [ { "p": "Das Zurückrollen muss den Code und die bereits verarbeiteten Daten abdecken. Eine alte Verarbeitung wieder in Betrieb zu nehmen, korrigiert nicht automatisch die während des Vorfalls verteilten Beträge. Legen Sie den betroffenen Stapel fest, die auszusetzenden Ausgaben und die Art, wie die Ergebnisse ohne Duplikate neu berechnet oder korrigiert werden." }, { "p": "Vor der Umstellung muss das Team eine konkrete Frage beantworten können: Wenn die Prüfung einer Rechnung fehlschlägt, welche Maßnahme stoppt die Ausbreitung und wer löst sie aus? Je nach Datenfluss kann das ein Zurückhalten, eine Datenquarantäne oder ein Stopp des Konsumenten sein. Die Antwort hängt von den Kosten falscher Daten und den Kosten einer Unterbrechung ab." }, { "p": "Legen Sie auch den Kontrollpunkt nach dem Deployment fest. Die verantwortlichen Personen der Verwendungen müssen ihre Ergebnisse auf demselben Datenumfang bestätigen. Der Abschluss der Änderung kann sich dann auf identifizierte Nachweise stützen, und die Entfernung der alten Version darauf, dass keine Konsumenten mehr von ihr abhängen." } ] }, { "id": "naechste-pruefung", "heading": "Ihre nächste Änderungsprüfung vorbereiten", "blocks": [ { "p": "Das zugehörige Arbeitsblatt greift diese Vorgehensweise auf: ein ausgefülltes fiktives Beispiel, dann ein Raster, um Ihren Datenfluss zu dokumentieren. Es ersetzt keine Testergebnisse: Es zeigt, was geprüft werden muss, von wem, und wo der Nachweis zu finden ist." }, { "p": "Beginnen Sie mit einem Datenelement, dessen Änderung bereits geplant ist. Bringen Sie das Quellteam und die verantwortlichen Personen der Verwendungen zusammen. Wenn Sie einen Konsumenten, seine erwartete Einheit oder seine verantwortliche Person noch nicht benennen können, haben Sie einen Punkt gefunden, der vor der Auslieferung zu klären ist." } ] } ], "body_markdown": "## Eine gültige Zahl kann falsch interpretiert werden\n\nNehmen wir ein fiktives Beispiel. Eine Fakturierungsanwendung übermittelt den Bruttobetrag einer Rechnung im Feld `invoice_total`. Für eine Rechnung über 48,50 Euro sendet sie den numerischen Wert `48.50`. Nach einer Änderung sendet sie `4850`, nun in Cent ausgedrückt. Der Feldname bleibt gleich, und das Schema erlaubt weiterhin eine Zahl.\n\nEine Prüfung, die nur das Vorhandensein des Feldes und seinen Typ kontrolliert, kann beide Werte akzeptieren. Liest die nachfolgende Verarbeitung jedoch weiterhin Euro, erhält sie 4.850 Euro. In diesem Beispiel ist der interpretierte Betrag hundertmal zu hoch. Die Währung EUR reicht nicht aus, um die Mehrdeutigkeit aufzulösen: Man muss auch die Darstellungseinheit kennen.\n\nEin Abgleich mit der Quellrechnung oder eine gut gewählte fachliche Regel kann diese Abweichung erkennen. Das Problem ist der Umfang der tatsächlich ausgeführten Prüfung. Ein technischer Status „abgeschlossen“ sagt uns, dass die Verarbeitung gelaufen ist; ob der Betrag stimmt, hängt auch von den vorgesehenen Prüfungen ab.\n\nDie dbt-Dokumentation beschreibt diese Schwierigkeit: Eine Berechnung kann die Ergebnisse einer Spalte ändern, während Name und Typ gleich bleiben. Das Team, das das Modell pflegt, muss die Folgen für seine Nutzer beurteilen. [1]\n\n## Verwendungen finden, bevor das Feld geändert wird\n\nUm die Änderung vorzubereiten, schlagen wir vor, von einem Datenelement auszugehen und seinem Weg zu folgen. Wer erzeugt es? Welche Verarbeitungen transformieren es? Welche Anwendungen, Exporte oder Entscheidungen hängen davon ab? Eine Abhängigkeitsansicht ist ein guter Ausgangspunkt, ihre Abdeckung muss aber überprüft werden. Eine exportierte und anschließend manuell weiterverarbeitete Datei kann der technischen Kartierung entgehen.\n\nStellen wir uns in unserem Beispiel zwei Konsumenten vor: ein Finanz-Monitoring-Dashboard und einen Export für das Forderungsmanagement. Das erste zeigt die Summen an; der zweite dient dazu, eine Liste zu bearbeitender Rechnungen vorzubereiten. Die Änderung muss in beiden Verwendungen getestet werden. Nur das Eintreffen der Daten im Data Warehouse zu validieren, würde die endgültige Lesart ungeprüft lassen.\n\nHalten Sie für jeden Konsumenten eine verantwortliche Person, die anzupassende Verarbeitung und einen erwarteten Nachweis fest. Die verantwortliche Person der Quellanwendung bestätigt die neue Darstellung. Das Integrationsteam prüft die Transformation. Die verantwortliche Person jeder Verwendung bestätigt das erzielte Ergebnis. Eine Person steuert den Übergang und kennt die noch offenen Punkte.\n\nDiese Liste sollte dem Datenfluss angemessen bleiben. Für selten genutzte Daten können wenige Zeilen genügen. Bei einem Betrag, der an mehrere Systeme verteilt wird, sollte eine Abhängigkeit ohne verantwortliche Person geklärt werden, bevor die Umstellung terminiert wird.\n\n## Definition und Erwartungen explizit machen\n\nEin Datenvertrag ist eine Vereinbarung zwischen denen, die Daten erzeugen, und denen, die sie nutzen. Confluent unterscheidet in dieser Vereinbarung Struktur, Einschränkungen, Metadaten, Regeln und Weiterentwicklung. [2] Für unsere Prüfung behalten wir die Informationen, mit denen sich entscheiden lässt, ob die Änderung akzeptabel ist.\n\n| Zu klärender Punkt | Anwendung auf unser fiktives Beispiel |\n|---|---|\n| Fachliche Definition | Bruttobetrag der Rechnung, eine Rechnung pro Datensatz. |\n| Einheit und Währung | Euro vor der Änderung; Euro-Cent danach. |\n| Sonderfälle | Negative Gutschriften, Nullbetrag, Stornierung und fehlender Wert, nach expliziten Regeln zu behandeln. |\n| Versionen und Zeitraum | Empfangene Version, Wirksamkeitsdatum und Behandlung historischer Rechnungen. |\n| Konsumenten | Finanz-Monitoring und Export für das Forderungsmanagement, jeweils mit einer verantwortlichen Person. |\n| Prüfungen und Reaktion | Abgleich mit den Quellrechnungen; Stopp oder Ausleitung des Datenflusses bei ungeklärter Abweichung. |\n\nDieser Inhalt kann in einem Referenzverzeichnis, einem Code-Repository oder einer versionierten Spezifikation geführt werden. Der Ablageort muss es den betroffenen Teams ermöglichen, ihn zu finden und die Änderung nachzuvollziehen. Das Dokument muss sich anschließend in ausgeführte Prüfungen und zugewiesene Freigaben übersetzen. Eine schriftliche Regel, die nie an einer Abnahme oder Überwachung teilnimmt, erkennt keine Abweichung.\n\nDer Open Data Contract Standard unterscheidet zudem textlich beschriebene Regeln von ausführbaren Regeln, zum Beispiel in SQL oder mit einer Datenqualitäts-Engine. [3] Diese Unterscheidung hilft zu erkennen, was bereits geprüft wird und was noch umzusetzen ist.\n\n## Das Ergebnis in einer gemeinsamen Einheit testen\n\nEin nützlicher Test vergleicht Werte mit derselben Bedeutung. Beträgt der neue Wert `4850` Cent, ist sein normalisierter Betrag `48.50` Euro. Dieser Betrag ist mit der Referenz in Euro zu vergleichen. Ein direkter Vergleich der beiden Rohzahlen würde eine erwartete Warnung erzeugen, ohne die Umrechnung zu prüfen.\n\nWählen Sie einen kleinen Satz von Rechnungen mit bekannten erwarteten Ergebnissen. Nehmen Sie die fachlich zulässigen Fälle auf: eine normale Rechnung, eine Gutschrift, einen Nullbetrag und die relevanten Situationen von Stornierung oder fehlendem Wert. Halten Sie für jeden Fall die Eingabedaten, die verwendete Version, das erwartete Ergebnis und das in jedem Konsumenten beobachtete Ergebnis fest.\n\n| Prüfung | Erwartetes Ergebnis in unserem Beispiel |\n|---|---|\n| Rechnung über 48,50 Euro | `4850` Cent werden nach der Normalisierung zu `48.50` Euro. |\n| Gutschrift über 12 Euro | Sind Gutschriften negativ, wird `-1200` zu `-12.00` Euro. |\n| Fehlende Einheit oder unbekannte Version | Die Verarbeitung wendet die vereinbarte Regel an und meldet den Fall; sie errät die Einheit nicht. |\n| Gleicher Rechnungsstapel | Die normalisierte Summe entspricht der Referenz, mit einer dokumentierten Rundungsregel. |\n| Erneutes Einspielen eines Stapels | Das Ergebnis enthält kein zusätzliches Duplikat. |\n\nDie Summe ist nützlich, kann aber Fehler verdecken, die sich gegenseitig ausgleichen. Prüfen Sie auch die Zeilen, ihre Anzahl und ihre Identität. Eine Toleranz braucht einen fachlichen Grund, zum Beispiel eine definierte Rundung; ein Schwellenwert, der nur gewählt wird, um die Abnahme zu bestehen, macht die Prüfung wenig aussagekräftig.\n\nLegen Sie bei Beträgen außerdem fest, wo gerundet wird und wie viele Nachkommastellen erhalten bleiben. Dieselbe Berechnung auf Zeilenebene oder nach der Aggregation kann unterschiedliche Ergebnisse liefern. Diese Entscheidung muss von den betroffenen Konsumenten geteilt werden.\n\n## Den Übergang nach den Abhängigkeiten wählen\n\nWenn alle Konsumenten gemeinsam angepasst werden können, kann eine koordinierte Umstellung passen. Dann müssen die Reihenfolge der Eingriffe, die Tests nach dem Deployment und die Entscheidung festgelegt werden, falls einer davon fehlschlägt. Ein kurzes Zeitfenster entbindet nicht davon, zu wissen, wer die Verarbeitung stoppen kann.\n\nHaben die Teams unterschiedliche Zeitpläne, kann eine Phase der Koexistenz nötig sein. In unserem Beispiel könnte die Quelle eine neue Version oder ein neues Feld mit expliziter Einheit bereitstellen. Die Konsumenten migrieren dann nach einem bekannten Zeitplan. Es gilt zu vermeiden, dass dasselbe Datenelement nacheinander „Euro“ und dann „Cent“ bedeutet, ohne die beiden Darstellungen zuverlässig unterscheiden zu können.\n\ndbt erlaubt für versionierte Modelle, parallele Versionen beizubehalten und ein Abkündigungsdatum festzulegen. Die Dokumentation weist auch auf die Kosten dieser Koexistenz hin. [1] Das Prinzip ist über dieses Werkzeug hinaus nützlich: Jede beibehaltene Version braucht identifizierte Nutzer und eine Bedingung für ihre Entfernung. Kopien ohne Zeitplan zu vervielfachen, verschiebt das Problem nur.\n\nDer Übergang muss auch die Historie behandeln. Bleiben bereits erfasste Rechnungen in der alten Darstellung? Werden sie umgerechnet? Wie erkennt man einen alten Stapel, der nach der Umstellung erneut eingespielt wird? Ein Verarbeitungsdatum allein kann unzureichend sein, wenn der Stapel ältere Daten enthält. Eine explizite Version oder eine andere eindeutige Regel muss die Interpretation leiten.\n\n## Die Wiederherstellung vor der Freigabe vorbereiten\n\nDas Zurückrollen muss den Code und die bereits verarbeiteten Daten abdecken. Eine alte Verarbeitung wieder in Betrieb zu nehmen, korrigiert nicht automatisch die während des Vorfalls verteilten Beträge. Legen Sie den betroffenen Stapel fest, die auszusetzenden Ausgaben und die Art, wie die Ergebnisse ohne Duplikate neu berechnet oder korrigiert werden.\n\nVor der Umstellung muss das Team eine konkrete Frage beantworten können: Wenn die Prüfung einer Rechnung fehlschlägt, welche Maßnahme stoppt die Ausbreitung und wer löst sie aus? Je nach Datenfluss kann das ein Zurückhalten, eine Datenquarantäne oder ein Stopp des Konsumenten sein. Die Antwort hängt von den Kosten falscher Daten und den Kosten einer Unterbrechung ab.\n\nLegen Sie auch den Kontrollpunkt nach dem Deployment fest. Die verantwortlichen Personen der Verwendungen müssen ihre Ergebnisse auf demselben Datenumfang bestätigen. Der Abschluss der Änderung kann sich dann auf identifizierte Nachweise stützen, und die Entfernung der alten Version darauf, dass keine Konsumenten mehr von ihr abhängen.\n\n## Ihre nächste Änderungsprüfung vorbereiten\n\nDas zugehörige Arbeitsblatt greift diese Vorgehensweise auf: ein ausgefülltes fiktives Beispiel, dann ein Raster, um Ihren Datenfluss zu dokumentieren. Es ersetzt keine Testergebnisse: Es zeigt, was geprüft werden muss, von wem, und wo der Nachweis zu finden ist.\n\nBeginnen Sie mit einem Datenelement, dessen Änderung bereits geplant ist. Bringen Sie das Quellteam und die verantwortlichen Personen der Verwendungen zusammen. Wenn Sie einen Konsumenten, seine erwartete Einheit oder seine verantwortliche Person noch nicht benennen können, haben Sie einen Punkt gefunden, der vor der Auslieferung zu klären ist.", "closing": "Sie ändern Daten, die von mehreren Anwendungen genutzt werden? Sprechen wir über einen konkreten Datenfluss, um seine Abhängigkeiten, die vorzusehenden Prüfungen und den Übergang abzustecken.", "cta": { "label": "Datenfluss mit DATANALYSIS besprechen", "url": "https://datanalysis.re/contact?lang=de" }, "worksheet": { "label": "Arbeitsblatt öffnen (druckbares HTML)", "url": "https://datanalysis.re/ressources/data-engineering/daten-bedeutung-aenderungen-zwischen-anwendungen/arbeitsblatt", "fields": [ [ "Betroffener Datenfluss", "invoice_total: Fakturierungsanwendung zum Finanz-Monitoring-Dashboard und zum Export für das Forderungsmanagement." ], [ "Verantwortlich für die Änderung", "Eine Person steuert den Übergang und kennt die noch offenen Punkte." ], [ "Definition und Granularität", "Bruttobetrag der Rechnung, eine Rechnung pro Datensatz." ], [ "Einheit, Währung, Version: vorher", "Euro, Währung EUR: 48.50 für eine Rechnung über 48,50 €; aktuelle Version." ], [ "Einheit, Währung, Version: nachher", "Euro-Cent, Währung EUR: 4850 (4850 = 48,50 €); explizite empfangene Version und Wirksamkeitsdatum." ], [ "Konsumenten und Verantwortliche", "Finanz-Monitoring-Dashboard; Export für das Forderungsmanagement. Eine verantwortliche Person pro Konsument; Integrationsteam für die Transformation; die verantwortliche Person der Fakturierungsanwendung bestätigt die neue Darstellung." ], [ "Prüfungen und Nachweise", "Rechnung 48,50 €, Gutschrift -12,00 €, Nullbetrag, fehlende Einheit oder unbekannte Version, Stapelsumme mit dokumentierter Rundung, erneutes Einspielen ohne Duplikate. Nachweis: Eingabe, Version, erwartetes und beobachtetes Ergebnis in jedem Konsumenten." ], [ "Übergang, Historie, Entfernung", "Koordinierte Umstellung oder Koexistenz mit Feld oder Version mit expliziter Einheit und Migrationszeitplan; Behandlung historischer Rechnungen; Entfernung, wenn kein Konsument mehr von der alten Version abhängt." ], [ "Reaktion und Wiederherstellung", "Betroffener Stapel, auszusetzende Ausgaben, Maßnahme, die die Ausbreitung stoppt, und wer sie auslöst, Korrektur ohne Duplikate, Kontrolle nach dem Deployment." ], [ "Entscheidung", "Freigabe nur, wenn jeder Konsument eine verantwortliche Person, eine erwartete Einheit und einen identifizierten Nachweis hat." ], [ "Freigebende und Rollen", "Verantwortliche Person der Quellanwendung; Integrationsteam; verantwortliche Person jeder Verwendung; Person, die den Übergang steuert." ], [ "Datum", "Datum der Prüfung, Wirksamkeitsdatum der neuen Version, Kontrollpunkt nach dem Deployment (fiktives Beispiel: kein reales Datum)." ], [ "Vorbehalte", "Eine exportierte und manuell weiterverarbeitete Datei kann der technischen Kartierung entgehen: vor der Umstellung prüfen." ] ], "pdf": "https://datanalysis.re/downloads/data-n2-fiche-remplissable.de.pdf" }, "pdf": { "article": "https://datanalysis.re/downloads/data-n2-article.de.pdf", "worksheet": "https://datanalysis.re/downloads/data-n2-fiche-remplissable.de.pdf", "pack": "https://datanalysis.re/downloads/data-n2-pack-fr-en-de.zip" }, "related_articles": [ { "title": "Einen Datenfluss wieder aufnehmen, ohne seine Wirkungen zu vervielfachen", "url": "https://datanalysis.re/ressources/data-engineering/datenfluss-wiederaufnehmen-ohne-doppelte-wirkungen" }, { "title": "Eine Datenplattform modernisieren, während das Unternehmen weiterarbeitet", "url": "https://datanalysis.re/ressources/data-engineering/datenplattform-modernisieren-laufender-betrieb" } ], "sources": [ { "n": 1, "label": "dbt Labs | Model versions", "url": "https://docs.getdbt.com/docs/mesh/govern/model-versions", "note": "Berechnungsänderung ohne Änderung von Name oder Typ; Versionen und Abkündigung" }, { "n": 2, "label": "Confluent | Data Contracts for Schema Registry", "url": "https://docs.confluent.io/cloud/current/sr/fundamentals/data-contracts.html", "note": "Struktur, Regeln, Metadaten, Weiterentwicklung" }, { "n": 3, "label": "Bitol | Open Data Contract Standard, Data Quality, version 3.2.0", "url": "https://bitol-io.github.io/open-data-contract-standard/v3.2.0/data-quality/", "note": "textliche Beschreibung gegenüber ausführbarer Prüfung" } ], "sources_note": "Quellen am 10. November 2026 erneut geprüft. Methode und Beispiele dienen der Veranschaulichung; es werden keine Kundenergebnisse dargestellt.", "canonical": "https://datanalysis.re/ressources/data-engineering/daten-bedeutung-aenderungen-zwischen-anwendungen", "alternates": { "fr": "https://datanalysis.re/ressources/data-engineering/donnee-change-de-sens-evolution-flux", "en": "https://datanalysis.re/ressources/data-engineering/data-changes-meaning-across-applications", "de": "https://datanalysis.re/ressources/data-engineering/daten-bedeutung-aenderungen-zwischen-anwendungen" } }