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

Phase 1–3 · Jetzt

Die aktuelle Entwicklungsstufe schafft zunächst die vollständige fachliche und technische Grundordnung.

Im Mittelpunkt stehen:

• die verbindliche Handakte,
• eine verständliche S•U•S•I-Kommunikation,
• eine einheitliche Benutzerführung,
• das revisionsfähige PDF 2.0,
• die vollständige Ereignis- und Arbeitsprotokollkette.

Die Handakte als verbindliche Grundlage

Die Handakte beschreibt Zweck, Schutzprinzipien, Rollen, Prüfebenen, Tagesprozess, Diagnosematrix, Nachweisführung, Governance und Abnahmekriterien.

Sie dient als fachliche Referenz, technische Sollordnung sowie Grundlage für UI-Texte, Tests und spätere Patches.

Neue Funktionen dürfen dieser Ordnung nicht still widersprechen. Abweichungen werden ausdrücklich dokumentiert und geprüft.

S•U•S•I-Verständlichkeit ausarbeiten

Die maschinelle Prüfung benötigt eine belastbare menschliche Erklärungsschicht.

Deshalb werden verständliche Aussagen für Einladung, Prüffortschritt, Grün, Gelb, die vier Rot-Kategorien, nächste Maßnahmen und wirtschaftliche Neutralität definiert.

Jede Aussage muss aus strukturierten Prüfdaten ableitbar sein. Unbelegte Freitextfantasie bleibt ausgeschlossen.

Ziel ist eine ruhige, reproduzierbare Fachsprache, die unmittelbar beantwortet:

• Was wurde geprüft?
• Was ist nutzbar?
• Besteht ein Risiko?
• Was geschieht jetzt?
• Wo liegt der Nachweis?

Die Benutzerführung vereinheitlichen

Das Tages-QM erhält eine konsistente Nutzerstrecke:

Angebot → Erklärung → Entscheidung → Lauf → Stellungnahme → Protokoll → Tagesgruß

Die Oberfläche bleibt kompakt, freiwillig, verständlich, responsiv und nicht alarmistisch.

Jetzt starten, Später erinnern und Heute nicht werden technisch und sprachlich eindeutig behandelt.

Das QM darf den übrigen S•U•S•I-Tagesablauf nicht dominieren.

PDF 2.0 als revisionsfähige Prüfakte

Das PDF wird zu einem mehrschichtigen Protokollmodell ausgebaut.

Vorgesehen sind:

• Kundenlesefassung
• technische Prüffassung
• Revisionsfassung

Die Kundenlesefassung erklärt den Systemzustand. Die technische Fassung dokumentiert Funktionen, Soll-Ist-Abweichungen und Befunde. Die Revisionsfassung bindet Run-ID, Mandant, Rolle, Versionen, UTC- und Berlin-Zeit, Payload-Hash und PDF-Hash.

Jede erzeugte PDF bleibt unveränderlich. Eine Neubewertung erzeugt eine neue Revision.

Arbeitsprotokoll und Ereignisspur schließen

Tageszustand, Ereignisse, PDF und Arbeitsprotokoll werden eindeutig miteinander verbunden.

Jeder relevante Schritt erhält Run-ID, Ereignistyp, Zeitpunkt, Kontext und Payload-Hash.

Nutzerentscheidung, technischer Laufstatus und fachlicher Befund bleiben getrennt. Eine Ablehnung darf niemals als technischer Fehler gespeichert werden.

Der Abschluss der ersten Entwicklungsstufe verlangt eine lückenlose Nachweiskette.

Ergebnis der Phasen 1–3

Am Ende der aktuellen Stufe liegen vor:

• vollständige Handakte,
• abgestimmte 30-Schautafel-Struktur,
• freigegebene S•U•S•I-Terminologie,
• definierte Diagnosetexte,
• PDF-2.0-Sollmodell,
• Arbeitsprotokollordnung,
• Ereignis- und Revisionsvertrag,
• fachliche Pilotabnahmekriterien.

Diese Stufe schafft noch keine unkontrollierte Automatik. Sie schafft die verlässliche Grundlage für deren spätere Prüfung.

Phase 4–6 · Bald

Die mittlere Entwicklungsstufe härtet die Tageslogik und bereitet den späteren Schattenbetrieb vor.

Im Mittelpunkt stehen First-Login-Logik, stabiler Tages-Key, Doppelstartschutz, sichere Fortsetzung, manuelles Vor-Dienstbeginn-Angebot, widerrufbare Zustimmungsstruktur und die praktische Validierung der Rollenregister A, B und C.

Die Logik des ersten Logins schärfen

Der Tagescheck darf nicht bei jedem Seitenwechsel erneut erscheinen.

Die Triggerlogik wird vollständig an den gebundenen Tageszustand gekoppelt.

Der Tages-Key umfasst:

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

Geprüft werden vorhandener Tagesstatus, laufender Vorgang, sichere Fortsetzung und relevante Kontextwechsel.

Ein einfacher Reload erzeugt keinen neuen Lauf. Rollen-, Mandanten- oder relevante Versionsänderungen können dagegen einen neuen Prüfanlass begründen.

Doppelstarts und Wiederholungen verhindern

Für denselben Tages-Key darf nur ein aktiver Lauf bestehen.

Wiederholte Klicks, Tabs oder Requests werden idempotent behandelt. Browserabriss und Reload führen zur sicheren Fortsetzung statt zu einem parallelen Neustart.

Verwaiste Läufe werden kontrolliert erkannt. PDF und Arbeitsprotokoll dürfen nicht doppelt erzeugt werden.

Diese Betriebsfestigkeit ist Voraussetzung für jede spätere Automatisierung.

Fortsetzungsakte praktisch erproben

Der laufende QM-Prozess wird gegen reale Unterbrechungen geprüft.

Testfälle sind:

• Seitenreload,
• Browser schließen,
• erneute Anmeldung,
• Gerätewechsel,
• Rollenwechsel,
• Sitzungsablauf.

Die Fortsetzung bleibt an Run-ID, Nutzer, Mandant, Rolle, Versionen und letzten sicheren Prüfschritt gebunden.

Fremde oder veraltete Fortsetzungsstände werden abgewiesen.

Manuelles Angebot vor Dienstbeginn

Vor einer Vollautomatik wird zunächst nur ein manuelles Angebot erprobt.

S•U•S•I kann vor einem geplanten Dienstbeginn auf den Tagescheck hinweisen. Der Lauf beginnt jedoch erst nach einem ausdrücklichen Klick.

Dadurch wird geprüft:

• Ist der Zeitpunkt sinnvoll?
• Ist die Einladung verständlich?
• Ist der Lauf rechtzeitig abgeschlossen?
• Stört er den Tagesbeginn?

Ein einmaliger Start erzeugt keine dauerhafte Zustimmung.

Zustimmung rollen- und mandantenbezogen vorbereiten

Eine spätere Automatik benötigt eine ausdrückliche und widerrufbare Zustimmung.

Diese Zustimmung wird nicht global gespeichert. Sie gilt nur für einen Nutzer, einen Mandanten, eine Rolle, eine definierte Automatik und eine bestimmte Regelversion.

Ein Rollen- oder Mandantenwechsel übernimmt die Zustimmung nicht.

Der Nutzer kann jederzeit auf das normale freiwillige Modell zurückkehren.

Rollen A, B und C praktisch verifizieren

Vor dem Schattenbetrieb werden die rollenbezogenen Funktionsregister praktisch geprüft.

Für A · Makler stehen Leitstand, Objektzugang, Anfragen, Rückrufe und Termine im Mittelpunkt.

Für B · Empfehlungspartner werden Partnerbereich, eigene Codes, eigene Empfehlungen und Kommunikationswege geprüft.

Für C · Assistenz werden Zuweisungen, Tagesaufgaben, Hinweise und Fortsetzungsakten geprüft.

Für jede Rolle werden positive und negative Scope-Tests durchgeführt.

Erst danach ist eine automatische Hintergrundbewertung fachlich belastbar.

Ergebnis der Phasen 4–6

Am Ende der mittleren Stufe sind nachgewiesen:

• saubere First-Login-Logik,
• stabiler Tages-Key,
• Doppelstartschutz,
• Fortsetzung nach Browserabriss,
• manuelles Vor-Dienstbeginn-Angebot,
• widerrufbare Zustimmungsstruktur,
• validierte Rollenregister A/B/C,
• konsistente Berliner Zeitführung.

Die Automatik bleibt weiterhin ausgeschaltet. Die technische und organisatorische Grundlage für den Schattenbetrieb ist nun vorhanden.

Phase 7–9 · Später

Die letzte Roadmap-Stufe führt schrittweise vom wirkungslosen Schattenbetrieb zur kontrollierten Automatisierung.

Auch hier gilt: Automatisierung ist kein Konfigurationsschalter, sondern das Ergebnis einer eigenen fachlichen, technischen und betrieblichen Abnahme.

Automatisierungsfreigabe als eigener Abnahmeschritt

Vor einer Vollautomatik sind erforderlich:

• fachliche Freigabe,
• technische Prüfung,
• Datenschutz- und Governance-Prüfung,
• Rollen- und Mandantentest,
• Rückfallkonzept,
• reale Browserabnahme.

Die Automatisierungsfreigabe erhält eine eigene Version, einen benannten Akteur, einen dokumentierten Grund und eine eigene Auditspur.

Ohne diese Freigabe bleibt der automatische Start gesperrt.

Cron zunächst im Schattenbetrieb

Cron läuft zunächst ohne produktive Nutzerwirkung.

Im Schattenbetrieb wird geprüft:

• ob Aufträge korrekt geplant würden,
• welche Mandanten und Rollen betroffen wären,
• ob Zeitquellen stimmen,
• ob Doppelstarts verhindert werden,
• welche Ergebnisse entstanden wären.

Es werden keine persönlichen Tagesläufe produktiv ausgelöst, keine Nutzerhinweise erzwungen und keine fachlichen oder wirtschaftlichen Zustände verändert.

Die Ergebnisse dienen ausschließlich der Abnahme und Feinjustierung.

Mehrere Tage Schattenbetrieb

Ein einzelner erfolgreicher Cron-Lauf genügt nicht.

Der Schattenbetrieb wird über mehrere Tage beobachtet. Geprüft werden unterschiedliche Wochentage, mehrere Mandanten, Rollen A/B/C, Sommer- und Winterzeitlogik, Dienstplanänderungen, Unterbrechungen sowie Worker- und Agentenverhalten.

Wiederkehrende Abweichungen müssen vor der Aktivierung geschlossen werden.

Die mehrtägige Prüfung verhindert eine Freigabe aufgrund eines zufällig grünen Einzellaufs.

Agentenaufsicht vollständig aktivieren

Vor dem produktiven Cronbetrieb müssen Leases, Heartbeats, Timeout-Erkennung, Wiederaufnahme, Retry, Backoff, Dead Letter und Finalisierung zuverlässig funktionieren.

Der Agent überwacht, entscheidet aber nicht fachlich.

Ein Lauf darf weder unbemerkt hängen noch doppelt starten oder ohne Abschlussstatus verschwinden.

Der Agent darf keine Produktiv- oder Wirtschaftswirkung freigeben.

Cron kontrolliert produktiv aktivieren

Nach bestandener Schattenabnahme kann Cron schrittweise aktiviert werden.

Die Reihenfolge lautet:

1. einzelne interne Testnutzer,
2. ausgewählte Mandanten,
3. einzelne Rollenprofile,
4. kontrollierte Erweiterung.

Ein Big-Bang-Rollout ist ausgeschlossen.

Bei kritischen Befunden wird Cron deaktiviert, auf das freiwillige Tagesmodell zurückgefallen und der Befund vollständig analysiert.

Automatischer Vor-Dienstbeginn-Lauf

Ein persönlicher automatischer Lauf erfolgt nur bei ausdrücklicher Zustimmung, eindeutiger Rolle, eindeutigem Mandanten, verlässlicher Zeitquelle und gültiger Registerversion.

Ohne sicheren Kontext findet kein Blindstart statt.

Die Prüfung bleibt neutral, wirtschaftlich LOCKED, revisionsfähig und arbeitsrechtlich neutral.

Beim späteren Login erhält der Nutzer eine sichtbare Stellungnahme.

Der automatische Lauf ist kein Anwesenheitsnachweis.

Aktiver Cron ersetzt den Tagescheck nicht

Auch nach der Aktivierung bleibt die Trennung bestehen:

• Cron prüft den systemischen Zustand.
• Der Tagescheck bestätigt den konkreten Nutzerkontext.

Hintergrundbefunde können den Tagescheck verkürzen. Sitzung, Rolle, Mandant und persönliche Zuweisungen werden dennoch individuell geprüft.

Keine Ebene ersetzt die andere.

Trenddaten und Qualitätskennzahlen ausbauen

Nach stabilem Betrieb können systemische Kennzahlen weiterentwickelt werden.

Zulässig sind beispielsweise Abschlussquote, Timeout-Quote, PDF- und Hashquote, Laufdauer, Retry- und Dead-Letter-Quote sowie Häufigkeit technischer Befundklassen.

Die Auswertung bleibt funktionsbezogen, mandantenbezogen, versionsbezogen und systembezogen.

Nutzer-Rankings und Leistungsbewertungen bleiben ausgeschlossen.

Schutzregeln über alle Phasen

Keine Entwicklungsstufe lockert die Grundprinzipien.

In jeder Phase gelten:

• Tagesprüfung bleibt freiwillig,
• Sicherheit arbeitet Fail-Closed,
• Neutraltest bleibt bei 0,00 EUR,
• Wirtschaftsmodus bleibt LOCKED,
• keine automatische Produktivfreigabe,
• keine Mitarbeiterbewertung,
• keine stillen Änderungen,
• vollständige Auditspur,
• neue Revision statt Überschreibung.

Jede Phase besitzt eine eigene Abnahme

Die fachliche Abnahme prüft Verständlichkeit, Freiwilligkeit, Rollenpassung und den Ausschluss jeder Personenbewertung.

Die technische Abnahme prüft Mandant, Rolle, Capability, Scope, Run-ID, Hash und Idempotenz.

Die betriebliche Abnahme prüft Browserabriss, Wiederaufnahme, Zeitführung, Cron, Agent und Rückbau.

Ein Übergang ohne Nachweis ist nicht zulässig.

Rückfall bleibt jederzeit möglich

Jede automatisierte Ausbaustufe muss auf das vorherige stabile Modell zurückfallen können.

Beispielsweise:

Cron aktiv → kritischer Befund → Cron aus → freiwilliger Tagescheck bleibt nutzbar → Befund und Rückbau werden dokumentiert

Der Rückbau löscht keine Auditdaten, Protokolle, Fehlerspuren oder bestehenden Nachweise.

Er stellt ausschließlich den bestätigten Betriebszustand wieder her.

Die Roadmap als Reifeprozess

Die Entwicklungslogik lautet:

Verstehen → dokumentieren → manuell prüfen → stabil fortsetzen → Zustimmung speichern → im Schatten beobachten → kontrolliert automatisieren

Automatisierung ist das Ergebnis nachgewiesener Reife. Sie ist nicht der Ausgangspunkt.

Je höher der Automatisierungsgrad, desto stärker müssen Schutz, Nachweis, Fehlerbehandlung und Rückfall entwickelt sein.

Kein technischer Selbstzweck

Jede Entwicklungsstufe muss einen konkreten Nutzen schaffen.

Phase 1–3 schafft eine verständliche und nachweisbare Tagesprüfung.

Phase 4–6 schafft einen stabilen und kontextbezogenen Ablauf.

Phase 7–9 ermöglicht vorbeugende, kontrollierte Automatisierung.

Technik wird nicht erweitert, nur weil Automatisierung möglich ist. Sie wird erweitert, wenn Nutzen und Schutz nachgewiesen sind.

Der Mensch bleibt im Mittelpunkt

Auch in der letzten Automatisierungsstufe bleibt S•U•S•I erklärend, transparent und nicht kontrollierend.

Der Nutzer sieht, was geprüft wurde, welches Ergebnis vorliegt, was weiter nutzbar ist und wo sich der Nachweis befindet.

Automatisierung darf den Menschen nicht aus der Kommunikation ausschließen.

Sie soll technische Belastung reduzieren, nicht Entscheidungsfreiheit entziehen.

Das Abschlussbild der Roadmap

Phase 1–3 · Jetzt:
Handakte abschließen, Terminologie festlegen, S•U•S•I-Stellungnahmen definieren, PDF 2.0 ausarbeiten sowie Ereignis- und Revisionsmodell schließen.

Phase 4–6 · Bald:
First-Login-Logik härten, Tages-Key verifizieren, Fortsetzung stabilisieren, Vor-Dienstbeginn-Angebot manuell testen, Zustimmung vorbereiten und Rollen A/B/C praktisch validieren.

Phase 7–9 · Später:
Automatisierungsfreigabe, Cron-Schattenbetrieb, mehrtägige Abnahme, vollständige Agentenaufsicht, kontrollierte Aktivierung und technische Qualitätskennzahlen.

Langfristiger Zielzustand

Das System prüft regelmäßig seine technische Grundlage. Der konkrete Nutzer erhält zum Tagesstart eine verständliche und rollenbezogene Bestätigung.

Kritische Abweichungen werden früh erkannt. Kein Prüflauf erzeugt wirtschaftliche oder rechtliche Nebenwirkungen.

Jeder relevante Zustand bleibt revisionsfähig dokumentiert. Die Anwendung verbessert sich anhand ihrer eigenen technischen Qualitätsdaten.

Der Mensch bleibt von Leistungs- und Anwesenheitsbewertung ausgeschlossen.