• TEDAMOH

    Blog

Vertrauen, Audits und Nachvollziehbarkeit: Bitemporalität als Governance-Grundlage

Am Ende von Teil 3 stand eine Frage im Raum: ob ihr eigentlich nachweisen könnt, was in euren Reports steht – und wer euch danach überhaupt fragt. Drei Teile lang ging es um die fachliche Anwendung. Jetzt fragt jemand von außen nach. Und die Argumentation, die das Management überzeugt, beginnt genau an dieser Stelle.

Wer Sylvia, Diego, Michael, Yerodin und Amal noch nicht kennt: Sie sind fiktive Figuren aus dem FastChangeCo-Universum, mit dem ich reale Herausforderungen aus Projekten und Coachings greifbar mache.

Dieser Artikel schließt eine vierteilige Serie über bitemporale Daten in der Praxis ab. Er bündelt die drei strategischen Gründe aus dem Hub-Artikel „8 Gründe, warum man bitemporale Daten benötigt" – Entscheidungsanalyse, gesetzliche Regelungen, Überprüfung und Audit –, die sonst nur als Stichworte für „das macht man halt im Finanzsektor" durchgehen.

Die eine Frage, die diesen Artikel trägt: Können wir nachweisen, was wir wann wussten? Sie klingt nach Pflicht, doch sie endet woanders.

Die eine Zeile, die niemand sofort unterschreibt

Bei FastChangeCo liegt ein Vertrag auf dem Tisch. Ein Großkunde, ein Volumen, bei dem niemand „nein" sagen möchte, eine Mappe mit vierzig Seiten Klauseln, die meisten davon Routine. Sylvia Seven, CFO, liest sie trotzdem alle. An einer bleibt sie hängen.

„Der Auftragnehmer stellt sicher, dass für jeden gelieferten Datensatz jederzeit rekonstruiert werden kann, zu welchem Zeitpunkt er mit welchem Kenntnisstand bereitgestellt wurde."

Sylvia liest sie zweimal. „Das ist ein Satz", sagt sie, „aber keiner, den ich nebenbei unterschreibe." Sie ruft Michael dazu, Head of Data Management. Er liest, schweigt, liest nochmal.

„Jeder gelieferte Datensatz", sagt Michael schließlich. „Nicht der aktuelle Stand. Jeder. Und nicht nur, was wir geliefert haben, sondern wann – und was wir zu dem Zeitpunkt überhaupt wussten." Er rechnet im Kopf kurz hoch, was das an Lieferungen pro Jahr bedeutet, und der Wert gefällt ihm nicht. „Wenn der Kunde in zwei Jahren fragt, warum eine Kennzahl im März so aussah, wie sie aussah – dann muss ich den März von vor zwei Jahren wieder herstellen können. Nicht ungefähr – genau."

Sylvia bleibt still. Sie hat in ihrer Laufbahn genug Verträge gesehen, um zu wissen, dass solche Sätze nicht aus Misstrauen entstehen, sondern aus Erfahrung – irgendwann hat dieser Kunde einmal eine Zahl bekommen, die sich später still verändert hat, und niemand konnte ihm sagen, was zwischen damals und heute passiert war. Die Klausel ist die Narbe dieser Erfahrung.

Sylvia nickt langsam. Sie sagt nichts Lösendes, keine Pointe, kein „im Grunde ist das ja". Sie merkt nur an: „Wir liefern dem Kunden ohnehin jeden Monat Zahlen. Die Frage ist, ob wir sie auch zurückholen können, wenn sie alt sind."

Genau das ist der wunde Punkt. Ein klassischer Datenbestand kennt nur einen Zustand: den aktuellen. Wer überschreibt, verliert das Davor. Und eine Klausel, die „jederzeit rekonstruieren" verlangt, fragt nach genau dem, was Überschreiben vernichtet.

Diego rechnet nach

As-Of-Schnitt auf der Assertion Timeline zu einem vergangenen Stichtag, spätere Erkenntnisse bleiben unsichtbarMichael holt Diego dazu, Coach und Mentor des Teams. Diego liest die Klausel, dann lächelt er ein bisschen – aber nicht, weil er die Lösung verkünden will, sondern weil ihm etwas bekannt vorkommt. „Lies den Satz nochmal langsam: ‚mit welchem Kenntnisstand bereitgestellt'. Da geht es nicht um die Lieferung – da geht es darum, was ihr in dem Moment wusstet."

Er greift zum Stift. „Wann ein Wert in der Realität galt, und wann ihr von ihm wusstet – das sind zwei verschiedene Dinge. Ihr trennt sie längst." Auf das Whiteboard kommen die zwei Zeitlinien, die seit Teil 2 dort eigentlich immer stehen: die Assertion Timeline (technisch) hält fest, wann wir von einem Wert erfahren haben, die State Timeline (fachlich) hält fest, ab wann er gilt.

„Der Kenntnisstand zu einem Stichtag", sagt Diego, „ist nichts anderes als ein Schnitt durch die Assertion Timeline. Ihr fragt: Was war im März bekannt? Und schneidet alles weg, was ihr erst danach erfahren habt. Das ist die As-Of-Sicht – dieselbe, mit der Yerodin in Teil 3 seinen Forecast stabil gehalten hat." Er zeichnet den Schnitt ein. „Und nebenbei: wegwerfen dürft ihr die alten Stände sowieso nicht, also liegt der Stoff für die Rekonstruktion längst da, wo er hingehört."

Michael sieht es kommen. „Heißt, wir bauen für die Klausel gar nichts Neues. Wir lesen das, was schon da ist, nur aus einem anderen Blickwinkel." Diego: „Diesen Blickwinkel habt ihr euch in den letzten drei Quartalen erarbeitet, ohne an einen Kundenvertrag zu denken."

Diego macht es konkret. „Stellt euch vor, der Kunde fragt im November: Welche Umsatzzahl habt ihr uns für den März gemeldet – und was wusstet ihr damals schon über die Nachbuchungen, die erst im Mai kamen? Ohne die Trennung müsstet ihr raten oder lange suchen. Mit der Assertion Timeline setzt ihr den Schnitt auf Ende März und lest ab, was zu diesem Zeitpunkt im System stand – nicht der heutige, der von damals." Genau das ist der Unterschied zwischen „was stimmt heute" und „was haben wir damals geliefert" – und beide Antworten liegen in derselben Tabelle.

Wer an dieser Stelle wissen will, wie sich so ein Befund in echtes Budget und einen Fahrplan übersetzt: In Strategie-Workshops mit Data-Management-Leads und CDOs zeichne ich genau diese zwei Bilder nebeneinander – was euer Datenfundament heute schon trägt, und wo die Lücken sind, bevor jemand von außen danach fragt.

Was Yerodins Reports plötzlich wert sind

Audit-Spur eines korrigierten Werts auf beiden Zeitlinien mit Markierung von Gültigkeit, Korrekturzeitpunkt und damals sichtbarem StandYerodin, Controller, kommt eher zufällig dazu und erkennt seine eigenen Reports wieder. „Das ist doch das, womit ich seit dem Tarif-Thema arbeite. Mein Q3-Vergleich zieht heute noch denselben Stand wie beim Q3-Abschluss – egal, was HR seither nachgebucht hat."

Genau die Reports, die Yerodin gebaut hat, damit er ruhig schlafen kann, sind jetzt der Nachweis, den die Klausel verlangt. Amal, Data Modeler, fasst die Mechanik in einem Satz zusammen: „Es ist der Werkzeugkasten aus Teil 2 – Allen Relationship, Closed-Open-Intervalle –, nur dass ihn diesmal kein Controller liest, sondern ein Kunde." Der Hub-Artikel zur Serie nennt das den Grund „Überprüfung und Audit".

Wie das konkret aussieht, zeigt ein kleiner Vorfall, der nichts mit dem Großkunden zu tun hat. Eine interne Abteilung reklamiert: „Ihr habt unsere Umsatzzahlen für Februar nachträglich geändert." Vorwurf im Raum, früher der Beginn einer langen Suche – diesmal nicht. Das Team zieht den Februar-Stand, wie er beim Monatsabschluss sichtbar war, daneben den heutigen, dazu den Zeitpunkt und den Grund der Korrektur. Wann, wie, warum – in einer Abfrage. Die Reklamation ist nach zehn Minuten kein Streit mehr, sondern eine Erklärung.

Michael erinnert sich an früher, fast beiläufig: „Weißt du, was das eigentlich ersetzt? Den Kollegen, der an Silvester ins Büro musste, um den Jahresend-Snapshot vom Warehouse zu ziehen – falls wir den Stand mal wieder brauchen. Den brauchen wir nicht mehr. Der Stand ist immer da."

Yerodin lacht kurz. „Früher hätte so eine Reklamation einen halben Tag gekostet – und am Ende hätte uns trotzdem keiner geglaubt." Amal, trocken: „Jetzt muss auch keiner uns glauben. Es steht in den Daten, wann sich was geändert hat und warum. Das ist ein anderer Gesprächston."

Sylvia, zum zweiten Mal

Eine bitemporale Struktur in der Mitte, von der zwei Pfeile ausgehen: interner Bedarf an sauberen Daten und externe Nachweis-AnforderungSylvia hat die ganze Zeit zugehört, mehr als sie geredet hat. Als Diego fertig ist, sagt sie nicht „also unterschreiben wir". Sie sagt: „Bei meinem vorherigen Arbeitgeber hatten wir eine BaFin-Prüfung. Anstrengend, wochenlang. Aber am Ende wusste ich über unsere eigenen Zahlen Dinge, die ich vorher nur vermutet hatte. Ich habe die Prüfung nicht gemocht. Ich habe sie nicht bereut."

Mehr sagt sie dazu nicht. Sie schaut auf die Klausel, dann auf das Whiteboard mit den zwei Zeitlinien, dann wieder auf die Klausel. „Wir haben das Fundament für etwas gelegt, das wir intern wollten – stabile Reports, saubere Korrekturen, ein Forecast, der nicht wackelt. Und jetzt steht hier ein Kunde, der zufällig dasselbe Fundament verlangt." Sie lässt den Satz stehen, ohne ihn aufzulösen.

Im Hub-Artikel ist das der Grund „Gesetzliche Regelungen": Gerade in der Finanz- und Versicherungsbranche gibt es Anforderungen an eine unveränderbare, unlöschbare Speicherung. Was bei FastChangeCo als Kundenklausel auftaucht, steht bei anderen im Gesetz – die Mechanik dahinter ist dieselbe. Und der Grund „Entscheidungsanalyse" liegt direkt daneben: Wer den Kenntnisstand von damals rekonstruieren kann, kann auch nachvollziehen, ob eine Entscheidung mit dem damaligen Wissen richtig war – nicht mit dem von heute.

 


Über diese Serie: Dies ist Teil 4 und der Abschluss unserer Serie „Bitemporale Daten in der Praxis", die vom konkreten Engineering-Schmerz bis zur strategischen Entscheidung führt. Teil 1 nimmt sich Late Arrivals und Korrekturen vor. Teil 2 behandelt den technischen Kern der Zeitreisen mit Allen Relationship und Closed-Open-Intervallen. Teil 3 zeigt den Geschäftswert jenseits der Gegenwart. Den Gesamtüberblick gibt der Hub-Artikel „8 Gründe, warum man bitemporale Daten benötigt".


Steht bei euch demnächst ein Audit, eine Prüfung oder eine Nachweis-Klausel an?

Im 2-stündigen Strategie-Workshop mit Data-Management-Leads und CDOs zeichnen wir zwei Bilder nebeneinander: was euer Datenfundament heute schon trägt – und wo die Lücken sind, bevor jemand von außen danach fragt.

→ Strategie-Workshop anfragen

Vom Schmerz zur Entscheidung

Die ATK-Klausel oben, darunter aufgefächert die drei strategischen Gründe Audit, Regulatorik und Entscheidungsanalyse, daneben der Vier-Teile-Bogen der Serie

Schaut man jetzt nochmal auf die Klausel, liest sie sich anders. „Für jeden gelieferten Datensatz" – das ist die Frage nach unveränderbarer, unlöschbarer Aufbewahrung. „Zu welchem Zeitpunkt" – das ist die Audit-Spur, wann, wie, warum. „Mit welchem Kenntnisstand" – das ist die Entscheidungsanalyse, das Wissen von damals. Drei der acht Gründe aus dem Hub, in einem einzigen Vertragssatz, ohne dass irgendwer sie dort hineingeschrieben hätte.

Das ist der Bogen dieser Serie. Teil 1 begann mit einem Engineering-Schmerz: Daten, die in der falschen Reihenfolge ankommen. Teil 2 baute die Mechanik – zwei Zeitlinien, sauber getrennt. Teil 3 zeigte den Geschäftswert: Vergangenheit, Gegenwart und Zukunft als planbare Achse. Und hier, in Teil 4, stellt sich heraus, dass dasselbe Fundament eine Frage beantwortet, die niemand beim Bauen gestellt hat.

Vielleicht kennst du die Situation aus der anderen Richtung: Erst ist da die externe Anforderung – ein Audit, eine Klausel, eine Aufsichtsbehörde –, und dann beginnt die Suche, wie man sie erfüllt. Bei FastChangeCo lief es umgekehrt. Das Fundament war zuerst da, die Anforderung kam danach. Welcher der beiden Wege dir bevorsteht, hängt vor allem davon ab, wann du anfängst.

Sylvia unterschreibt am Ende. Bevor sie die Mappe zumacht, sagt sie nur einen Satz, halb zu Michael, halb zu sich: „Wir mussten dafür nichts Neues anfangen." Mehr Pointe braucht es nicht.

Sobald die strategische Entscheidung gefallen ist, bringt das Temporal Data Training euer Team in zwei bis vier Tagen auf den nötigen Wissensstand – auch in-house.

So long,
Dirk