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

1. Login und Kontextkennung

Ausgangspunkt ist der Login oder das Öffnen des persönlichen Arbeitsraums. Der Login allein startet noch keinen vollständigen Prüflauf. Zunächst erkennt das System, wer angemeldet ist, welchem Mandanten der Nutzer zugeordnet ist, welche Rolle aktiv ist, welcher Arbeitsraum geöffnet wurde und welche Sitzung verwendet wird.

Der Tagesprozess beginnt damit nicht bei einer abstrakten Systemprüfung, sondern beim konkreten Nutzungskontext. Erst wenn dieser eindeutig feststeht, kann das passende Funktionsregister aufgelöst werden.

Zur Kontextkennung gehören insbesondere Nutzeridentität, company_id, aktive Rollenbindung, Arbeitskontext, Sitzung, Capabilities, Objekt-, Own- oder Vorgangsscope, App-Version, Funktionsregister-Version und das Tagesdatum in Europe/Berlin.

Fehlt eine zwingende Kontextinformation, wird kein ungebundener Lauf gestartet. Mandant, Rolle und Scope arbeiten Fail-Closed. Eine Rollenbezeichnung allein genügt nicht. Die tatsächliche Berechtigung entsteht aus der Verbindung von Identität, Mandant, aktivem Kontext, Capability und Datenscope.

Ein echter Rollen- oder Mandantenwechsel erzeugt einen neuen Arbeitskontext. Vorherige Rechte werden nicht addiert, und das Funktionsregister wird neu aufgelöst. Alte Browser-Tabs und Deep Links werden erneut serverseitig geprüft. Ein einfacher Seitenwechsel innerhalb desselben Kontexts löst dagegen keinen neuen Tageslauf aus.

2. Statusprüfung

Nach der Kontextkennung prüft das System, ob für diesen konkreten Tageskontext bereits ein gültiger QM-Zustand vorliegt. Maßgeblich ist die Kombination aus Datum, Nutzer, Mandant, Rolle, Sitzung beziehungsweise Arbeitskontext, App-Version und Funktionsregister-Version.

Ein vorhandener grüner und weiterhin gültiger Tageszustand kann wiederverwendet werden. Der Nutzer soll nicht bei jedem erneuten Öffnen des Dashboards denselben Test wiederholen müssen. Die Statusprüfung verhindert dadurch unnötige Doppel- und Parallelläufe.

Ein neuer Lauf kann erforderlich sein, wenn für den aktuellen Tag noch kein Ergebnis vorliegt, ein vorheriger Lauf nicht abgeschlossen wurde, Rolle oder Mandant gewechselt haben, sich eine relevante App- oder Registerversion geändert hat, ein Nachweis unvollständig ist oder ein technischer Befund eine Wiederholungsprüfung verlangt.

Kein neuer Lauf ist notwendig, wenn bereits ein aktueller Tageszustand vorliegt, lediglich die Seite gewechselt wurde, innerhalb desselben Arbeitskontexts weitergearbeitet wird oder ein vorhandener Lauf sicher fortgesetzt werden kann.

Existiert ein unterbrochener Lauf, wird deshalb zuerst eine Fortsetzung geprüft. Der Zwischenstand bleibt an Run-ID, Nutzer, Mandant, Rolle, Prüfebene und Versionsstand gebunden. Fremde, manipulierte oder veraltete Fortsetzungen werden abgewiesen. Fortsetzung hat Vorrang vor unnötigem Neustart.

3. Einladung durch S•U•S•I

Die Einladung erscheint nur, wenn ein neuer oder fortzusetzender Tageslauf tatsächlich sinnvoll ist. S•U•S•I öffnet nicht bei jedem Login automatisch eine dominante Prüffläche. Eine bereits gültige Tagesstellungnahme macht eine neue Einladung überflüssig.

Der Hinweis fügt sich in das allgemeine Tagesmodell ein und verdrängt weder Aufgaben, Fortsetzungen, Termine noch dringende Vorgänge. Die Einladung informiert sachlich über Zweck, voraussichtliche Dauer, Freiwilligkeit, Neutraltest, fehlende wirtschaftliche Wirkung und die Form des späteren Nachweises.

Die Ansprache bleibt freundlich und nicht alarmistisch. Sie vermittelt nicht den Eindruck, dass bereits ein kritischer Fehler besteht, und erzeugt keinen Rechtfertigungsdruck.

Der Nutzer kann zwischen Jetzt starten, Später erinnern und Heute nicht mehr anzeigen wählen. Alle Entscheidungen sind technisch wirksam. Eine spätere Erinnerung erfolgt höchstens angemessen und einmalig. Das Ausblenden gilt für den aktuellen Tageskontext. Keine Auswahl führt zu einer negativen Bewertung oder Einschränkung.

4. Nutzerentscheidung

Mit Jetzt starten autorisiert der Nutzer den freiwilligen Tageslauf. Vor dem Start wird nochmals sichtbar bestätigt, was geprüft wird, wie lange der Lauf ungefähr dauert, dass 0,00 EUR verwendet werden, keine reale Außenwirkung entsteht und ein Protokoll erzeugt wird.

Erst danach wird der Lauf eröffnet. Er erhält eine eindeutige Run-ID, und Parallelstarts für denselben Tageskontext werden verhindert.

Die Entscheidung Später erinnern wird nicht als fehlgeschlagene Prüfung bewertet. Der Nutzer arbeitet normal weiter. Der Zustand bleibt verschoben und wird nicht als gelber oder roter Systembefund interpretiert.

Mit Heute nicht mehr anzeigen wird die Einladung für den aktuellen Tageskontext ausgeblendet. Der allgemeine Arbeitszugang bleibt erhalten. Es entstehen kein negativer Nutzerstatus, keine Eskalation, keine Leistungsbewertung und keine Anwesenheitsinterpretation.

Unabhängig erkannte kritische Schutzprobleme bleiben davon unberührt. Freiwilligkeit darf keine technische Sicherheitsgrenze aufheben.

5. Lauf und Bewertung

Nach der Startentscheidung wird ein eindeutiger Laufdatensatz angelegt. Er enthält mindestens Run-ID, Nutzer, Mandant, Rolle, Prüfebene, Startzeit, App-Version, Funktionsregister-Version, Prüfmodus und Neutralitätsstatus.

Der Laufzustand wird nachvollziehbar geführt. Mögliche Zustände sind vorbereitet, gestartet, laufend, unterbrochen, abgeschlossen, fehlgeschlagen oder abgebrochen. Jeder Übergang bleibt sichtbar und protokolliert.

Während des Laufs erkennt der Nutzer, dass die Prüfung tatsächlich arbeitet. Verständliche Prüfschritte können lauten: Arbeitskontext erkannt, Rollenbindung geprüft, Kernfunktionen aufgerufen, Schutzbedingungen bestätigt, Neutraltest durchgeführt und Nachweis vorbereitet.

Ein endloser Ladeindikator reicht nicht aus. Verzögerungen werden sichtbar gemacht, Soft- und Hard-Timeouts begrenzen den Lauf und Unterbrechungen bleiben kontrolliert fortsetzbar.

Der Prüfumfang richtet sich nach dem Funktionsregister der aktiven Rolle. Im Maklerkontext können Leitstand, Objektzugang, Anfragen, Rückrufe und Termine geprüft werden. Beim Empfehlungspartner stehen Partnerbereich, eigene Codes, Empfehlungen und Kommunikationswege im Mittelpunkt. Im Assistenzkontext werden Zuweisungen, Tagesaufgaben, interne Hinweise und Fortsetzungsakten geprüft.

Irrelevante oder unzulässige Funktionen werden nicht einbezogen. Dadurch bleibt der Tageslauf kurz und fachlich eindeutig.

Für alle Rollen gelten dieselben Schutzprüfungen. Dazu gehören Mandanten- und Rollenbindung, aktive Sitzung, Capability, zulässiger Scope, Auditfähigkeit, neutrale Testwerte, Wirtschaftsmodus LOCKED und der Ausschluss jeder automatischen Produktivwirkung.

Jeder Prüfschritt erhält einen strukturierten Status. Unterschieden werden bestandene Prüfungen, Warnungen, kritische oder technische Fehler, unvollständige Nachweise und fehlende Konfigurationen. Einzelbefunde werden nicht voreilig zu einem allgemeinen Systemausfall verdichtet. Nicht betroffene Funktionen bleiben als verfügbar ausgewiesen.

Der gesamte Lauf arbeitet mit 0,00 EUR. Es entstehen kein realer Lead, keine Kundenbuchung, keine Provision, keine Auszahlung, keine Rechnung und keine Produktivfreigabe. Kann der gesperrte Wirtschaftsmodus nicht bestätigt werden, liegt ein kritischer Befund vor. Auch ein abgebrochener oder fehlgeschlagener Lauf hinterlässt keine wirtschaftliche Teilwirkung.

6. S•U•S•I-Stellungnahme

Nach der technischen Bewertung formuliert S•U•S•I eine verständliche Stellungnahme. Grundlage sind ausschließlich strukturierte Prüfdaten. Die Aussage ist keine freie oder unbelegte Textgenerierung.

Sie erklärt, welcher Kontext geprüft wurde, welche Funktionen bereitstehen, welche Auffälligkeiten bestehen, welche Auswirkungen daraus folgen, welche Bereiche weiterhin nutzbar bleiben und welcher nächste Schritt vorgesehen ist.

Eine Farbe allein genügt nicht. Grün bestätigt Betriebsbereitschaft, Schutz und Nachweisbarkeit. Gelb zeigt einen offenen Teilnachweis oder Vertiefungsbedarf. Rot-Kritisch bezeichnet eine Schutzverletzung, Rot-Technisch einen technischen Ausfall, Rot-Nachweis eine fehlende Quittierung oder Auditspur und Rot-Konfiguration eine unvollständige Einrichtung.

Befund, Wirkung und Maßnahme werden zusammengeführt. Nicht betroffene Funktionen bleiben sichtbar. Die Stellungnahme beschreibt ausschließlich das System und enthält keine Aussagen über Arbeitsleistung, Geschwindigkeit, Anwesenheit, Verhalten, Umsatz oder persönliche Zuverlässigkeit.

Die sprachliche Grundregel lautet: Die Funktion ist nicht bereit. Der Mensch ist nicht der Fehler.

7. PDF und Arbeitsprotokoll

Nach Abschluss wird eine menschenlesbare PDF-Quittung erzeugt. Sie enthält Tagesdatum, Nutzerkontext, Prüfebene, Laufzeit, geprüfte Funktionsgruppen, Gesamtstatus, Einzelbefunde, Neutraltest, Wirtschaftsstatus, nächsten Schritt, Run-ID und Nachweis-Hash.

Die PDF ist versioniert und eindeutig dem Lauf zugeordnet. Bereits erzeugte PDFs werden nicht still verändert. Eine Neubewertung erzeugt eine neue Revision.

Zusätzlich entsteht ein sachlicher Eintrag im Arbeitsprotokoll. Er hält fest, dass ein Tages-QM stattgefunden hat, in welchem Rollen- und Mandantenkontext, mit welchem Ergebnis und wo PDF und Quittung abrufbar sind.

Der Eintrag ist keine Leistungs- oder Anwesenheitskontrolle. Er dokumentiert den Systemzustand im Arbeitskontext. PDF, Arbeitsprotokoll und Datenbankquittung werden über Run-ID und Hash miteinander verbunden.

Sichtbare Zeiten werden konsistent in Europe/Berlin ausgegeben. Technische Speicherung kann intern in UTC erfolgen. Beide Darstellungen müssen denselben Zeitpunkt eindeutig abbilden und Sommer- sowie Winterzeit korrekt berücksichtigen.

8. Tagesgruß und Rückkehr in den Arbeitsablauf

Nach der Quittierung führt S•U•S•I den Nutzer zurück in seinen Arbeitsraum. Der Tagesgruß fasst das Ergebnis knapp zusammen. Er kann bestätigen, dass die Tagesbereitschaft hergestellt ist, einen offenen Prüfpunkt benennen, auf eine vorbereitete technische Maßnahme hinweisen oder den Ablageort von PDF und Protokoll nennen.

Bei einem grünen Ergebnis zieht sich die Prüfung in eine kompakte Bestätigung zurück. Der Nutzer erkennt, dass der aktuelle Arbeitskontext geprüft, die wesentlichen Funktionen bestätigt, die wirtschaftliche Neutralität gesichert und der Nachweis gespeichert wurden.

Bei einem gelben Ergebnis wird der offene Punkt sachlich benannt. Es wird erklärt, ob und wie weitergearbeitet werden kann. Nicht betroffene Funktionen bleiben nutzbar, und eine Nachprüfung oder Beobachtung kann als Folgeaufgabe erscheinen.

Ein roter Befund wird klar, aber nicht alarmistisch eingeordnet. S•U•S•I benennt die betroffene Funktion, eine mögliche Schutzsperre, weiterhin nutzbare Bereiche und die vorgesehene technische Maßnahme. Eine automatische fachliche oder wirtschaftliche Freigabe bleibt ausgeschlossen.