State Tracking Engine

Jedes Geschäftsobjekt durchläuft Zustände: ein Antrag wird eingereicht, geprüft, genehmigt oder abgelehnt. Ein Equipment wird in Betrieb genommen, gewartet, außer Betrieb gesetzt. In vielen Systemen ist nur der aktuelle Wert gespeichert. Wann der Wechsel stattfand, wer ihn ausgelöst hat und was der vorherige Zustand war, lässt sich nicht rekonstruieren. Genau diese Lücke wird in Audits, bei Eskalationen und bei der Fehlersuche zum Problem.

Die State Tracking Engine dokumentiert jeden Zustandswechsel als eigenständiges Ereignis und kann automatisch Folgeereignisse auslösen. Statt nachträglich Protokolle zusammenzusuchen, entsteht eine vollständige Zustandshistorie als Nebenprodukt des normalen Betriebs.

In der Praxis haben Geschäftsobjekte mehrere unabhängige Zustandsaspekte gleichzeitig. Ein Gerät hat einen Lebenszyklus-Zustand (aktiv, in Wartung, dekommissioniert), einen Ausfallstatus (funktionsfähig, eingeschränkt, ausgefallen) und einen Bearbeitungsstatus (offen, in Prüfung, abgeschlossen). Wer das in ein einziges Statusfeld presst, verliert entweder Information oder baut fragile Workarounds.

Die State Tracking Engine führt diese Dimensionen als separate Zustandstabellen mit jeweils eigenen Regeln, Berechtigungen und Eskalationslogiken. Jede Dimension entwickelt sich unabhängig. Das Ergebnis: Zustandsinformationen bleiben vollständig und auswertbar, ohne dass ein Feld das andere überschreibt.

Wenn im Audit jemand fragt, wann und warum ein Status gewechselt hat, fehlt in vielen Systemen die Antwort. Entweder existiert kein Protokoll, oder es muss mühsam aus Logfiles rekonstruiert werden. Das kostet Zeit und birgt das Risiko unvollständiger Nachweise.

Die State Tracking Engine speichert jeden Zustandswechsel als eigenständiges Ereignis, mit altem Zustand, neuem Zustand, Zeitpunkt und Auslöser. Diese Daten sind nicht nachträglich veränderbar. Die konfigurierbare Option, auch unveränderte Zustände zu protokollieren, schließt die Lücke für Fälle, in denen ein Bearbeitungsvorgang stattfand, aber keine Statusänderung auslöste. Im Audit liefern Sie die Antwort in Sekunden, jede Statusänderung ist jederzeit nachweisbar.

KI-Agenten können nur so gut entscheiden, wie die Datenbasis es zulässt. Wenn Zustandsverläufe fehlen oder lückenhaft sind, fehlt der Kontext für automatisierte Entscheidungen. Das betrifft sowohl Muster-Erkennung als auch Anomalie-Detektion.

Die vollständige Zustandshistorie liefert genau das, was KI-Agenten brauchen: Kontextverständnis (was ist bisher passiert), Entscheidungsgrundlage (welche Muster führen zu welchen Ergebnissen) und Trainingsdaten (welche Zustandsabfolgen sind typisch, welche anomal). Unternehmen, die die State Tracking Engine nutzen, bauen diese strukturierte Datenbasis automatisch auf, ohne separates Datenerfassungsprojekt.

Zustandstabellen können zentral oder direkt aus der Tabellendefinition heraus erstellt werden. Der Entwickler wählt das Informationsobjekt, definiert das relevante Attribut (Auswahlfeld) oder den Fremdschlüssel, der auf die Tabelle mit den möglichen Zuständen verweist, und legt fest, ob alter und neuer Zustand gespeichert werden sollen.

Jede Zustandstabelle erhält eine eindeutige Bezeichnung und Beschreibung. Nach dem Speichern generiert das System automatisch die Zustands-Tabelle und die zugehörigen Trigger für CRUD-Operationen. Eine Vorschau zeigt die Tabellenstruktur vor der finalen Erstellung.

Für spezifische Zustände können Ereignisse definiert werden, die ausgelöst werden bei: bestimmten Zustandsübergangskombinationen (alter und neuer Zustand), bestimmten neuen Zuständen (unabhängig vom Übergang) oder bestimmten alten Zuständen (unabhängig vom Übergang). Zwei Ereignistypen sind verfügbar: Löschen von Beziehungen: mit der Option, bestimmte Beziehungen vom Löschen auszunehmen.

Ausführung gespeicherter SQL-Prozeduren: mit Parameterübergabe und Zugriff auf Assistenten und Code-Vorlagen.

Über den Reiter „Weitere Einstellungen" oder über tabellenabhängige Maskeneinstellungen kann festgelegt werden, dass auch bei unverändertem Status ein Eintrag in die Life-Cycle-Tabelle erfolgt. Die Steuerung kann regelbasiert über SQL-Skripte erfolgen. Diese Funktion stellt sicher, dass Bearbeitungsvorgänge auch dann dokumentiert werden, wenn sie keine Statusänderung auslösen, relevant für vollständige Audit-Trails.

Neue Zustandstabellen können jederzeit erstellt werden. Bestehende Konfigurationen, einschließlich Zustandsdefinitionen, Event-Handling und Trigger, können jederzeit angepasst werden. Nach jeder Änderung passt das System die Tabellenstruktur und Trigger automatisch an.

Die gesamte Generierung erfolgt automatisiert. Entwickler müssen keine manuellen Skripte für die Zustandstabellen-Infrastruktur erstellen.

Jede Zustandstabelle kann einer Systemobjekt-Gruppe zugeordnet werden. Alle Anpassungen werden in der Änderungsdokumentation festgehalten, dauerhaft und nachvollziehbar, mit Versionskontrolle und Rückverfolgbarkeit. Das ist besonders relevant für die Zusammenarbeit im Entwicklerteam und für Audit-Anforderungen.