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

Das Angebot

S•U•S•I bietet den Tagescheck nur an, wenn ein tatsächlicher Prüfanlass besteht. Die Einladung ist freundlich, knapp, sachlich und nicht alarmistisch. Sie darf weder drohend wirken noch den Eindruck erwecken, bereits sei ein persönliches oder technisches Fehlverhalten festgestellt worden.

Vor der Entscheidung erklärt S•U•S•I den Zweck des Laufs, seine voraussichtliche Dauer, den freiwilligen Charakter, die neutralen Prüfwerte, die fehlende wirtschaftliche Wirkung und die Form des späteren Nachweises. Der Nutzer soll verstehen können, was geschieht, bevor er eine Auswahl trifft.

Das Angebot führt zu drei gleichwertigen Entscheidungswegen:

• Jetzt starten
• Später erinnern
• Heute nicht

Alle drei Wege sind legitime Nutzungsentscheidungen. Nur die erste Auswahl startet den QM-Lauf unmittelbar. Die beiden anderen dürfen nicht als Ablehnung von Qualität, Pflichtverletzung, technischer Fehler oder Zugangsproblem interpretiert werden.

Die Entscheidung wird nur so weit gespeichert, wie es für die korrekte Hinweislogik notwendig ist.

Weg 1 · Jetzt starten

Mit Jetzt starten bestätigt der Nutzer ausdrücklich den freiwilligen Beginn des Tageschecks. Vor der Ausführung werden Nutzer, Mandant, Rolle, Tagesdatum, App-Version, Funktionsregister-Version und Neutralitätsstatus nochmals eindeutig gebunden.

Anschließend wird eine eindeutige Run-ID erzeugt. Parallele Läufe für denselben Tageskontext werden verhindert. Der Nutzer sieht den Fortschritt und die geprüften Funktionsgruppen.

Die technische Prüfung führt das rollenbezogene Funktionsregister aus. Sie prüft Betriebsbereitschaft, Erreichbarkeit, organisatorischen Schutz, Auditfähigkeit und wirtschaftliche Neutralität. Während des Laufs bleibt sichtbar, welcher Abschnitt geprüft wird, ob der Lauf aktiv ist, ob eine Verzögerung besteht und ob eine Fortsetzung möglich ist.

Unterbrechungen dürfen nicht automatisch einen zweiten Lauf erzeugen. Bei Reload oder Gerätewechsel wird eine sichere Fortsetzung geprüft.

Nach Abschluss entsteht eine nachvollziehbare Quittierung. Dazu gehören die S•U•S•I-Stellungnahme, PDF, Arbeitsprotokolleintrag, Run-ID, Hash, Ergebnisstatus und der Nachweis der wirtschaftlichen Neutralität.

Der Abschluss dokumentiert den Systemzustand. Er bewertet nicht die Entscheidung des Nutzers als persönliche Leistung. Auch ein gelber oder roter technischer Befund bleibt von der Nutzerentscheidung getrennt. Der Nutzer hat den Test gestartet; der Befund beschreibt das System.

Weg 2 · Später erinnern

Der Nutzer kann den Tagescheck auf einen späteren Zeitpunkt verschieben. Das kann sinnvoll sein, wenn zunächst ein dringender Vorgang bearbeitet werden muss, ein Termin beginnt, der Arbeitsraum nur kurz geöffnet wurde oder der Check zu einem ruhigeren Zeitpunkt stattfinden soll.

Die Verschiebung ist kein Fehler. Sie erhält weder einen gelben noch einen roten Qualitätsstatus und verändert weder Rechte noch Zugang.

Später erinnern darf nicht zu einer dauerhaften Pop-up-Schleife führen. Für den Tag ist höchstens eine angemessene erneute Erinnerung vorgesehen. Sie soll zeitlich sinnvoll, ruhig, leicht schließbar und nicht alarmistisch sein.

Die Erinnerung darf keine wichtige Arbeitsfläche verdecken. Auch nach der erneuten Anzeige bleibt die Entscheidung frei. Wiederholtes Schließen darf nicht zu einer Eskalation führen.

Unzulässig wären wiederkehrende Dialoge bei jedem Seitenwechsel, blockierende Overlays, Countdown-Zwang, künstliche Dringlichkeit oder versteckte Zugangssperren. Der gewählte Erinnerungszustand bleibt für den aktuellen Tageskontext erhalten. Ein Seitenwechsel setzt ihn nicht zurück.

Weg 3 · Heute nicht

Mit Heute nicht beendet der Nutzer die QM-Einladung für den aktuellen Tageskontext. Danach erscheinen an diesem Tag keine weiteren gewöhnlichen Hinweise zum Tagescheck.

Der Zustand bleibt an Datum, Nutzer, Mandant, Rolle sowie App- und Funktionsregister-Version gebunden. Ein einfacher Seitenwechsel oder erneuter Login im selben Kontext darf die Einladung nicht wieder aktivieren. Erst ein echter Rollen-, Mandanten- oder relevanter Versionswechsel kann einen neuen Kontext erzeugen.

Heute nicht bedeutet nicht, dass der Test fehlgeschlagen ist, das System rot steht, der Nutzer unkooperativ handelt, der Zugang unsicher ist oder die Arbeitsleistung mangelhaft wäre. Es handelt sich ausschließlich um eine legitime Entscheidung gegen den freiwilligen Lauf an diesem Tag.

Ein Status wie declined_today oder dismissed_for_day darf deshalb nicht mit einem technischen Fehlerstatus vermischt werden. Nutzerentscheidung und Prüfbefund bleiben fachlich getrennt.

Aus der Ablehnung dürfen keine Zugangssperre, Rechteentziehung, Einschränkung des Dashboards, negative Kennzahl, Personalhinweis, Provisions- oder Vergütungsfolge, Eskalation an Vorgesetzte oder automatischer Supportfall entstehen.

Das System bleibt normal nutzbar. Nur unabhängig festgestellte kritische Schutzverletzungen dürfen die konkret betroffene Funktion sperren. Eine solche Sperre wäre Folge eines technischen Befunds, nicht Folge der Ablehnung.

Gemeinsames Ergebnis aller drei Wege

Alle drei Entscheidungswege führen zurück in den normalen Arbeitsablauf. Bei Jetzt starten geschieht dies nach Abschluss und Quittierung. Bei Später erinnern erfolgt die Rückkehr unmittelbar mit einer späteren, begrenzten Erinnerung. Bei Heute nicht bleibt der Arbeitsraum ohne weitere gewöhnliche Hinweise nutzbar.

Der Nutzer behält die Kontrolle über den Zeitpunkt des freiwilligen Checks. Das System behält die Kontrolle über seine zwingenden Schutzbedingungen. Dadurch entsteht ein Modell, das weder Qualität erzwingt noch Sicherheit relativiert.

Kein negativer Nutzerstatus

Aus einer Verschiebung oder Ablehnung darf keine persönliche Negativmarkierung entstehen. Statuswerte oder Auswertungen wie unkooperativ, Prüfung verweigert, mangelnde Compliance, verspätet geprüft oder geringe Beteiligung sind ausgeschlossen.

Zulässig ist ausschließlich die sachliche Information, dass das QM heute gestartet, später erinnert oder für den Tag ausgeblendet wurde. Diese Information dient der Hinweissteuerung und ist kein Bestandteil einer Leistungs-, Personal- oder Vergütungsakte.

Die Entscheidung darf keine arbeitsrechtlichen oder wirtschaftlichen Nebenwirkungen auslösen. Sie verändert weder Anwesenheitsbewertung noch Arbeitszeitauswertung, Leistungsbeurteilung, Vergütung, Provision oder Bonusentscheidung.

Auch die Anzahl freiwillig gestarteter Tests darf nicht zu einem Ranking verarbeitet werden.

Datensparsame Speicherung

Die getroffene Auswahl kann technisch gespeichert werden, damit Einladungen nicht unnötig wiederholt werden. Gespeichert werden nur die notwendigen Informationen: Tages-Key, Auswahl, Zeitpunkt und gegebenenfalls Erinnerungstermin.

Nicht erforderlich sind eine Begründung der Ablehnung, persönliche Bewertungen, Verhaltensprofile oder ein dauerhaftes Entscheidungsranking. Die Speicherung bleibt datensparsam und zweckgebunden.

Mit einem neuen Tages- oder Arbeitskontext wird die Entscheidung neu bewertet.

Fail-Open und Fail-Closed

Fail-Open gilt für:

• die freiwillige Einladung,
• die Startentscheidung,
• die Verschiebung,
• das Ausblenden für den Tag,
• die allgemeine Weiternutzung des Systems.

Fail-Closed gilt für:

• Mandantengrenze,
• Rollenbindung,
• Capability,
• Object-, Referral- oder Own-Scope,
• sichere Sitzung,
• wirtschaftliche Sperre,
• Schutz vor Fremdzugriff,
• reale Produktivwirkung.

Diese Unterscheidung ist zentral. Der Nutzer besitzt Entscheidungsfreiheit beim freiwilligen Check. Das System besitzt keine Entscheidungsfreiheit bei zwingenden Sicherheitsregeln.

Kontextänderungen nach einer Ablehnung

Die Entscheidung Heute nicht gilt nur für den konkret gebundenen Tageskontext. Ändern sich am selben Tag Mandant, Rolle, App-Version, Funktionsregister oder eine kritische Schutzlage, kann ein neuer Prüfanlass entstehen.

S•U•S•I muss dann verständlich erklären, warum erneut ein Angebot erscheint. Ein bloßer Seitenwechsel reicht dafür nicht aus. Der frühere Nutzungsentscheid bleibt als eigener Kontextzustand erhalten und wird nicht rückwirkend verändert.

Unabhängige kritische Befunde

Freiwilligkeit bedeutet nicht, dass bekannte kritische Systemfehler ignoriert werden. Erkennt das System unabhängig vom freiwilligen QM-Lauf eine Mandantenvermischung, fehlenden Rollenschutz, eine unsichere Sitzung oder eine nicht gesperrte Wirtschaftswirkung, darf die betroffene Funktion Fail-Closed geschützt werden.

Der Nutzer erhält in diesem Fall einen konkreten Sicherheitshinweis. Dieser Hinweis ist keine wiederholte QM-Einladung, sondern die Reaktion auf einen realen kritischen Befund.

Gestaltung und Zustandslogik

Die drei Optionen werden gleichwertig und verständlich dargestellt. Jetzt starten darf hervorgehoben sein, aber nicht als einzige zulässige Entscheidung erscheinen. Später erinnern und Heute nicht dürfen weder versteckt noch beschämend formuliert werden.

Die Sprache bleibt sachlich, respektvoll, eindeutig und frei von manipulativer Dringlichkeit. Nach der Auswahl schließt sich die Einladung unmittelbar. Der Arbeitsraum bleibt nutzbar.

Eine mögliche Zustandslogik lautet:

offered → started → running → completed

oder:

offered → remind_later → reminded_once → started | dismissed_today

oder:

offered → dismissed_today

dismissed_today ist kein Fehlerstatus. remind_later ist kein Warnstatus. Nutzerentscheidung und technischer Laufstatus werden in getrennten Feldern geführt.

Wiederholte Klicks dürfen keinen widersprüchlichen Zustand erzeugen. Jetzt starten eröffnet nur einen aktiven Lauf. Später erinnern erzeugt nicht mehrere Erinnerungseinträge. Heute nicht wird nicht bei jedem Seitenwechsel neu gespeichert.

Die Entscheidung bleibt an den Tages-Key gebunden. Dadurch bleiben Oberfläche und Nachweisspur konsistent.