Änderungshistorie

In der Praxis scheitert Audit-Compliance oft nicht am Willen, sondern an der Architektur. Protokolle werden nachträglich in Systeme integriert, decken nur bestimmte Felder ab oder lassen sich im Nachhinein manipulieren. Das Ergebnis: Prüfer fragen nach einer Datenänderung vom letzten Quartal, und die Antwort lautet „wir müssen das erst recherchieren." Die Änderungshistorie der omniSuite macht dieses Problem strukturell unmöglich. Historisierung ist keine Funktion, die aktiviert wird – sie ist konfigurierbare Architektur, die automatisch greift.

Nicht jede Änderung an jedem Attribut ist gleich relevant. Operative Felder brauchen eine andere Protokolltiefe als finanzrelevante oder personenbezogene Daten. Die Änderungshistorie erlaubt es, pro Attribut und pro Operation zu definieren, wann historisiert wird – bei Anlage, Änderung oder Löschung, oder bei bestimmten Kombinationen davon. Das verhindert Datenmüll in der Historientabelle und schärft den Fokus auf das, was für Compliance und Analyse tatsächlich zählt.

Für regulierte Branchen oder sensible Datenbereiche können separate Historientabellen mit eigenem Zugriffsschutz angelegt werden. Wer die Änderungshistorie eines Vertragsfeldes einsehen darf, ist nicht automatisch berechtigt, die Historientabelle für Gehaltsattribute zu sehen. Diese Trennung nach Datentyp und Zugriffsebene ist keine IT-Entscheidung – sie ist eine Compliance-Entscheidung, die direkt in der Plattform umgesetzt wird.

Zustand rekonstruierbar machen ist mehr als eine Audit-Anforderung – es ist eine analytische Ressource. Wann hat sich ein Kundenstatus geändert? Welche Attributänderungen gingen einer Eskalation voraus? Aus welchen Wertentwicklungen lassen sich Muster ableiten? Die Historientabellen der omniSuite sind vollwertige Datenobjekte, die sich wie reguläre Tabellen abfragen, filtern und für Berichte nutzen lassen. Die Grundlage für KI-gestützte Analysen entsteht damit als Nebenprodukt des laufenden Betriebs.

Historientabellen können zentral oder direkt aus der Tabellendefinition heraus angelegt werden. Der Entwickler wählt das Informationsobjekt, legt die zu historisierenden Attribute fest und definiert, bei welcher CRUD-Operation – Create, Update oder Delete – ein Historieneintrag erzeugt wird. Alter und neuer Wert sind wahlweise speicherbar. Nach der Konfiguration generiert das System automatisch die Historientabelle und die zugehörigen Datenbank-Trigger. Eine Vorschau zeigt die Tabellenstruktur vor dem finalen Speichern.

Attribute können nachträglich hinzugefügt oder aus der Historisierung ausgeschlossen werden. Das System passt Tabellenstruktur und Trigger dabei automatisch an – ohne manuellen Eingriff auf Datenbankebene. Pro Informationsobjekt sind mehrere Historientabellen anlegbar, etwa eine für operative Felder und eine für finanzkritische Attribute. Jede Historientabelle kann einer Systemobjekt-Gruppe zugeordnet werden und hat eine eigene Änderungsdokumentation.

Die Änderungshistorie folgt Event-Sourcing-Prinzipien: Jede Änderung wird als eigenständiges Ereignis gespeichert, mit Zeitstempel, altem Wert, neuem Wert und Auslöser – entweder einer User-ID oder dem Kennzeichen „System" für automatisierte Aktionen. Der Zustand eines Datensatzes ist damit zu jedem vergangenen Zeitpunkt vollständig rekonstruierbar. Die Daten sind nicht nachträglich veränderbar, was die Auditfähigkeit strukturell absichert.

Wenn Änderungsarten sich klar unterscheiden – operativ versus finanziell, intern versus regulatorisch – verbessert die Aufteilung auf separate Historientabellen sowohl die Abfrageperformance als auch die Zugriffssteuerung. Wachsendes Datenvolumen lässt sich durch diese Trennung gezielt skalieren. Für spezielle Auswertungen oder Compliance-Berichte stehen die Historientabellen mit denselben Abfrage- und Filtermechanismen wie reguläre Tabellen zur Verfügung.