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

Fachliche Abnahme · Freiwilligkeit muss tatsächlich funktionieren

Die Einladung zur Tagesprüfung muss eindeutig als freiwillig erkennbar sein. Sichtbar angeboten werden:

• Jetzt starten
• Später erinnern
• Heute nicht

Keine dieser Optionen darf versteckt, abgewertet oder irreführend formuliert sein.

Später erinnern darf höchstens eine angemessene erneute Erinnerung erzeugen. Heute nicht beendet die gewöhnliche Einladung für den aktuellen Tageskontext.

Verschiebung oder Ablehnung dürfen weder Zugangssperre noch Warnung, negative Nutzerbewertung oder Eskalation auslösen.

Die Pilotabnahme muss alle drei Wege praktisch im Browser nachweisen.

Freiwilligkeit muss auch serverseitig wirksam sein

Es genügt nicht, dass die Oberfläche freiwillig wirkt. Der Serverzustand muss die Entscheidung korrekt speichern und respektieren.

Geprüft werden:

• kein Lauf nach Ablehnung,
• kein Doppelstart,
• keine wiederholten Pop-ups,
• keine Vermischung von declined, failed und warning,
• uneingeschränkte allgemeine Systemnutzung.

Das Fail-Open-Modell muss in Benutzeroberfläche, Datenmodell und Ereignisspur übereinstimmen.

Der Nachweis muss zeigen, dass die Entscheidung respektiert und nicht später negativ umgedeutet wurde.

Gelb- und Rot-Texte müssen verständlich sein

Eine Ampelfarbe allein reicht für die Pilotabnahme nicht aus.

Für jeden gelben oder roten Befund muss S•U•S•I verständlich beantworten:

• Was wurde geprüft?
• Was ist nutzbar?
• Welche Funktion ist betroffen?
• Besteht ein Risiko?
• Kann sicher weitergearbeitet werden?
• Was geschieht als Nächstes?

Die Kategorien Rot-Kritisch, Rot-Technisch, Rot-Nachweis und Rot-Konfiguration müssen sprachlich klar voneinander unterscheidbar bleiben.

Technische Rohmeldungen wie HTTP 500 oder Timeout werden in eine arbeitsbezogene Aussage übersetzt. S•U•S•I darf dabei keine unbelegte Ursache erfinden.

Ist die Ursache noch unklar, wird genau das benannt.

Ruhige Fachsprache ohne Schuldzuweisung

Ein technischer Ausfall darf nicht automatisch wie ein Sicherheits- oder Wirtschaftsschaden formuliert werden.

Eine Nachweislücke darf nicht wie ein vollständiger Funktionsausfall erscheinen. Ein Konfigurationsproblem darf nicht dem Nutzer persönlich zugerechnet werden.

Die Abnahme prüft:

• ruhige Sprache,
• klare praktische Wirkung,
• begrenzte Maßnahme,
• keine Schuldzuweisung.

Nicht betroffene Arbeitsbereiche werden ausdrücklich benannt. Der Nutzer bleibt dadurch handlungsfähig und wird nicht unnötig verunsichert.

Das PDF muss lesbar und fachlich vollständig sein

Das PDF-Protokoll muss ohne technische Spezialkenntnisse verständlich sein.

Die Kundenlesefassung enthält mindestens:

• geprüften Kontext,
• Prüfebene,
• Gesamtstatus,
• Kurzstellungnahme,
• betroffene und weiterhin nutzbare Funktionen,
• wirtschaftliche Neutralität,
• nächsten Schritt.

Das Dokument darf keine abgeschnittenen Texte, unlesbaren Tabellen, falschen Zeilenumbrüche, überlagerten Elemente oder fehlerhaften Sonderzeichen enthalten.

Auch längere gelbe und rote Stellungnahmen müssen in Browser und PDF sauber dargestellt werden. Technische Prüffassung und Revisionsfassung müssen vollständig auffindbar sein.

Die PDF muss zur tatsächlichen Prüfebene passen

Ein Tagescheck darf nicht als vollständiges Rollen-Audit bezeichnet werden. Ein Hintergrundbericht darf nicht wie ein individueller Nutzercheck erscheinen.

Im PDF muss sichtbar sein:

• Ebene 1 · Tagesprüfung,
• Ebene 2 · vollständiges Rollen-Audit,
• Ebene 3 · Hintergrund-QM.

Der ausgewiesene Prüfumfang muss dem tatsächlichen Lauf entsprechen. Nicht geprüfte Funktionen dürfen nicht still als bestätigt erscheinen.

Keine Mitarbeiterbewertung

Das QM darf im Pilotbetrieb keine Bewertung erzeugen zu Arbeitsleistung, Produktivität, Geschwindigkeit, Anwesenheit, Pünktlichkeit, Verhalten oder Kooperationsbereitschaft.

Der Loginzeitpunkt ist kein Arbeitsbeginn. Die Laufzeit beschreibt ausschließlich die technische Systemdauer. Eine Ablehnung des freiwilligen Checks ist kein negativer Status.

Arbeitsprotokoll und Kennzahlendashboard müssen diese Grenze sichtbar einhalten.

Der Pilot ist nicht abnahmefähig, wenn aus QM-Daten personenbezogene Rankings oder Leistungsprofile abgeleitet werden können.

Technische Abnahme · Run, Rolle und Mandant

Jeder Lauf benötigt eine eindeutige Run-ID. Sie wird an Nutzer, Mandant, Rolle, Prüfebene, Berliner Tagesdatum, App-Version und Funktionsregister-Version gebunden.

Ein Ergebnis darf nicht auf einen anderen Kontext übertragen werden. Ein Maklerlauf gilt nicht für den Affiliate-Kontext. Ein Lauf aus Mandant A gilt nicht für Mandant B.

Fremde Nutzer dürfen PDF oder Arbeitsprotokoll nicht allein über eine erratbare ID öffnen.

Tages-Key und Laufidentität

Der Tages-Key besteht aus:

• Datum in Europe/Berlin,
• company_id,
• role_code,
• user_id,
• App-Version,
• Funktionsregister-Version.

Geprüft wird, dass derselbe Kontext einen gültigen Tageszustand wiederverwendet, relevante Kontextwechsel neuen Prüfbedarf erzeugen, Seitenwechsel keinen neuen Lauf starten, unterbrochene Läufe fortgesetzt und Doppelstarts verhindert werden.

Rollen- oder Mandantenwechsel dürfen keine Rechteunion erzeugen. Alte Browser-Tabs werden serverseitig neu geprüft.

Serverseitige Schutzkette

Die Bindung muss durch die gesamte technische Kette wirken:

Route → Middleware → Controller → Service → Query beziehungsweise Repository → Audit

Ein ausgeblendeter Menüpunkt gilt nicht als Schutz.

Negative Tests müssen belegen:

• fremde company_id wird abgewiesen,
• fremdes Objekt wird abgewiesen,
• fremde Empfehlung wird abgewiesen,
• unbekannte Capability wird abgewiesen,
• manipulierte Sessionrolle erzeugt keinen Zugriff.

Die Abweisung erfolgt nachvollziehbar mit definiertem HTTP- oder Fehlerstatus.

Payload und PDF müssen über Hashes verbunden sein

Der strukturierte Prüfpayload erhält einen Payload-Hash. Die konkrete PDF-Datei erhält einen eigenen PDF-Hash.

Geprüft wird:

• Hash erzeugt,
• Hash gespeichert,
• Hash reproduzierbar,
• PDF gehört zum richtigen Run,
• PDF-Inhalt entspricht dem gespeicherten Payload.

Ein fehlender oder abweichender Hash darf nicht zu Grün führen.

Der Befund wird als Rot-Nachweis oder bei Manipulationsverdacht als kritischer Schutzbefund behandelt.

Idempotente PDF-Erzeugung

Wiederholte Abschlussaufrufe dürfen keine widersprüchlichen PDFs erzeugen.

Für denselben unveränderten Payload wird dieselbe registrierte Fassung ausgeliefert.

Eine inhaltliche Änderung erzeugt neue Revision, neuen Hash, neue Erstellungszeit und einen Vorgängerbezug.

Frühere Fassungen werden nicht still überschrieben. Die Pilotabnahme muss mindestens einen Wiederholungs- und einen Revisionsfall enthalten.

Wirtschaft muss verifizierbar LOCKED bleiben

Der QM-Lauf verwendet ausschließlich 0,00 EUR.

Technisch nachgewiesen werden müssen:

• economic_effect = none,
• Wirtschaftsmodus LOCKED,
• keine Forderung,
• keine Provision,
• keine Auszahlung,
• keine Rechnung,
• keine reale Kundenbuchung,
• keine Produktivfreigabe.

Die Sperre muss auf Systemebene wirken. Ein ausgeblendeter Button oder fehlendes Menü reicht nicht aus.

Wirtschaftlich wirksame Services und Commands bleiben gesperrt.

Keine automatische Statusvererbung

Ein grüner QM-Status darf keinen fachlichen Freigabestatus verändern.

Zulässig ist:

qm_status = green
release_status = pending
economic_status = locked

Unzulässig wäre:

qm_status = green → release_status = approved → payout_status = authorized

Prüf-, Freigabe-, Wirtschafts- und Auszahlungsstatus werden getrennt geführt.

Vollständige Ereignisspur

Für einen regulären Lauf muss mindestens folgende Kette nachvollziehbar sein:

offered → started → completed → generated → protocol_written

Für Verschiebung und Ablehnung gelten eigene neutrale Wege.

Bei Fehlerfällen müssen letzter erfolgreicher Schritt, Fehlerklasse, Timeout, Retry oder Fortsetzung erkennbar sein.

Jedes Ereignis bleibt an Run-ID, Kontext, Zeit und Payload-Hash gebunden. Fehlende Ereignisse erzeugen einen Nachweisbefund.

Betriebliche Abnahme · Browserabriss und Reload

Der Pilot muss einen realen Browserabriss während eines laufenden QM-Tests verkraften.

Geprüft werden Browser schließen, Tab schließen, Reload, Sitzung erneuern und spätere Anmeldung.

Der Lauf darf nicht verschwinden, nicht doppelt neu starten und keinen widersprüchlichen Status erzeugen.

Soweit möglich wird am letzten bestätigten Schritt fortgesetzt. Fremde oder veraltete Fortsetzungsstände werden abgewiesen.

Geräte- und Sitzungswechsel

Ein laufender oder abgeschlossener Prüfvorgang muss nach einem kontrollierten Gerätewechsel korrekt zugeordnet bleiben.

Geprüft werden neue Authentifizierung, gleicher Nutzer, gleicher Mandant, gleiche Rolle und gültige Fortsetzungsberechtigung.

Ein anderes Benutzerkonto darf den Lauf nicht übernehmen. Ein Rollenwechsel erzeugt einen neuen Kontext und gegebenenfalls einen neuen Lauf.

Die Fortsetzungsakte bleibt identitäts- und scope-gebunden.

Doppelstart und parallele Verarbeitung

Zwei Browser-Tabs oder wiederholte Klicks dürfen nicht zwei aktive Tagesläufe erzeugen.

Auch Cron, Agent und manueller Start dürfen denselben Lauf nicht parallel anlegen.

Geprüft werden Lock, Idempotenzschlüssel, Lease, Run-ID und Ereignisspur.

Ein paralleler Start wird auf den vorhandenen Lauf verwiesen oder kontrolliert abgewiesen.

Rollen A, B und C praktisch validieren

Der Pilot prüft mindestens:

• A · Makler
• B · Affiliate beziehungsweise Empfehlungspartner
• C · Assistenz

Jede Rolle besitzt ein eigenes Funktionsregister.

Nachzuweisen sind richtige Navigation, richtige Kernarbeitsbereiche, passende Capabilities, korrekter Daten- und Ressourcenscope, verständliche Stellungnahme sowie PDF und Arbeitsprotokoll.

Der gemeinsame Schutzvertrag bleibt für alle Rollen gleich. Unterschiede bestehen ausschließlich im fachlichen Prüfumfang.

Rolle A · Makler

Zu prüfen sind beispielsweise Makler-Leitstand, Objektmatrix, eigene oder zugewiesene Objekte, Anfragen, Rückrufe, Termine, Neutraltest und Nachweis.

Negative Fälle sind:

• fremdes Objekt,
• fremder Mandant,
• fehlende Capability,
• unzulässiger Direktlink.

Das Ergebnis darf keine automatische Exposé-, Objekt- oder Abrechnungsfreigabe auslösen.

Rolle B · Empfehlungspartner

Zu prüfen sind eigene Partneridentität, eigener Partnerbereich, eigene Codes und Links, eigene Empfehlungen, eigene Nachweise und reduzierte Statussicht.

Negative Fälle sind:

• fremde Empfehlung,
• fremde Abrechnung,
• Partnercode als alleiniger Zugriffsschlüssel,
• Selbstfreigabe einer Vergütung.

Provision und Auszahlung bleiben vollständig gesperrt.

Rolle C · Assistenz

Zu prüfen sind gültige Zuweisungen, Tagesaufgaben, interne Hinweise, Fortsetzungsakten und begrenzte Objekt- oder Vorgangssichten.

Negative Fälle sind:

• abgelaufene Zuweisung,
• fremder Vorgang,
• Rollenwechsel ohne Neubewertung,
• unzulässige Vollakte.

Eine Assistenzzuweisung ist keine pauschale Vollmacht.

Sommer- und Winterzeit in Europe/Berlin

Die fachliche Tageslogik verwendet Europe/Berlin.

Geprüft werden Sommerzeit, Winterzeit, Zeitumstellung, Mitternachtswechsel und UTC-Umrechnung.

Das Berliner Datum bestimmt den Tages-Key. UTC bleibt der technische Primärzeitpunkt.

Beide Darstellungen müssen denselben realen Zeitpunkt abbilden. Widersprüche erzeugen einen Konfigurations- oder Nachweisbefund.

Zeittests an kritischen Übergängen

Sinnvolle Testfälle sind:

• Lauf kurz vor Mitternacht,
• Abschluss nach Mitternacht,
• Rollenwechsel am selben Tag,
• Zeitumstellung im Frühjahr,
• Zeitumstellung im Herbst.

Es dürfen weder doppelter Tag noch verlorener Lauf, falscher Tages-Key oder widersprüchlicher Protokollzeitpunkt entstehen.

Sichtbare Zeiten müssen in Benutzeroberfläche, PDF und Arbeitsprotokoll übereinstimmen.

Rollback praktisch prüfen

Der Pilot ist erst betrieblich belastbar, wenn ein absichtlich fehlerhafter Installations- oder Aktivierungslauf kontrolliert zurückgebaut wurde.

Geprüft werden:

• Fehlererkennung,
• Schreibstopp,
• Wiederherstellung des bestätigten Vorgängerstands,
• Erhalt der Befund- und Auditdaten,
• Verifier nach dem Rückbau,
• Browserfunktion nach dem Rückbau.

Ein dokumentierter Rollbackplan allein reicht nicht aus. Die Rückbauprobe muss reproduzierbar nachgewiesen sein.

Rückbau darf Nachweise nicht vernichten

Rollback stellt den funktionsfähigen Programmstand wieder her.

Er löscht jedoch weder Auditspur noch Fehlerbericht, Installationsquittung, ursprünglichen Befund oder Rückbauquittung.

Neue, noch nicht bestätigte Dateien werden entfernt. Bestehende Dateien werden aus dem gesicherten Vorgängerstand wiederhergestellt.

Der Rückbau selbst erzeugt ein revisionsfähiges Ereignis.

Cron- und Agentenbetrieb

Für Ebene 3 werden Cron-Trigger, Agentenannahme, Lease, Heartbeat, Timeout, Retry, Backoff, Dead Letter und Finalisierung geprüft.

Ein Lauf darf nicht bei 99 Prozent hängen bleiben.

Cron gibt ausschließlich den Takt vor. Der Agent überwacht. Der QM-Service bewertet. S•U•S•I erklärt.

Agent und Cron dürfen keine fachliche oder wirtschaftliche Freigabe erzeugen.

Abnahme der Benutzeroberfläche

Die Einladung darf den Arbeitsraum nicht dominieren. Sie muss kompakt, verständlich, barrierearm und responsiv sein.

Alle drei Entscheidungswege bleiben erreichbar. Ein Seitenwechsel darf keinen erneuten Dialog erzeugen.

Der gewählte Zustand bleibt für den aktuellen Tageskontext erhalten.

Fortschrittsanzeige

Während des Laufs wird ein sichtbarer Fortschritt angezeigt.

Der Nutzer erkennt Kontextprüfung, Funktionsprüfung, Neutraltest, Finalisierung und PDF-Erzeugung.

Ein reiner Endlosspinner ist nicht ausreichend. Timeout und Fortsetzung werden verständlich erklärt.

Stellungnahme und Tagesgruß

Die Stellungnahme muss die zentrale Frage beantworten:

Kann ich sicher weiterarbeiten?

Der Tagesgruß führt anschließend in den normalen Arbeitsablauf zurück.

Grün zieht sich kompakt zurück. Gelb nennt den offenen Punkt. Rot benennt Kategorie, betroffene Funktion, weitere Nutzbarkeit und nächste Maßnahme.

Responsives Verhalten

Die Pilotoberfläche wird auf Desktop, Tablet und Smartphone geprüft.

Texte dürfen nicht abgeschnitten werden. Schaltflächen müssen bedienbar bleiben. Ampeln und Statusinformationen dürfen nicht ausschließlich über Farbe vermittelt werden.

PDF- und Protokolllinks bleiben auf allen Geräten erreichbar.

Abnahme der vollständigen Nachweisstrecke

Für einen abgeschlossenen Lauf müssen folgende Schichten zusammenpassen:

• Daily State,
• Run,
• Events,
• Findings,
• S•U•S•I-Stellungnahme,
• PDF,
• Arbeitsprotokoll,
• Payload-Hash,
• PDF-Hash.

Ein fehlendes Glied verhindert die vollständig grüne Abnahme.

Die gesamte Kette wird anhand einer konkreten Run-ID kontrolliert.

Altstände und Revisionen

Eine Neubewertung erzeugt neue Run- oder Revisions-ID, neue Ereignisse, neue Stellungnahme, neue PDF und neue Hashes.

Der frühere Stand bleibt erhalten.

Der Pilot muss mindestens einen Vorgänger-Nachfolger-Fall nachweisen. Stilles Überschreiben ist ein No-Go.

Download- und Zugriffsschutz

PDF und Detailprotokoll dürfen nicht über erratbare IDs frei abrufbar sein.

Geprüft werden Authentifizierung, Mandant, Rolle, Capability und Scope.

Der Abruf kann als eigenes Ereignis protokolliert werden. Der ausgelieferte Dateihash muss zur registrierten Fassung passen.

Fachliche Negativabnahme · Heute nicht

Wählt der Nutzer Heute nicht, wird erwartet:

• kein technischer Lauf,
• keine erneute gewöhnliche Einladung,
• keine Zugangssperre,
• kein negativer Nutzerstatus,
• kein arbeitsrechtlicher oder wirtschaftlicher Effekt.

Die Ereignisspur lautet:

offered → declined

Fachliche Negativabnahme · Später erinnern

Wählt der Nutzer Später erinnern, wird erwartet:

• normale Systemnutzung,
• höchstens eine erneute Erinnerung,
• keine Pop-up-Schleife,
• kein Fehlerstatus.

Die Ereignisspur lautet:

offered → deferred

Fachliche Negativabnahme · Technischer Fehler

Liefert ein Testdienst kontrolliert einen Fehler, wird erwartet:

• Rot-Technisch,
• wirtschaftliche Neutralität,
• klar benannte betroffene Funktion,
• weiterhin nutzbare andere Bereiche,
• vorbereiteter Retry oder Prüfauftrag.

Der technische Fehler darf nicht als persönlicher Nutzerfehler erscheinen.

Fachliche Negativabnahme · Nachweisfehler

Schlägt PDF- oder Hashbildung kontrolliert fehl, wird erwartet:

• Rot-Nachweis,
• keine automatische erneute Ausführung der Fachfunktion,
• Reparatur der Nachweisschicht,
• Erhalt des Altstands.

Fachliche Negativabnahme · Schutzverletzung

Wird ein fremder Mandanten- oder Ressourcenzugriff simuliert, wird erwartet:

• serverseitige Abweisung,
• Rot-Kritisch beziehungsweise erfolgreicher negativer Schutztest,
• Sperre der betroffenen Funktion,
• vollständige Auditspur,
• keine Datenoffenlegung.

Dieser Test ist zwingend für die Pilotfreigabe.

Go-Kriterien

Pilot 1.0 ist für den kontrollierten Echtbetrieb freigabefähig, wenn:

• die Nutzerführung verständlich und freiwillig arbeitet,
• keine Mitarbeiterbewertung möglich oder vorgesehen ist,
• Rollen A, B und C positiv und negativ geprüft sind,
• Mandanten-, Capability- und Scope-Grenzen serverseitig wirken,
• PDF, Payload, Run und Hash vollständig verbunden sind,
• die Wirtschaft nachweisbar LOCKED bleibt,
• Browserabriss, Reload und Fortsetzung funktionieren,
• die Berlin-Zeitführung korrekt ist,
• der Rollback praktisch bestanden wurde,
• kritische Befunde geschlossen oder ausdrücklich als No-Go behandelt sind.

No-Go-Kriterien

Kein Echtbetrieb erfolgt bei:

• Mandantenüberschreitung,
• ungesicherter Rollen- oder Scope-Bindung,
• fehlender Wirtschaftssperre,
• automatischer Produktivfreigabe,
• fehlender oder veränderbarer Auditspur,
• PDF ohne reproduzierbaren Hash,
• nicht kontrollierbaren Doppelstarts,
• verlorenen Läufen nach Browserabriss,
• fehlerhafter Zeitzuordnung,
• fehlendem Rückbau,
• Personen-, Leistungs- oder Anwesenheitsauswertung.

Abnahme ist kein Dauerfreibrief

Die Pilotabnahme gilt nur für die definierte Version, das festgelegte Funktionsregister, die benannten Rollen und Mandanten sowie den geprüften Umfang.

Relevante Änderungen können eine neue Teil- oder Gesamtprüfung erfordern.

Neue wirtschaftliche oder rechtliche Automatismen benötigen eine eigene Abnahme.

Das Pilot-Siegel wird nicht still auf spätere Erweiterungen übertragen.

Kontrollierter Echtbetrieb

Der Echtbetrieb beginnt mit wenigen benannten Konten, kontrollierten Mandanten, klaren Funktionsgrenzen, aktivem Monitoring und erreichbarer Rückfalloption.

Während eines Stabilisierungsfensters werden insbesondere Timeouts, Nachweislücken, Scopeabweichungen, PDF-Integrität, Nutzerverständlichkeit sowie Agenten- und Cronbetrieb beobachtet.

Fachliche Ausweitungen erfolgen erst nach einem stabilen Beobachtungszeitraum.