Ein Kunde bestreitet einen Preis, den er vor zwei Jahren zugesagt bekommen hat. Ein Prüfer fragt, wie ein Datensatz zum Stichtag der letzten Bilanz aussah und wer ihn zuletzt geändert hat. Mit einem klassischen Change-Log wird daraus schnell ein Ein-Tages-Projekt: Log-Einträge sind Rohdaten, kein abfragbarer Datenbestand von damals – jemand muss sie von Hand rückwärts zusammensetzen. Ein separates Audit-Log oder Data-Warehouse-Snapshots lösen das nicht, sie verschieben es nur: durchsuchbar, aber kein Formular, kein Report, kein System, das man einfach zu einem Stichtag befragen kann – dafür aber ein weiteres System, das betrieben und abgesichert werden muss.

Ein Lösungsansatz aus der Praxis

Yoonite baut das nicht nach, sondern führt es von Anfang an mit: Jede Tabelle speichert automatisch, wann welcher Stand galt und wer ihn erzeugt hat – bei jedem Anlegen, Ändern und Löschen, ohne dass eine Anwendung das explizit programmieren müsste. Der Stichtag wird nicht in jeder einzelnen Abfrage mitgegeben, sondern einmal beim Öffnen der Sitzung – ab dann sieht die gesamte Sitzung automatisch den Stand von damals:

Sitzung mit dem gewünschten Stichtag öffnen

SELECT auth.init_session(‘pruefer’, ‘2024-03-31 23:59:59’);

Ganz normale Abfrage auf die Items-Tabelle – liefert ab jetzt automatisch den damaligen Stand

SELECT CI_KEY, CI_NAME FROM V_CI_ITEM WHERE CI_KEY = ‘SRV-4711’;

Und liefert damit exakt den Datenstand von damals – dieselben Formulare, dieselben Auswertungen, nur zu einem früheren Zeitpunkt. Keine Rekonstruktion, keine Rückfrage an die IT: Die Antwort steht in Sekunden statt Tagen.

Für IT-Entscheider zählt vor allem der Umfang: Historisiert werden nicht nur Fachdaten, sondern auch Beziehungen, Konfigurationen, Formulare, Prozesse und Berechtigungen – weil auch die Plattformkonfiguration selbst ganz normal in denselben Tabellen liegt. Ein Rollback einer Formularänderung ist deshalb keine Migration, sondern eine Zeitreise. Und weil Ersteller, letzter Bearbeiter und letzter Prüfer inklusive Zeitstempel automatisch mitgeführt werden, entfällt jedes Sonderprojekt für Nachweispflichten und jedes zusätzliche System für Auditfähigkeit. Genau das macht Historisierung in regulierten Branchen zur Risikofrage, nicht zur Komfortfrage: Versicherungen müssen Entscheidungen nach Jahrzehnten erklären, Banken ihre Governance nachweisen, Industrieunternehmen Änderungen an Fertigungsdaten zurückverfolgen können. Wer das nachträglich um eine bestehende Anwendung herumbaut, zahlt doppelt – für das Zusatzsystem, und im Zweifel für zwei Wahrheiten, die auseinanderlaufen.

Nicht jede Anwendung braucht das: Für reine Zwischenergebnisse oder kurzlebige Sitzungsdaten ist vollständige Historisierung unnötiger Overhead ohne je abgerufenen Mehrwert. Ihren Wert zeigt der Ansatz genau dort, wo nicht nur “wie ist der Stand heute”, sondern “wie war der Stand damals, und wer hat das verändert” gefragt wird – und dort ist er nicht nachträglich einzubauen, sondern von Anfang an Teil der Plattform.

Selbst ausprobieren

Die Kernplattform von Yoonite steht als kostenlose SaaS-Lite-Version bereit – ohne Fachmodule, aber mit Zeitreise für Ihre generischen Daten: Sie können selbst ausprobieren, wie sich ein Datenstand zu einem früheren Zeitpunkt abfragen lässt. Nicht enthalten ist die Zeitreise für die Konfiguration selbst (Formulare, Menüs, Metamodell) – die gehört zum vollen Implementierungsprojekt.