S•U•S•I - Qualitätsmanagement für immoSoR

Ebene 1 · Freiwilliger Tagesstart

Die erste Ebene ist der kurze, nutzerbezogene Tagescheck. Sie begleitet den Beginn oder die bewusste Aufnahme des Arbeitstages und bezieht sich auf den aktuellen Kontext aus Nutzer, Mandant, Rolle, Sitzung, App-Version und Funktionsregister-Version. Geprüft werden ausschließlich die für den Tag wesentlichen Arbeits- und Schutzfunktionen. Der Tagescheck ist damit eine gezielte Betriebsbereitschaftsprüfung und keine vollständige technische Tiefenprüfung.

Typischer Auslöser ist der erste Login des Tages. Ein Lauf kann außerdem manuell gestartet oder durch einen echten Rollen- oder Mandantenwechsel, eine relevante Versionsänderung, einen veralteten Tageszustand oder einen ausdrücklich gewünschten Wiederholungstest begründet werden. Ein bloßer Seitenwechsel löst keinen neuen Tageslauf aus. Bereits gültige Tageszustände werden wiederverwendet, und parallele oder doppelte Läufe werden verhindert.

Der Nutzer entscheidet selbst, ob er den Tagescheck startet. Er kann den Test sofort ausführen, sich später erinnern lassen oder die Einladung für den Tag ausblenden. Eine Verschiebung oder Ablehnung erzeugt keinen negativen Nutzerstatus, sperrt nicht den allgemeinen Zugang und wird nicht als Leistungs- oder Qualitätsmangel gewertet. Die freiwillige Einladung arbeitet Fail-Open. Mandanten-, Rollen-, Sitzungs-, Capability- und Scope-Schutz bleiben davon unabhängig Fail-Closed.

Die Zielzeit des Tageschecks liegt bei ungefähr 15 Sekunden. Die reguläre Laufzeit soll etwa 30 Sekunden nicht überschreiten. Zeitaufwendige Einzelprüfungen werden deshalb nicht in diese Ebene aufgenommen. Bei Verzögerungen bleibt der Fortschritt sichtbar. Soft- und Hard-Timeouts verhindern endlose Läufe, während Unterbrechungen kontrolliert fortgesetzt werden können.

Geprüft werden insbesondere der gültige Mandantenkontext, die aktive Rollenbindung, die sichere Sitzung, die erforderlichen Capabilities, zentrale Arbeitsbereiche, der Schutz vor Fremdscope, der Neutraltest, der Wirtschaftsmodus LOCKED sowie die Nachweis- und Quittierungsfähigkeit. Der Umfang bleibt rollenbezogen und auf die unmittelbare Tagesbereitschaft begrenzt.

Das Ergebnis ist eine kompakte S•U•S•I-Stellungnahme. Sie enthält eine verständliche Kurzbewertung, einen Ampelstatus mit Klartextgrund, Hinweise zu betroffenen und unbetroffenen Funktionen sowie den nächsten sinnvollen Schritt. PDF-Quittung, Arbeitsprotokolleintrag, Run-ID und Hash schließen den Lauf revisionsfähig ab. Die erste Ebene liefert damit einen Tageszustand, aber keine Gesamtzertifizierung des Systems.

Ebene 2 · Vollständiges Rollen-Audit

Die zweite Ebene prüft tiefer und umfassender. Sie untersucht das vollständige rollenbezogene Funktionsregister und richtet sich nicht nur auf die unmittelbare Tagesbereitschaft, sondern auf die technische und fachliche Belastbarkeit einer Rolle. Das Audit eignet sich insbesondere für Abnahmen, Regressionstests, Versionswechsel, Pilotprüfungen, gezielte Nachprüfungen und die Eingrenzung wiederkehrender Befunde.

Ein Audit kann manuell gestartet, von S•U•S•I nach einem entsprechenden Befund empfohlen oder durch einen Agentenauftrag vorbereitet werden. Weitere Auslöser können eine neue App-Version, ein geändertes Funktionsregister, wiederkehrende gelbe Befunde, kritische technische Fehler, Rollen- oder Policy-Änderungen sowie eine geplante Pilotabnahme sein. Ein vollständiges Audit wird nicht bei jedem Login ausgeführt.

Die Zielzeit liegt bei bis zu ungefähr 90 Sekunden; abhängig von der Prüftiefe kann die maximale Laufzeit etwa 180 Sekunden betragen. Der Lauf benötigt sichtbaren Fortschritt, klar strukturierte Prüfschritte, fortsetzbare Zwischenstände und eine eindeutige Timeout-Behandlung. Er darf nicht unbemerkt im Hintergrund verschwinden.

Das Audit arbeitet rollenbezogen. Die Profile A · Makler, B · Empfehlungspartner beziehungsweise Affiliate und C · Assistenz verwenden jeweils ein eigenes Funktionsregister. Der gemeinsame Schutzvertrag bleibt gleich, während sich Fachfunktionen, Capabilities und zulässige Datenreichweiten unterscheiden. Geprüft werden je nach Rollenprofil Navigation, Route, Middleware, Capability, Mandant, Object- oder Own-Scope, Service, Datenhaltung, Ereignis, Audit und sichtbare Rückmeldung.

Die Prüftiefe lässt sich in vier aufeinander aufbauende Stufen gliedern. Stufe I bestätigt, dass der technische Baustein vorhanden ist. Stufe II prüft, ob er registriert, erreichbar und konfiguriert ist. Stufe III untersucht Schutz und vollständige Funktionskette, einschließlich Mandant, Rolle, Capability, Scope und der Route–Controller–Service–Daten-Verbindung. Stufe IV weist den vollständigen Ablauf im realen Browser oder in einem reproduzierbaren Test praktisch nach.

Eine sichtbare Funktion gilt deshalb nicht bereits als vollständig belastbar. Vorhandensein und technische Installation sind nur Teilnachweise. Erst die passende Prüfstufe bestätigt, ob die Funktion tatsächlich geschützt, ausführbar, nachvollziehbar und abgenommen ist.

Das Audit erzeugt eine ausführlichere Prüfakte mit geprüfter Rolle, Prüfstufen, Funktionsregister-Version, Einzel- und Schutzbefunden, offenen Nachweisen, technischen Maßnahmen, Audit-PDF, Hash und eindeutigem Versions- und Kontextbezug. Daraus können gezielte Prüf- oder Reparaturaufträge entstehen. Eine automatische fachliche, rechtliche oder wirtschaftliche Produktivfreigabe bleibt ausgeschlossen.

Ebene 3 · Hintergrund-QM

Die dritte Ebene prüft das System unabhängig von einem einzelnen Nutzerlogin. Sie dient der regelmäßigen mandantenbezogenen Überwachung von Stabilität, Hintergrunddiensten, Versionen, Konfigurationen, Schutzbedingungen und Nachweisvollständigkeit. Ihr Ziel ist, Auffälligkeiten möglichst zu erkennen, bevor sie im Arbeitsalltag eines Nutzers sichtbar werden.

Hauptauslöser ist ein kontrollierter Cronlauf. Die Prüfung kann nachts, am frühen Morgen oder in festgelegten Intervallen ausgeführt werden. Der Cron startet den Lauf nach einem definierten und versionierten Betriebsvertrag. Eine automatische Aktivierung erfolgt erst nach gesonderter Abnahme. Zeitplan, Mandantenumfang und Prüfregister müssen eindeutig festgelegt sein.

Die Laufzeit richtet sich nach dem tatsächlichen Prüfvolumen. Anzahl der Mandanten, Rollenprofile, Funktionen, externen Dienste sowie Wiederholungs- und Fehlerfälle beeinflussen die Dauer. Deshalb besitzt das Hintergrund-QM keine starre kurze Zielzeit. Es benötigt Queues, Leases, Heartbeats, Fortsetzung, Retry, Backoff und Dead-Letter-Behandlung. Umfangreiche Prüfungen werden in kontrollierbare Einheiten zerlegt.

Jeder Mandant erhält einen eigenen Laufkontext, ein eigenes Funktionsregister, eigene Ergebnisse und eigene Korrelations- und Nachweisdaten. Mandantendaten dürfen nicht vermischt werden. Ein Fehler in einem Mandanten darf andere Läufe nicht unkontrolliert beeinflussen. Jeder Prüfstand bleibt eindeutig an Mandant, Rollenprofil, Version, Lauf, Zeitpunkt und Ergebnis gebunden.

Der Hintergrundlauf kann zentrale Services, Datenbankverbindungen, Queues, Outbox, NotificationCenter, Funktionsregister, Rollen- und Mandantenbindungen, Versionen, Hashes und Konfigurationsdrift prüfen. Dadurch kann S•U•S•I beim Tagesstart bereits auf bekannte technische Befunde zurückgreifen. Der persönliche Tagescheck bleibt dennoch erforderlich, weil nur er den konkreten Nutzer-, Rollen-, Sitzungs- und Arbeitskontext bestätigt.

Der Agent überwacht die technische Ausführung. Er kontrolliert Worker, Leases, Heartbeats, Unterbrechungen, Wiederaufnahme, Fehlerklassen, Finalisierung und technische Prüfaufträge. Er darf einen Lauf fortsetzen, technische Fehler klassifizieren, Nachprüfungen vorbereiten und die Finalisierung anstoßen. Er darf jedoch keine fachliche Freigabe ersetzen, wirtschaftliche Wirkung aktivieren oder ungeprüfte Ergebnisse produktiv freigeben. Cron startet, der Agent überwacht und der QM-Service bewertet.

Hintergrundläufe erzeugen mandantenbezogene Prüfberichte, technische Befunde, Trenddaten, Wiederholungsmuster, Prüfaufträge, Laufprotokolle, Hashes und Auditspuren. Nicht jeder technische Einzelbefund wird dem Nutzer angezeigt. S•U•S•I projiziert nur die für Rolle, Arbeitskontext und konkrete Betroffenheit relevanten Hinweise in den Tagesablauf.