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

Die maschinelle Ebene bleibt strukturiert

Der QM-Service liefert keine fertige Prosa, sondern geordnete Befundfelder. Dazu gehören beispielsweise:

• overall_status,
• technical_findings,
• critical_findings,
• evidence_findings,
• configuration_findings,
• economic_effect,
• neutral_test,
• payload_hash,
• geprüfte Funktionen,
• betroffene Funktionen,
• unbetroffene Funktionen,
• empfohlene Maßnahmen.

Diese Felder bilden die belegbare Ausgangslage. Jede fachliche Aussage muss auf mindestens ein solches Datenfeld zurückgeführt werden können.

Der strukturierte Befund bleibt als maschinenlesbare Quelle erhalten.

Der Gesamtstatus benötigt Kontext

Der Wert overall_status liefert die zusammenfassende Einstufung: Grün, Gelb, Rot-Kritisch, Rot-Technisch, Rot-Nachweis oder Rot-Konfiguration.

Der Gesamtstatus darf jedoch nicht isoliert ausgegeben werden. Er benötigt:

• eine belegte Ursache,
• einen konkreten Funktionsbezug,
• eine praktische Auswirkung,
• einen nächsten Schritt.

Ein roter Gesamtstatus bedeutet nicht automatisch, dass das gesamte System unbrauchbar ist. Die Stellungnahme muss erklären, ob ein einzelner Dienst, ein Arbeitsbereich oder der gesamte Arbeitskontext betroffen ist.

Technische Befunde werden in Arbeitswirkung übersetzt

Technische Befunde können HTTP 500, Timeout, nicht erreichbarer Service, fehlerhafte Route, ungültige Serverantwort, Queue- oder Workerproblem, Datenbankfehler oder Versionskonflikt sein.

Eine rein technische Meldung wie:

HTTP 500 im Callback-Service.

reicht für den Nutzer nicht aus.

Verständlicher ist:

Der Rückrufdienst konnte den Vorgang technisch nicht abschließen. Andere geprüfte Arbeitsbereiche sind davon nicht betroffen.

Die technische Präzision bleibt im Protokoll erhalten. Die Nutzeransicht erklärt die praktische Bedeutung.

Kritische Befunde verlangen eindeutige Sprache

Bei Schutzverletzungen darf die Stellungnahme nicht beschönigen. Dazu gehören beispielsweise eine nicht bestätigte Mandantenbindung, ein erreichbarer fremder Scope, eine unsichere Sitzung oder ein nicht gesperrter Wirtschaftsmodus.

Die Aussage muss klar benennen:

• welche Schutzbedingung verletzt ist,
• welche Funktion gesperrt wurde,
• ob ein Risiko bereits eingetreten ist,
• welche Eskalation erfolgt.

Gleichzeitig darf die Sprache keine unnötige Panik erzeugen. Eindeutigkeit und Ruhe gehören zusammen.

Wirtschaftliche Wirkung ausdrücklich benennen

Die Stellungnahme muss ausdrücklich erklären, ob eine wirtschaftliche Wirkung entstanden ist.

Im regulären QM-Lauf lautet das erwartete Ergebnis:

economic_effect = none

Neutraltest = 0,00 EUR

Wirtschaftsmodus = LOCKED

Daraus folgt die verständliche Aussage:

Es wurden keine Forderung, Provision, Auszahlung oder reale Kundenbuchung ausgelöst.

Diese Information ist besonders bei roten Befunden wichtig. Ein technischer Fehler darf nicht automatisch als wirtschaftlicher Schaden verstanden werden.

Kann die Neutralität nicht bestätigt werden, muss dies als kritischer Befund erscheinen.

Der Payload-Hash bindet Aussage und Nachweis

Der Payload-Hash verbindet strukturierte Prüfdaten, Stellungnahme, PDF, Arbeitsprotokoll und Datenbankquittung.

Dadurch kann später geprüft werden, ob die lesbare Aussage tatsächlich zum gespeicherten Befund gehört. Der Hash schützt vor stiller Veränderung.

Fehlt die Hashbindung, kann eine Funktion technisch gearbeitet haben, revisionsseitig ist der Vorgang jedoch unvollständig. Dieser Fall wird als Rot-Nachweis behandelt.

In der Nutzeransicht genügt der Hinweis, dass der Nachweis vollständig gebunden oder noch nicht vollständig bestätigt ist.

Die fünf Klartextfragen

Eine vollständige Stellungnahme beantwortet fünf zentrale Fragen:

1. Was wurde geprüft?
2. Was ist nutzbar?
3. Gibt es Risiken?
4. Was geschieht jetzt?
5. Wo liegt das Protokoll?

Was wurde geprüft?

Die Stellungnahme benennt den tatsächlichen Prüfumfang. Dazu gehören Rolle, Mandant, Prüfebene, Funktionsgruppen, App-Version und Funktionsregister-Version.

Die Aussage darf nicht pauschal lauten:

Das System wurde geprüft.

Besser ist:

Geprüft wurden der aktuelle Maklerkontext, die sichere Sitzung, der Makler-Leitstand, der Objektzugang, die Rückruffunktion und der wirtschaftlich neutrale Testlauf.

Der Nutzer erkennt dadurch, worauf sich der Status tatsächlich bezieht. Nicht geprüfte Funktionen dürfen nicht still als bestätigt erscheinen.

Was ist nutzbar?

Die Stellungnahme benennt ausdrücklich die bestätigten Funktionen. Dies ist besonders bei gelben und roten Befunden wichtig.

Sie kann beispielsweise erklären:

• Dashboard nutzbar,
• Objektlesesicht nutzbar,
• Rückruffunktion derzeit nicht verfügbar,
• PDF-Nachweis offen,
• übrige Arbeitsbereiche nicht betroffen.

Dadurch wird ein begrenzter Befund nicht als vollständiger Systemausfall missverstanden.

Die zentrale Nutzerfrage lautet:

Kann ich sicher weiterarbeiten?

Die Antwort muss konkret und handlungsbezogen sein.

Gibt es Risiken?

Die Stellungnahme trennt Risikoarten. Mögliche Aussagen sind:

• kein unmittelbares Risiko,
• technischer Ausfall ohne Daten- oder Wirtschaftswirkung,
• Nachweislücke,
• unvollständige Konfiguration,
• kritische Schutzverletzung.

Risiko darf nicht pauschal behauptet werden. Ein HTTP-500-Fehler ist nicht automatisch ein Mandantenrisiko. Ein fehlender Hash ist nicht automatisch ein wirtschaftlicher Schaden.

Eine Mandantenvermischung ist dagegen klar als kritisches Schutzrisiko zu benennen.

Was geschieht jetzt?

Jeder nicht vollständig grüne Befund benötigt eine nächste Maßnahme.

Dazu können gehören:

• Nachprüfung wird vorbereitet,
• technischer Retry wird ausgeführt,
• vollständiges Rollen-Audit wird empfohlen,
• Nachweisschicht wird repariert,
• Konfiguration wird ergänzt,
• betroffene Funktion bleibt vorsorglich gesperrt.

Die Stellungnahme erklärt auch, ob der Nutzer selbst handeln muss.

Häufig lautet die richtige Aussage:

Für Sie ist derzeit keine weitere Aktion erforderlich.

Dadurch wird technische Verantwortung nicht unnötig auf den Nutzer verlagert.

Wo liegt das Protokoll?

Die Stellungnahme verweist auf PDF-Quittung, Arbeitsprotokoll, Run-ID und gegebenenfalls einen Detailbefund.

Der Nachweis muss leicht auffindbar sein. Ein Status ohne zugängliches Protokoll ist unvollständig.

Link oder Pfad bleiben rollen- und mandantengebunden. Fremde Nutzer dürfen den Nachweis nicht allein über eine erratbare ID öffnen.

Feste Ordnung der Stellungnahme

Eine vollständige Stellungnahme folgt einer klaren Reihenfolge:

1. Kontext
2. Prüfumfang
3. Gesamtstatus
4. bestätigte Funktionen
5. Auffälligkeiten
6. Risiko und wirtschaftliche Wirkung
7. nächste Maßnahme
8. Nachweisstelle

Diese Ordnung schafft Vergleichbarkeit. Nutzer lernen, wo sie die wichtigste Information finden. Technische und fachliche Stellungnahmen bleiben über Versionen hinweg konsistent.

Zusätzliche Details können in einem aufklappbaren Bereich oder im PDF stehen.

Erst die Kernaussage, dann die Einzelheiten

Die wichtigste Antwort gehört an den Anfang.

Beispielsweise:

Sie können im aktuellen Maklerkontext grundsätzlich sicher weiterarbeiten. Die Rückruffunktion ist technisch nicht verfügbar; alle übrigen geprüften Tagesfunktionen stehen bereit.

Danach folgen Ursache, Maßnahme und Nachweis.

Eine lange technische Vorrede würde die praktische Kernfrage verdecken. Die Stellungnahme folgt deshalb dem Prinzip:

Wirkung zuerst, technische Einzelheit danach.

Ruhige Fachsprache

Die Sprache soll sachlich, klar, nicht alarmistisch, nicht beschönigend und nicht technokratisch sein.

Zu vermeiden sind Katastrophensprache, Schuldzuweisungen, unklare Floskeln, unbelegte Gewissheit und eine unnötige Häufung interner Begriffe.

Geeignet sind Formulierungen wie:

• bestätigt,
• nicht vollständig bestätigt,
• technisch nicht erreichbar,
• Nachweis offen,
• Schutzbedingung verletzt,
• weitere Prüfung vorbereitet.

Keine unbelegte Freitextfantasie

S•U•S•I darf keine zusätzliche Ursache erfinden.

Liegt als Befund lediglich ein Timeout vor, wäre folgende Aussage unzulässig:

Der Server war überlastet.

Eine Überlastung darf nur genannt werden, wenn sie belegt ist.

Korrekt ist:

Der Dienst hat innerhalb der vorgesehenen Zeit nicht geantwortet. Die genaue technische Ursache wird geprüft.

Die Stellungnahme unterscheidet zwischen festgestellt, wahrscheinlich und noch ungeklärt. Vermutungen werden als Vermutungen gekennzeichnet.

Keine freie Risikobewertung

Die Risikoeinstufung folgt einer versionierten Regelmatrix. Maßgeblich sind Befundkategorie, Pflichtgrad, betroffene Funktion, Schutzrelevanz, wirtschaftliche Wirkung und Datenreichweite.

Die Übersetzungs-Engine darf ein Gelb nicht eigenmächtig zu Rot verschärfen. Sie darf ein Rot-Kritisch nicht sprachlich zu einem bloßen Hinweis abschwächen.

Fachliche Bewertung und sprachliche Formulierung bleiben getrennte Schritte.

Keine Personenbewertung

Die Stellungnahme beschreibt ausschließlich System, Funktion, Kontext und Nachweis.

Unzulässig sind Aussagen über Arbeitsleistung, Geschwindigkeit, Anwesenheit, Sorgfalt, Verhalten oder Kooperationsbereitschaft.

Statt:

Sie konnten die Funktion nicht korrekt verwenden.

lautet die richtige Formulierung:

Die Funktion konnte im aktuellen Kontext technisch nicht abgeschlossen werden.

Rollen- und mandantenbezogene Sprache

Die Stellungnahme berücksichtigt den aktuellen Arbeitsraum. Ein Makler erhält andere Begriffe als ein Empfehlungspartner, eine Assistenz oder ein Super-Admin.

Die technische Kernbedeutung bleibt gleich. Im Maklerkontext geht es etwa um Objektzugang, Rückruf, Termin oder Exposé. Im Partnerkontext um eigene Empfehlung, Partnercode, Nachweis und reduzierte Statussicht. Im Assistenzkontext um Zuweisung, Tagesaufgabe und Fortsetzungsakte.

Dadurch bleibt die Aussage verständlich, ohne Fachgrenzen zu vermischen.

Zusätzlich muss klar sein, für welchen Mandanten der Befund gilt. Ein grünes Ergebnis aus Mandant A gilt nicht für Mandant B.

Ein Kontextwechsel erzeugt eine neue Stellungnahme statt einer stillen Übertragung.

Die Prüfebene bleibt sichtbar

Der Nutzer muss erkennen können, ob ein Ergebnis aus dem 15-Sekunden-Tagescheck, dem vollständigen Rollen-Audit oder dem Hintergrund-QM stammt.

Die Aussagekraft unterscheidet sich. Ein grüner Tagescheck bestätigt die kritischen Tagesfunktionen. Ein grünes Rollen-Audit bestätigt eine deutlich tiefere Funktionskette. Ein Hintergrundbefund beschreibt einen mandantenweiten technischen Zustand.

Die Stellungnahme darf diese Ebenen nicht gleichsetzen.

Beispiele nach Ampelstatus

Grün:

Die für den heutigen Maklerkontext benötigten Kernfunktionen wurden vollständig bestätigt. Sitzung, Mandantenbindung, Leitstand, Objektzugang und Neutraltest sind verfügbar und geschützt. Es entstand keine wirtschaftliche Wirkung. PDF und Arbeitsprotokoll wurden revisionsfähig hinterlegt.

Gelb:

Die benötigten Kernfunktionen sind grundsätzlich nutzbar. Für den Objektzugang fehlt noch die vollständige Bestätigung des negativen Fremdobjekttests. Ein unmittelbares Kunden-, Daten- oder Wirtschaftsrisiko wurde nicht festgestellt. Die vertiefte Prüfung wurde vorgemerkt.

Rot-Technisch:

Der Rückrufdienst konnte den Prüfvorgang technisch nicht abschließen. Ihre übrigen geprüften Arbeitsbereiche bleiben verfügbar. Es entstand keine wirtschaftliche Wirkung. Eine kontrollierte Fehleranalyse und Wiederholung wurden vorbereitet.

Rot-Nachweis:

Die Funktion wurde technisch abgeschlossen, die vollständige Verbindung zwischen Auditspur, PDF und Nachweis-Hash konnte jedoch nicht bestätigt werden. Die Nachweisschicht wird revisionsfähig geprüft. Die fachliche Nutzung bleibt entsprechend dem Pflichtgrad bestehen oder begrenzt.

Rot-Konfiguration:

Die Funktion ist technisch vorhanden, für den aktuellen Assistenzkontext fehlt jedoch eine gültige Zuweisung. Der Arbeitsbereich kann erst nach einer berechtigten Zuordnung geöffnet werden. Andere geprüfte Funktionen bleiben verfügbar.

Rot-Kritisch:

Die Mandantenbindung der betroffenen Funktion konnte nicht sicher bestätigt werden. Die Funktion wurde vorsorglich gesperrt. Eine Daten- und Schutzprüfung wurde unmittelbar eingeleitet. Andere eindeutig geschützte Arbeitsbereiche bleiben verfügbar.

Versionierung und Versiegelung

Jede Stellungnahme gehört zu einer Übersetzungsregel-Version, Befundmatrix-Version, App-Version und Funktionsregister-Version.

Dadurch bleibt nachvollziehbar, nach welchen Regeln sie erzeugt wurde. Neue Formulierungsregeln verändern alte PDFs nicht. Eine Neuberechnung erzeugt eine neue Revision.

Strukturierte Daten, Textfassung und PDF werden über Hashes miteinander verbunden. Der Text darf nach Abschluss nicht still geändert werden.

Korrekturen erfolgen transparent, mit neuer Revision und Verweis auf den Vorgänger.

Dadurch bleibt die Stellungnahme revisionsfähig und beweisbar.

Fallback bei fehlender Übersetzungsregel

Existiert für einen Befund keine freigegebene Textregel, darf S•U•S•I keine überzeugend klingende Aussage erfinden.

Ein sicherer Fallback lautet:

Für diesen technischen Befund liegt noch keine freigegebene fachliche Kurzbewertung vor. Die Detailprüfung wurde an die technische Verantwortung übergeben.

Der strukturierte Befund bleibt sichtbar. Der Status wird nicht verdeckt.

Eine fehlende Textvorlage ist ein Konfigurations- oder Nachweisproblem und kein Anlass für freie Erfindung.

Prüfung vor der finalen Bindung

Vor Abschluss wird kontrolliert:

• Sind alle Aussagen durch Prüfdaten belegt?
• Stimmen Ampel und Text überein?
• Ist die wirtschaftliche Wirkung korrekt benannt?
• Sind betroffene und unbetroffene Funktionen getrennt?
• Ist die nächste Maßnahme vorhanden?
• Ist die Protokollstelle benannt?
• Enthält der Text keine Personenbewertung?
• Sind Rolle und Mandant korrekt?
• Ist der Hash erzeugt?

Erst danach wird die Stellungnahme final gebunden.

Mehrsprachigkeit und Terminologie

Spätere Sprachfassungen müssen aus derselben strukturierten Quelle erzeugt werden. Die Übersetzung darf die fachliche Bedeutung nicht verändern.

Fachbegriffe werden zentral gepflegt. Statuswerte, Befundcodes und Hashes bleiben sprachunabhängig.

Die deutsche Fassung kann als führende Fachfassung dienen. Weitere Sprachen erhalten eigene versionierte Textbausteine.

Nutzen für Nutzer, Technik und Revision

Für den Nutzer beantwortet die Stellungnahme sofort die Frage, ob sicher weitergearbeitet werden kann. Sie trennt Systemfehler, Nachweislücke, Konfigurationsproblem und Schutzverletzung voneinander.

Sie macht wirtschaftliche Neutralität sichtbar, benennt den nächsten Schritt und verweist auf ein leicht auffindbares Protokoll.

Technik und Support arbeiten weiterhin mit präzisen Rohdaten. Der Run- und Befundbezug bleibt konsistent. Revision kann Text, Payload und Hash miteinander vergleichen.

Dadurch arbeiten Nutzer, Support, Technik und Revision mit derselben belegbaren Ausgangslage. Missverständnisse zwischen technischer und fachlicher Sprache werden reduziert.