Policy-Architektur: Regelbasierte Steuerung statt starrer Workflows

Die Policy-Architektur ist das Betriebssystem der Digitalisierung innerhalb der omniSuite. Anstatt Geschäftslogik in unzähligen Codezeilen, Triggern oder starren Workflows zu verstreuen, werden alle steuerungsrelevanten Regeln zentral, formal beschrieben und konfigurierbar definiert.

Komplexität wird reduziert, die Wartbarkeit erhöht und fachliche Änderungen lassen sich systemweit konsistent ausrollen, ohne das Gesamtsystem zu destabilisieren. Jede Regel gilt kanalübergreifend — ob UI, API oder Datenimport. Eine einmal definierte Geschäftsregel wird an jedem Enforcement-Gate identisch durchgesetzt, ohne mehrfach implementiert zu werden.

Klassische Modellierung ist statisch — sie zeichnet Pfade vor, die bei jeder Ausnahme angepasst werden müssen. Das führt bei wachsender Komplexität zur sogenannten Pfadexplosion: Jeder Sonderfall benötigt einen eigenen gezeichneten Weg. omniSuite nutzt stattdessen mehrdimensionale Prozesslogik.

Entscheidungen werden situativ aus dem konkreten Datenkontext, dem Zustand von Objekten und dem Zeitpunkt abgeleitet. Das macht Prozesse hochgradig flexibel und gleichzeitig präzise steuerbar, da das System zur Laufzeit entscheidet, was jetzt erlaubt oder geboten ist — nicht ein vorab gezeichneter Pfad.

Regeln werden in der omniSuite nicht isoliert bewertet, sondern innerhalb eines Koordinatensystems aus Kontext, Zustand und Zeit (CST-Prinzip). Eine Regel prüft nicht nur, ob ein Feld ausgefüllt ist, sondern ob es für diesen Benutzer in dieser Rolle bei diesem Bearbeitungsstatus zu diesem Zeitpunkt (z.

B. vor Ablauf einer Frist) zwingend erforderlich ist. Das CST-Prinzip stellt sicher, dass jede Steuerungsentscheidung ein stetig aktualisiertes Urteil ist — basierend auf den drei Achsen Kontext, Zustand und Zeit.

Die omniSuite nutzt eine mehrschichtige Architektur aus sechs gleichwertigen Policy-Familien, die wie Zahnräder ineinandergreifen:

State Management Policies steuern zulässige Zustandsübergänge und Guard-Conditions. Historisierung Policies sichern die lückenlose, revisionssichere Dokumentation. Correlation & Derivation Policies (ACE) leiten Folgeaktionen über Objektgrenzen hinweg ab.

Data & Relationship Policies erzwingen Datenqualität und korrekte Kardinalitäten. Data Reconciliation Policies sichern die systemübergreifende Konsistenz. Authorization & Access Policies regeln feingranulare Zugriffsrechte kontextabhängig.

Alle sechs Policy-Sets sind vollständig integriert und arbeiten bei jeder Transaktion zusammen. Kein Set ist optional — jedes adressiert eine eigenständige Steuerungsdimension.

Qualität ist in der omniSuite kein nachträglicher Prüfprozess, sondern durch blockierende Pre-Gates konstruktiv integriert. Regeln prüfen Daten bereits vor dem Speichern oder einem Statuswechsel auf Vollständigkeit, Plausibilität und Integrität. So wird verhindert, dass inkonsistente Zustände überhaupt entstehen können.

Die Steuerung auf Datenebene arbeitet dabei mit drei konkreten Kriterientypen: Festvorgegebene Werte (ein Feld ist nur bearbeitbar, wenn ein anderes Feld einen bestimmten Wert enthält), Auswahlfelder (die Bearbeitbarkeit wird durch die vom Benutzer getroffene Auswahl gesteuert) und 1:N-Ausprägungen (Regeln können an konkrete Datensätze in verknüpften Tabellen geknüpft werden). Diese Regeln greifen automatisch, sobald eine Maske geladen wird — unabhängig davon, welche Benutzeroberfläche verwendet wird.

Jede Regel folgt der formalen Grammatik Event — Condition — Action (Ereignis — Bedingung — Aktion). Event ist ein messbarer Auslöser (z. B. Speicherversuch, Zeitablauf). Condition ist eine fachliche Prüfung basierend auf realen Systemwerten (nicht nur flüchtigen UI-Eingaben).

Action ist die durchzusetzende Systemreaktion (z. B. Status setzen, Feld sperren, Benachrichtigung auslösen). Diese formale Struktur ist maschinenlesbar und bildet die Grundlage dafür, dass Entscheidungen nachvollziehbar, testbar und zukunftssicher dokumentiert sind.

Das Berechtigungskonzept der omniSuite arbeitet auf vier klar definierten Ebenen, die flexibel kombiniert werden können:

Rollen (RBAC): Berechtigungen werden anhand von Rollen vergeben. Rollen bündeln bestimmte Zugriffsrechte und können mehreren Benutzern zugewiesen werden. Änderungen an einer Rolle wirken automatisch auf alle zugeordneten Benutzer.

Organisationseinheiten: Berechtigungen können nach Abteilungen oder Teams vergeben werden. Benutzer einer Organisationseinheit erhalten gemeinsame Zugriffsrechte für relevante Funktionen und Daten.

Partnerfirmen: Externe Partner erhalten eigene Berechtigungen, um den Zugriff auf ausgewählte Systemobjekte gezielt zu steuern und gleichzeitig die Zusammenarbeit zu ermöglichen.

Individuelle Benutzer: Neben den gruppenbasierten Berechtigungen können spezielle Rechte auf individueller Benutzerebene zugewiesen werden, was eine besonders feingranulare Steuerung ermöglicht.

Berechtigungen werden innerhalb von Rollen und Organisationseinheiten automatisch vererbt, sodass Benutzer die Rechte ihrer zugeordneten Gruppen erhalten. Entscheidend: Vererbte Rechte können individuell überschrieben werden. Das ermöglicht es, standardisierte Rechteprofile zu nutzen und gleichzeitig Ausnahmen für einzelne Benutzer oder Situationen zu definieren — ohne das Gesamtkonzept zu untergraben.

Für Ausnahmesituationen bietet die omniSuite temporäre, einmalige Berechtigungen. Ein Benutzer kann gezielt Zugriff auf eine bestimmte Maske für definierte Aktionen erhalten, ohne dass eine dauerhafte Anpassung der Berechtigungsstruktur nötig ist. Die temporäre Berechtigung wird automatisiert gesetzt und erlischt nach Verwendung. Das reduziert das Risiko dauerhaft überprivilegierter Konten und ermöglicht gleichzeitig die fachlich notwendige Flexibilität.

Über die klassische Rollenvergabe hinaus bietet die omniSuite ein regelbasiertes Berechtigungsmodul, das RBAC, PBAC und ABAC kombiniert. Berechtigungen können auf Basis von Objektattributen, Zuständen, Benutzerrollen, Partnerfirmen und beliebigen Kombinationen dieser Faktoren dynamisch vergeben werden. So lässt sich beispielsweise der Zugriff auf einen bestimmten Kunden nach Kundennummer, Rolle und aktuellem Bearbeitungsstatus steuern — ohne individuelle Programmierung.

Die State Management Policies definieren zulässige Zustände und die Bedingungen für Übergänge (Guard Conditions). Pro Informationsobjekt können mehrere Zustandstabellen angelegt werden, die unterschiedliche Aspekte abbilden — etwa Lebenszyklus, Ausfallstatus oder Bearbeitungsstatus.

Jeder Zustandswechsel wird als Ereignis erfasst und in der jeweiligen Zustandstabelle dokumentiert. Das System verhindert so, dass ein Objekt in widersprüchliche Situationen geraten kann: Eine Maschine kann nicht gleichzeitig „gesperrt" und „zur Freigabe bereit" sein, wenn die Statuslogik dies ausschließt.

Durch das Zusammenspiel von State-Tracking und Historisierungs-Policies wird nicht nur gespeichert, was geändert wurde, sondern auch, warum das System eine Entscheidung getroffen hat. Jede Aktion lässt sich auf die zugrunde liegende Regel, den damaligen Datenkontext und den Zeitpunkt zurückführen.

Das Modul erfasst dabei auch Änderungen ohne Zustandswechsel — es wird also dokumentiert, wenn ein Objekt bearbeitet wurde, ohne dass sich sein Status ändert. Zustandswechsel können zudem automatisch Folgeereignisse auslösen: Benachrichtigungen, das Löschen von Beziehungen oder den Start nachgelagerter Prozesse. Das erfüllt höchste Compliance-Anforderungen und macht Audits effizient.

Builder müssen technische Standardmechanismen wie Statusabsicherungen oder kontextabhängige Pflichtfelder nicht mehr individuell programmieren (Boilerplate-Code). Sie nutzen stattdessen die zentrale Policy-Infrastruktur und konzentrieren sich ausschließlich auf die Abbildung der fachlichen Logik.

Das reduziert die Entwicklungszeit massiv und minimiert das Risiko für technische Schulden. Gleichzeitig bietet die Plattform lückenlose Datenverwendungs-Transparenz: Für jedes Attribut oder jede Policy lässt sich auf Knopfdruck sehen, in welchen Masken, APIs oder Triggern sie verwendet wird.

Da Regeln zentral gepflegt werden, müssen bei neuen Vorgaben keine Workflows neu gezeichnet oder Formularskripte an Dutzenden Stellen geändert werden. Die Anpassung einer zentralen Policy wirkt sofort systemweit an allen Enforcement-Gates (UI, API, Import). Der integrierte Data Integrity Deployment Cycle (DIDC) stellt dabei sicher, dass Änderungen vorab auf Abhängigkeiten geprüft und kontrolliert ausgerollt werden. Das System erkennt, ob eine Policy-Änderung zu Fehlern in anderen Prozeduren oder Masken führen würde, und verhindert riskante Deployments.

Ja. Die klare, formale Beschreibung aller Fachlogiken in maschinenlesbaren Regeln ist die notwendige Grundlage für KI-Integration. KI-Agenten können diese Regeln verstehen, validieren und für Optimierungen nutzen. Eine Prognose wird in der omniSuite somit nicht zur unkontrollierbaren Black Box, sondern zu einem transparenten Eingangswert für bestehende Policies.

Da alle Regeln und Abhängigkeiten formal beschrieben vorliegen, bildet dies das Fundament, um Prozesse künftig durch KI-Agenten optimieren oder automatisiert testen zu lassen.

Durch das integrierte State-Tracking und die Historisierungs-Policies wird nicht nur gespeichert, was geändert wurde, sondern auch, warum das System eine Entscheidung getroffen hat. Traces halten fest, welche Regel zum Zeitpunkt T unter welchen Bedingungen (CST) gegriffen hat.

Die Änderungsdokumentation umfasst dabei alle Anpassungen an Zustandstabellen und ist dauerhaft nachvollziehbar — jede Version, jede Modifikation. Das erfüllt höchste regulatorische Anforderungen und macht Audits effizient.