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

Mandant und Rolle bestimmen den Prüfrahmen

Die Tagesprüfung beginnt mit der eindeutigen Mandantenbindung. Der Nutzer darf nur im aktuell gültigen Unternehmens- oder Organisationskontext geprüft werden. Die company_id bestimmt den zulässigen Datenraum, das Funktionsregister, die Rollenbindung, die sichtbaren Arbeitsbereiche und die Nachweisspur.

Ein früherer Tagesstatus aus einem anderen Mandanten darf nicht wiederverwendet werden. Abweichende Mandantenwerte aus Request, Session oder manipuliertem Link werden verworfen. Fehlt eine eindeutige Mandantenbindung, wird kein ungebundener Tageslauf gestartet. Die Mandantengrenze arbeitet Fail-Closed.

Auch die aktive Rolle gehört fest zum Prüfkontext. Ein Makler erhält ein anderes Funktionsregister als ein Empfehlungspartner, eine Assistenz oder ein Super-Admin. Mehrfachrollen werden nicht zusammengeführt. Pro Lauf gilt genau ein Rollen- und Arbeitskontext.

Die Rolle bestimmt, welche Kernarbeitsbereiche geprüft werden, welche Capabilities erforderlich sind, welcher Scope zulässig ist und welche Rückmeldung der Nutzer erhält. Ein Rollenwechsel kann deshalb einen neuen Tagescheck erforderlich machen. Der bisherige Nachweis bleibt auf den früheren Kontext begrenzt.

Mandant und Rolle dürfen nicht getrennt voneinander betrachtet werden. Erst die Verbindung aus Nutzer, Mandant, Rolle, Sitzung, Capability und Scope erzeugt den gültigen Prüfrahmen. Der gleiche Menüpunkt kann in einem Kontext zulässig und in einem anderen gesperrt sein.

Der Tagescheck bestätigt daher keine abstrakte Systemfunktion, sondern deren sichere Verfügbarkeit für den konkreten Nutzer.

Die rollenbezogenen Kernarbeitsbereiche

Ebene 1 prüft nur diejenigen Arbeitsbereiche, die der Nutzer unmittelbar für seinen Arbeitstag benötigt. Im Maklerkontext können dazu Leitstand, Objektzugang, Anfragen, Rückrufe und Termine gehören. Im Empfehlungspartnerkontext stehen Partnerübersicht, eigene Empfehlungen, eigene Codes, Rückfragen und Nachweise im Mittelpunkt. Im Assistenzkontext werden Zuweisungen, Tagesaufgaben, interne Hinweise und Fortsetzungsakten geprüft.

Nicht benötigte Fachbereiche werden nicht aufgerufen. Dadurch bleibt der Lauf kurz und fachlich eindeutig.

Ein Kernarbeitsbereich gilt jedoch nicht allein deshalb als bereit, weil seine Seite sichtbar ist. Geprüft wird mindestens, ob die Route erreichbar, die Middleware aktiv, die Rolle zulässig, der Mandant korrekt, die Capability vorhanden, der Scope gebunden, die Datenprojektion verfügbar und die technische Antwort gültig ist.

Ein sichtbares Dashboard ohne korrekte Datenbindung wäre kein grüner Befund. Eine ausgeblendete Schaltfläche ist keine Sicherheitsprüfung. Der Tagescheck prüft die sichere Einstiegskette, nicht die vollständige Fachbearbeitung jedes einzelnen Vorgangs.

Innerhalb der kurzen Laufzeit werden kritische Funktionen priorisiert. Vorrang haben Bereiche, deren Ausfall den Arbeitstag unmittelbar beeinträchtigen würde. Dazu gehören insbesondere Login- und Sitzungsschutz, Leitstand, zentrale Datenprojektion, aktuelle Aufgaben- oder Vorgangssicht, Neutraltest und Quittierungsfähigkeit.

Weniger kritische Funktionen können später geprüft, im Audit vertieft oder im Hintergrund überwacht werden. Diese Priorisierung muss im Funktionsregister festgelegt und versioniert sein.

Die sichere Sitzung

Der Tagescheck bestätigt, dass die Sitzung zum angemeldeten Nutzer und zum aktuellen Arbeitskontext gehört. Geprüft werden können gültige Authentifizierung, aktive Session, passende Rollenbindung, das Fehlen veralteter Kontextübernahmen, eine korrekte Mandantenkennung und ein zulässiger Impersonation-Zustand.

Ein alter Browser-Tab nach einem Rollen- oder Mandantenwechsel muss erneut geprüft werden. Eine sichere Sitzung ist Voraussetzung für alle weiteren Schritte. Fehlt sie, liegt ein kritischer Schutzbefund vor.

Sicherheit hat Vorrang vor Komfort. Der Tagescheck darf eine unsichere Sitzung nicht aus Zeitgründen als grün behandeln. Kann eine zwingende Schutzbedingung nicht eindeutig bestätigt werden, wird der betroffene Schritt abgewiesen, der Befund klassifiziert und die wirtschaftliche Wirkung bleibt gesperrt.

Die 15 Sekunden sind ein Zielwert. Sie sind keine Erlaubnis, Schutzbedingungen zu umgehen.

Das Dashboard als täglicher Arbeitszugang

Das Dashboard ist häufig der erste zentrale Arbeitsbereich nach dem Login. Geprüft wird, ob es erreichbar, kontextbezogen, mandantensicher, mit aktuellen Daten versorgt und frei von fremden Datensätzen dargestellt wird.

Es kann offene Aufgaben, kritische Vorgänge, Termine, Rückfragen und Systemhinweise verdichten. Die Tagesprüfung bewertet jedoch nicht, wie viele Aufgaben der Nutzer erledigt hat. Sie bestätigt ausschließlich, dass der Arbeitszugang technisch korrekt bereitsteht.

Ein grünes Dashboard bedeutet nicht automatisch, dass sämtliche Fachmodule vollständig abgenommen sind. Ebene 1 prüft sichere Erreichbarkeit, korrekte Projektion und wesentliche Tagesdaten. Tiefergehende Fachfunktionen gehören in das vollständige Rollen-Audit.

Diese Trennung verhindert, dass der Tagesstart zu einem langen Ende-zu-Ende-Test wird.

Neutraltest und wirtschaftlicher Schutz

Der Tageslauf prüft wirtschaftsnahe Schutzmechanismen ausschließlich mit 0,00 EUR. Es entstehen keine Forderung, keine Provision, keine Auszahlung, keine Rechnung, kein realer Lead und keine Kundenbuchung.

Der Neutraltest bestätigt, dass wirtschaftliche Funktionen im QM-Kontext keine reale Außenwirkung entfalten. Ein grünes Ergebnis ist keine wirtschaftliche Freigabe. Technische Prüfung und kaufmännische Entscheidung bleiben strikt getrennt.

Während des gesamten Tageschecks gilt der Wirtschaftsmodus LOCKED. Die Sperre muss auf Systemebene wirken. Sie darf nicht nur durch ausgeblendete Buttons, Hinweise in der Benutzeroberfläche oder fehlende Menüeinträge hergestellt werden.

Wirtschaftlich wirkende Services und Commands bleiben gesperrt. Kann der Status LOCKED nicht bestätigt werden, liegt ein kritischer Befund vor. Ein solcher Befund darf nicht durch einen ansonsten schnellen Lauf überdeckt werden.

Sichtbarer Fortschritt und feste Laufzeitgrenzen

Auch ein kurzer Lauf benötigt eine verständliche Fortschrittsanzeige. Geeignete Schritte sind etwa: Kontext erkannt, Mandant und Rolle bestätigt, Kernarbeitsbereiche geprüft, Sitzung geschützt, Dashboard erreichbar, Neutraltest bestanden und Nachweis wird erzeugt.

Der Nutzer soll erkennen, dass der Lauf aktiv ist. Eine überladene technische Detailansicht ist dafür nicht erforderlich. Der Fortschritt soll Sicherheit schaffen und keine zusätzliche Unruhe erzeugen.

Die Zielzeit liegt bei ungefähr 15 Sekunden. Nach etwa 30 Sekunden greift die harte Grenze. Wird sie überschritten, muss der Lauf kontrolliert abbrechen, einen Teilstatus speichern, einen technischen Befund erzeugen und eine Fortsetzung oder Tiefenprüfung anbieten.

Ein hängender Dienst darf den Tagesstart nicht unbegrenzt blockieren. Ein Timeout wird niemals als persönlicher Nutzerfehler gewertet.

Die Ergebnislogik

Das Ergebnis bleibt kompakt und verständlich. Grün bestätigt, dass die kritischen Tagesfunktionen bereitstehen, die Schutzbedingungen erfüllt, die Neutralität bestätigt und der Nachweis erzeugt wurde.

Gelb bedeutet, dass die Arbeit grundsätzlich möglich ist, aber ein Teilnachweis oder eine nichtkritische Prüfung noch offen bleibt.

Rot-Kritisch bezeichnet eine verletzte oder nicht bestätigbare Schutzgrenze. Rot-Technisch beschreibt einen ausgefallenen Dienst, eine fehlerhafte Route oder einen nicht verfügbaren Datenzugang. Rot-Nachweis liegt vor, wenn die Funktion zwar gearbeitet hat, Quittierung oder Hash jedoch fehlen. Rot-Konfiguration kennzeichnet eine fehlende Zuordnung oder Einrichtung.

Jede Farbe wird durch einen Klartextgrund und die nächste Maßnahme ergänzt.

Ein einzelner Befund bedeutet nicht automatisch den Ausfall des gesamten Systems. Die Stellungnahme benennt die betroffene Funktion, nicht betroffene Bereiche, mögliche Weiterarbeit und den nächsten technischen Schritt. Nur ein unabhängig festgestelltes kritisches Risiko darf die konkret betroffene Funktion sperren.

Der Tagescheck soll schützen, ohne unnötig den gesamten Arbeitstag zu blockieren.

Nachweis trotz kurzer Laufzeit

Auch der 15-Sekunden-Check erzeugt eine belastbare Quittung. Dokumentiert werden Run-ID, Nutzer, Mandant, Rolle, Prüfdatum, Start und Ende, Dauer, App-Version, Funktionsregister-Version, Ergebnis, Neutraltest, Wirtschaftsstatus und Hash.

PDF und Arbeitsprotokoll werden dem Lauf eindeutig zugeordnet. Kürze bedeutet nicht Verzicht auf Nachweisbarkeit. Der Tageszustand bleibt revisionsfähig nachvollziehbar.

Der kurze Lauf beantwortet ausschließlich die Frage nach der unmittelbaren Arbeitsfähigkeit. Er ersetzt weder das vollständige Rollen-Audit noch eine Browser-Ende-zu-Ende-Abnahme, das Hintergrund-QM, eine Billing- oder Wirtschaftsprüfung oder eine Sicherheitsanalyse.

Ein gelber oder wiederkehrender Befund kann eine vertiefte Prüfung auslösen. Die QM-Ebenen arbeiten komplementär.

Technische Optimierung des 15-Sekunden-Zielwerts

Der Lauf greift auf vorbereitete und versionierte Prüfdefinitionen zu. Dazu gehören ein begrenztes Funktionsregister, vorbereitete Kontextauflösung, kurze Health- und Zugriffschecks, definierte Timeouts und gegebenenfalls parallel ausgeführte unabhängige Prüfungen.

Unnötige Volltabellenscans werden vermieden, und gültige Tageszustände können wiederverwendet werden. Prüfungen dürfen jedoch nicht aus veralteten oder fremden Cachezuständen beantwortet werden. Jede Optimierung bleibt an Mandant, Rolle und Version gebunden.

Ein gültiger Tageszustand wird nicht bei jedem Seitenwechsel neu berechnet. Ein unterbrochener Lauf wird fortgesetzt. Nur relevante Änderungen erzeugen einen neuen Prüfanlass.

Dadurch werden Laufzeit, Systemlast, Nutzerbelastung und doppelte Nachweise reduziert. Die Wiederverwendung bleibt an den eindeutigen Tages-Key gebunden.