Teil 2 endete mit einem Satz von Diego: „Zeitreisen gehen auch vorwärts. Rückwirkende Buchungen, geplante Preise, Szenarien für die Zukunft." Genau da steigen wir jetzt ein.

Mit den zwei Zeitlinien aus Teil 2 lassen sich plötzlich drei verschiedene Fragen sauber beantworten, die im Daten-Alltag permanent durcheinandergehen: Was wird gelten? Was galt damals? Was wussten wir damals? Drei Fragen, die ohne diese Trennung kollidieren – mit ihr drei klare Antworten haben.

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

Dieser Artikel ist Teil 3 einer vierteiligen Serie über bitemporale Daten in der Praxis. Er bündelt zwei der acht Gründe aus dem Hub-Artikel „8 Gründe, warum man bitemporale Daten benötigt": die Realität für Vergangenheit, Gegenwart und Zukunft zu speichern – und rückwirkende Operationen sauber abzubilden.

Die Kernthese: Sobald die zwei Zeitlinien stehen, beantwortet Bitemporalität drei Geschäftsfragen, die im Daten-Alltag permanent durcheinandergehen – über Vergangenheit, Gegenwart und Zukunft hinweg.

Bei FastChangeCo fängt es mit einer Planungsrunde an. Philomena Pavlovic, Business Analyst, sitzt mit Marketing über dem Aktionsplan für Black Friday. Fünf Preisaktionen sollen am 28. November um 0 Uhr automatisch aktiv werden – und am 2. Dezember um 0 Uhr wieder zurück auf den Normalpreis. „Wie tragen wir das ein", fragt sie ins Team, „ohne dass irgendwer um Mitternacht manuell SQL-Updates klopft?"

Yerodin van Dusseldorp, Controller, runzelt die Stirn. „Und mein Forecast-vs-Ist-Vergleich – der bricht doch sofort, wenn die Preisbasis sich automatisch verschiebt. Wenn ich Ende Dezember zurückschaue, sehe ich dann die Aktion oder den Normalpreis? Und gegen welchen vergleiche ich meinen Forecast?"

Amal Leyla Qasim, Data Modeler im Team, schaut auf das Whiteboard von vorletzter Woche. Da stehen noch die zwei Zeitlinien aus dem Meeting zu Teil 2 – Assertion und State. „Wir haben das Werkzeug doch schon", sagt sie. „Wir nutzen es bisher nur in eine Richtung."

Philomena schaut hoch. „In eine Richtung?" Amal greift zum Stift.

Drei Fragen, eine Mechanik

Aus Teil 2 stehen zwei Zeitlinien fest. Die Assertion Timeline (technisch) hält fest, wann wir von einem Wert erfahren haben. Die State Timeline (fachlich) hält fest, ab wann er in der Realität gilt. Zwei Achsen, jede mit ihrer eigenen Frage.

Amal zeichnet die State Timeline als horizontale Linie auf das Whiteboard. „Was wir bisher übersehen haben: Diese Linie kennt keine eingebaute Richtung. ‚Jetzt' ist nur ein Wert auf einer Achse, die sich genauso in die Zukunft erstreckt wie in die Vergangenheit. Sobald du das siehst, ändert sich der Werkzeugkasten."

Drei Fragen werden dann lösbar, die ohne zwei Zeitlinien zwangsläufig kollidieren:

As-Is – Was gilt? Nicht: was gilt jetzt. Der heutige Zustand ist nur ein Spezialfall – die Frage funktioniert für jeden Punkt der State Timeline.

As-Was – Was galt damals fachlich, auch wenn wir es erst später wussten?

As-Of – Was wussten wir damals?

„Mit zwei Zeitlinien drei verschiedene Antworten", sagt Amal. „Ohne sie kollidieren die Fragen, und das ganze Team rätselt, warum der Report von gestern heute anders aussieht."

Drei Beispiele aus dem Tagesgeschäft warten auf Antworten: Black Friday, der Tarifabschluss, Yerodins Forecast-Vergleich. Eines pro Frage.

Zukunft: Geplante Preise

Erste Frage: Was wird gelten? Philomenas Black-Friday-Planung lebt davon, dass diese Frage auch auf Daten in der Zukunft anwendbar sein muss.

Konkret trägt Philomena heute fünf Datensätze ein – einen pro geplanter Aktion. Inscription Timestamp: jetzt – damit ist klar, wann wir die Preise als verbindlich verbucht haben. State Timestamp: ab 28. November um 0 Uhr – damit ist klar, ab wann sie fachlich gelten. Zwei Zeitstempel, ein Datensatz, kein Konflikt.

Was am 28. November um 0 Uhr technisch passiert? Nichts. Der Datensatz steht schon im System, er wird einfach fachlich gültig. Keine Cronjobs, keine Mitternacht-SQLs, kein Marketing-Praktikant, der wach bleibt. Genau das Spiegelbild gilt am 2. Dezember um 0 Uhr: Ein zweiter, ebenfalls vorher eingetragener Datensatz wird gültig und löst den Black-Friday-Preis ab.

Amal an Yerodin: „Und wenn jemand am 30. November fragt 'was war der Preis am 1. November' – die Aktionen ändern daran nichts, weil sie auf einer anderen Stelle der Zeitachse liegen. Die fachliche Gültigkeit zum 1. November ist unabhängig davon, was später kommt."

Der praktische Effekt ist nicht klein. Marketing plant heute, das System löst zur richtigen Zeit aus. Pricing-Teams müssen keine Aktivierungs-Listen mehr pflegen, Operations keine Mitternacht-Cronjobs scharfschalten, und der Übergang in den Sale verläuft so leise wie das Tickwerk einer Uhr. Philomenas Reaktion ist trocken: „Endlich kann ich nach Hause gehen und schlafen, bevor die Aktion losgeht."

Im Hub-Artikel ist das der Grund „Die Realität für Vergangenheit, Gegenwart und Zukunft speichern". Wer Preise in die Zukunft plant, beantwortet eine As-Is-Frage – allerdings für einen Zeitpunkt, der heute noch nicht da ist.

Vergangenheit: Rückwirkende Buchungen

Zweite Frage: Was galt damals fachlich – auch wenn wir es erst später wussten? Die rückwirkende Tarifbuchung lebt von genau dieser Trennung.

Tarifabschluss am 15. Oktober. Die Gehaltserhöhung gilt rückwirkend ab dem 1. Juli. Klassisch, ohne bitemporale Historisierung, würde HR jetzt die Werte aktualisieren – und der historische Q3-Report zeigt ab sofort höhere Gehälter, als hätten sie schon im Juli gegolten. Der Stand vom Q3-Abschluss ist damit verloren.

Bitemporal trennt es sauber. Ein neuer Datensatz wird angelegt: State Timestamp = ab 1. Juli (wann er fachlich gilt), Inscription Timestamp = 15. Oktober (wann wir es wussten). Beide Stände existieren in der Tabelle nebeneinander – der ursprüngliche Q3-Stand bleibt unangetastet auf der Assertion Timeline, der korrigierte Wert ist über die State Timeline ab dem 1. Juli wirksam.

Das ist die As-Was-Frage. Was galt fachlich am 1. Juli? Ab dem 15. Oktober wissen wir die Antwort – aber sie war auch am 1. Juli schon die richtige Antwort. Wir haben es nur noch nicht gewusst.

Yerodin sieht es sofort: „Mein Q3-Report bleibt stabil. Und trotzdem stimmt der aktuelle Datenstand." Genau das ist der Punkt. Die Vergangenheit kann fachlich korrekt nachgezogen werden, ohne dass historische Reports umgeschrieben werden müssen.

Dasselbe Muster trägt für jede rückwirkende Operation. Die Rechnung kommt am 4. eines Monats und muss noch in den Vormonat gebucht werden – State Timestamp im Vormonat, Inscription Timestamp im aktuellen Monat. Im Hub-Artikel ist das der Grund „Rückwirkende Operationen", und es ist derselbe Werkzeugkasten, der auch die Tarifänderung trägt.

Gegenwart: Stabile Reports trotz beweglicher Welt

Dritte Frage: Was wussten wir damals? Hier wird Yerodins Skeptiker-Frage aus dem Anfang des Meetings eingelöst.

Yerodins eigentliche Sorge nochmal scharfgestellt: Sobald HR rückwirkend auf der State Timeline bucht, verschiebt sich potenziell jeder historische Report. Sein Forecast-vs-Ist-Vergleich vom Q3-Abschluss zeigte damals bestimmte Gehaltszahlen. Wenn diese Zahlen sich rückwirkend ändern, wackelt seine ganze Forecast-Genauigkeit.

Amal: „Du fragst eine andere Sache, als du denkst. Dein Forecast wurde mit dem damaligen Wissensstand erstellt. Die richtige Frage ist nicht ‚was war damals fachlich richtig' – das ist die As-Was-Sicht. Die richtige Frage ist ‚was wussten wir, als der Report entstand?'"

Das ist die As-Of-Frage – und die zugehörige Mechanik ist einfach. As-Of schneidet die Assertion Timeline an einem vergangenen Datum ab. Alles, was wir erst danach erfahren haben, bleibt für diese Abfrage unsichtbar. Yerodins Forecast-Vergleich zieht damit denselben Datenstand, den er auch beim Q3-Abschluss gezogen hat – egal, was HR seither im System nachgezogen hat.

Yerodin nickt langsam. „Also bleibt mein Forecast-vs-Ist-Vergleich stabil, selbst wenn HR die Vergangenheit über die State Timeline neu sortiert. Die zwei Zeitlinien sind kein zusätzlicher Komfort. Sie sind die Voraussetzung, damit ‚damals' überhaupt eindeutig ist."

Erst die Trennung der beiden Zeitlinien macht „damals" zu zwei verschiedenen Fragen.

Was-wäre-wenn: Zeitreisen für Szenarien

Es gibt eine Erweiterung, die in Planungsgesprächen oft kommt – und im FastChangeCo-Meeting bringt Philomena sie ebenfalls auf: Nicht jede Zeitreise muss „real" sein. Manche Szenarien sind hypothetisch.

„Was wäre, wenn wir Kostenstellen anders zuschneiden würden – wie sähe der Umsatz mit einer neuen Org-Struktur aus? Oder ein zweiter Forecast neben dem offiziellen, der eine andere Annahme über die Auslastung trifft. Können wir sowas auch?"

Amal: „Das ist nichts anderes als ein Datensatz mit einem State Timestamp in der Zukunft, der bewusst nie aktiviert wird. Ein Szenario-Stand neben dem Echt-Stand – auf derselben Tabelle, mit demselben Werkzeug."

Yerodin hängt sich gleich an: „Und ich kann Forecasts in mehreren Versionen nebeneinander pflegen, ohne dass sich die Versionen gegenseitig überschreiben. Jede Version mit ihrem eigenen State-Timestamp-Korridor – einsehbar, vergleichbar, prüfbar."

Das ist nicht der Kern dieses Artikels – aber es zeigt, wie weit der Werkzeugkasten trägt, sobald die zwei Zeitlinien sauber stehen.

Black Friday, rückwirkende Gehaltsänderungen, geplante Vertragsanpassungen – alles Beispiele, bei denen ich mit Teams in der Praxis arbeite. Die fachliche Mechanik ist meist klar – aber der Schritt von „aktueller Zustand" zu „modellierter Realität über Zeit" verläuft selten ohne ein paar steile Stellen.

Vom Schmerz zur Methode

Was die drei aus dem Meeting mitnehmen, sieht aus wie ein verteilter Gewinn. Philomena: Marketing plant Preise heute, das System löst sie zur richtigen Zeit selbst aus. Yerodin: historische Reports bleiben stabil, auch wenn HR die Vergangenheit nachzieht. Amal: dieselbe Mechanik aus Teil 2 trägt für alles – einmal richtig gebaut, dann nach allen drei Seiten nutzbar. Drei Probleme, ein Werkzeug, drei zufriedene Stimmen im Meeting-Raum.

Drei Fragen, die im Daten-Alltag ständig durcheinandergehen – As-Is, As-Was, As-Of – und mit zwei Zeitlinien plötzlich drei klare Antworten haben. Mehr ist es nicht. Und gleichzeitig ist es genau das.

Bitemporal ist nicht ein Werkzeug, um Vergangenes zu korrigieren – es ist ein Werkzeug, um Zeit überhaupt erst als planbare Achse zu behandeln.

Bis hierhin war alles fachliche Anwendung. Drei Geschäftsfragen, drei klare Antworten, drei Beispiele aus dem Tagesgeschäft. Aber wer fragt eigentlich, ob ihr das nachweisen könnt – wenn die BaFin morgen kommt und wissen will, warum der Q3-Report so aussah, wie er aussah? Die Argumentation, die das Management überzeugt, kommt im letzten Teil dieser Serie.

Wer das Konzept erst mal solide lernen will, bevor das eigene Projekt startet: das Temporal Data Training ist ab Mai 2026 wieder verfügbar.

So long,
Dirk