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

Die Auditprofile A, B und C

Das vollständige Audit arbeitet mit drei getrennten Rollenprofilen:

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

Jede Rolle besitzt ein eigenes versioniertes Funktionsregister. Darin sind die zu prüfenden Funktionen, Funktionsgruppen, Pflichtgrade, Prüfziele und erwarteten Nachweise festgelegt.

Der gemeinsame Schutzvertrag bleibt für alle drei Rollen gleich. Unterschiede bestehen bei Fachfunktionen, Capabilities, Datenreichweiten und den jeweiligen Objekt-, Referral- oder Zuweisungsscopes.

Ein Rollen-Audit bestätigt ausschließlich den konkret geprüften Rollen- und Mandantenkontext. Es ist keine pauschale Freigabe für andere Rollen, Mandanten oder Datenräume.

Vier aufeinander aufbauende Prüfstufen

Jede Funktion wird nicht nur mit einem einfachen Ja- oder Nein-Wert bewertet. Das Audit folgt vier aufeinander aufbauenden Stufen:

• Stufe I · Vorhandensein und Erreichbarkeit
• Stufe II · Auslösung, Annahme, Ausführung und Abschluss
• Stufe III · Neutraler Prüfvorgang und Soll-Ist-Bestätigung
• Stufe IV · Auditspur, Neutralität, Alarm und Rollenstatus

Die Stufen bauen fachlich aufeinander auf. Ein späterer Prüfschritt darf einen fehlenden früheren Nachweis nicht verdecken. Eine Funktion kann vorhanden sein, ohne vollständig ausführbar zu sein. Sie kann technisch laufen, ohne revisionsfähig nachgewiesen zu sein.

Das Audit trennt diese Zustände ausdrücklich voneinander.

Stufe I · Vorhandensein und Erreichbarkeit

Zunächst wird geprüft, ob die Funktion im System überhaupt vorhanden ist. Mögliche Funktionsanker sind Route, Controller-Einstieg, Dashboard-Karte, API-Endpunkt, Menü- oder Drawer-Ziel, Service-Registrierung oder Funktionsregistereintrag.

Das bloße Vorhandensein ist die niedrigste Prüfstufe. Es bestätigt noch keine vollständige technische Installation. Eine sichtbare Oberfläche oder vorhandene Route ist deshalb noch keine abgenommene Funktion.

Im nächsten Schritt wird geprüft, ob der Funktionsanker tatsächlich erreichbar ist. Dazu gehören HTTP-Erreichbarkeit, korrekte Middleware, gültige Authentifizierung, eine erwartbare Antwort sowie das Ausbleiben von Routingfehlern, falschen Weiterleitungen oder unerwarteten HTTP-500-Fehlern.

Das Audit prüft nicht nur, ob irgendeine Antwort zurückkommt. Es muss eine technisch kontrollierte und fachlich erwartete Antwort entstehen.

Anschließend wird bestätigt, dass das richtige Ziel erreicht wurde. Maßgeblich sind richtige Rolle, richtiger Mandant, richtige Funktion, richtige Ressource und richtige Datenprojektion.

Der Makler muss tatsächlich seinen Makler-Leitstand erreichen. Der Empfehlungspartner darf ausschließlich den eigenen Partnerbereich sehen. Die Assistenz darf nur auf zugewiesene Aufgaben zugreifen. Ein fremder oder falscher Datensatz darf nicht als erfolgreiche Erreichbarkeit gewertet werden.

Stufe I beantwortet damit die Frage: Ist die vorgesehene Funktion im richtigen Kontext vorhanden und erreichbar? Ein grüner Befund in dieser Stufe ist noch keine Gesamtfreigabe.

Stufe II · Auslösung, Annahme, Ausführung und Abschluss

In Stufe II wird geprüft, ob eine fachliche Aktion tatsächlich gestartet werden kann. Dazu können das Absenden eines Formulars, das Öffnen eines Rückrufs, das Einreichen einer Empfehlung, das Starten einer Fortsetzung oder das Auslösen eines Prüfauftrags gehören.

Eine sichtbare Schaltfläche allein genügt nicht. Der technische Aufruf muss korrekt verdrahtet, berechtigt, mandantengebunden und mit dem zulässigen Prozesszustand vereinbar sein.

Nach der Auslösung muss das System den Vorgang kontrolliert annehmen. Geprüft werden Requestvalidierung, Controllerannahme, Policy- und Capability-Prüfung, Mandanten- und Ressourcenscope, Idempotenz und Fehlerbehandlung.

Fremde IDs, falsche Rollen oder unzulässige Zustände müssen serverseitig abgewiesen werden. Die Annahme ist ein eigener Prüfschritt und wird getrennt von der späteren Ausführung bewertet.

Anschließend wird geprüft, ob Service oder Command die Aktion tatsächlich ausführt. Dazu gehören kontrollierter Zustandsübergang, korrekte Datenverarbeitung, richtige Zuordnung und das erwartete technische Ergebnis.

Die Funktion darf nicht nur scheinbar erfolgreich reagieren. Der tatsächliche Systemzustand muss dem erwarteten Ergebnis entsprechen. Fehler in Service, Datenbank, Queue, Controller oder externer Schnittstelle werden getrennt klassifiziert.

Eine Funktion ist erst dann vollständig ausführbar, wenn sie einen definierten Abschluss besitzt. Dieser kann als Receipt, Statuswechsel, Erfolgsantwort, Fortsetzungsakte, Abschlussprotokoll oder sichtbare Bestätigung vorliegen.

Der Abschluss muss eindeutig, idempotent, nachvollziehbar und dem richtigen Vorgang zugeordnet sein. Ein Prozess, der technisch beginnt, aber ohne kontrolliertes Ende hängen bleibt, ist nicht vollständig funktionsfähig.

Stufe II beantwortet die Frage: Kann die Funktion im zulässigen Kontext vollständig ausgelöst, angenommen, ausgeführt und abgeschlossen werden?

Stufe III · Neutraler Prüfvorgang und Soll-Ist-Bestätigung

In Stufe III wird ein kontrollierter Testauftrag angelegt. Dieser erhält eine eindeutige Run-ID, Rollen- und Mandantenbindung, Funktions- und Versionsbezug, Prüfmodus und ein definiertes Soll-Ergebnis.

Der Testauftrag muss klar von einem realen Fachvorgang getrennt bleiben. Er darf nicht unbemerkt in produktive Daten übergehen. Parallele oder doppelte Testaufträge werden verhindert.

Wirtschaftlich sensible Funktionen verwenden ausschließlich den neutralen Testwert von 0,00 EUR. Zusätzlich werden neutrale Kennungen und Testkontexte verwendet. Der Test darf keine Forderung, Provision, Gutschrift, Auszahlung oder Rechnung erzeugen.

Die Neutralität wird nicht nur in der Oberfläche erklärt. Sie muss im technischen Payload und in der Ausführungslogik nachweisbar sein.

Anschließend wird der eigentliche Prüfvorgang kontrolliert ausgeführt. Dabei werden die reale technische Kette und ihre Schutzmechanismen geprüft. Es entstehen keine echten Leads, Kundenbuchungen, Partneransprüche, Auszahlungen oder Produktivfreigaben.

Der Wirtschaftsmodus bleibt LOCKED. Kann die neutrale Durchführung nicht bestätigt werden, liegt ein kritischer Befund vor. Auch ein fehlgeschlagener Test darf keine wirtschaftliche Teilwirkung hinterlassen.

Nach der Ausführung wird das tatsächliche Ergebnis mit dem definierten Sollzustand verglichen. Geprüft werden erwarteter Status, erwartete Antwort, richtige Datenbindung, fehlende wirtschaftliche Wirkung, korrekter Abschluss und erwartete Folgeereignisse.

Abweichungen werden nicht pauschal als Fehler ausgegeben. Sie werden fachlich als technisch, kritisch, nachweisbezogen oder konfigurationsbedingt klassifiziert.

Stufe III beantwortet die Frage: Arbeitet die Funktion im neutralen Testfall genau so, wie sie fachlich und technisch vorgesehen ist?

Stufe IV · Auditspur, Neutralität, Alarm und Rollenstatus

Jeder relevante Auditlauf muss eine nachvollziehbare Ereignisspur erzeugen. Dokumentiert werden mindestens Run-ID, Nutzer, Rolle, Mandant, Funktionsregister-Version, App-Version, Start und Ende, Ergebnis, Befundklasse und Nachweis-Hash.

Eine Funktion, die technisch arbeitet, aber keine Auditspur erzeugt, ist revisionsseitig unvollständig. Dieser Zustand wird als Rot-Nachweis klassifiziert. Auditereignisse dürfen nachträglich nicht still verändert werden.

Die fehlende wirtschaftliche Außenwirkung wird nochmals ausdrücklich bestätigt. Nachgewiesen werden Neutraltest mit 0,00 EUR, economic_effect = none, Wirtschaftsmodus LOCKED sowie das Ausbleiben von Lead, Forderung, Provision, Auszahlung und Produktivfreigabe.

Diese Neutralitätsbestätigung gehört in Audit, Quittierung, PDF und S•U•S•I-Stellungnahme. Ohne diesen Nachweis darf der Auditlauf nicht vollständig grün abgeschlossen werden.

Das Audit prüft außerdem, ob erkannte Befunde korrekt weitergegeben werden. Ein grünes Ergebnis erzeugt keine unnötige Alarmierung. Gelb führt zu Nachprüfung oder Beobachtung. Rot-Technisch führt zu Fehleranalyse und Wiederholung. Rot-Nachweis zu Quittierungs- oder Hashreparatur. Rot-Konfiguration zu einer fehlenden Einrichtung oder Zuordnung. Rot-Kritisch zur Sperre der betroffenen Funktion und sofortigen Eskalation.

Alarmierung muss immer ursachenbezogen und verhältnismäßig sein. Eine Ampelfarbe allein reicht nicht aus.

Nach Abschluss wird der Rollenbefund aktualisiert. Gespeichert werden geprüfte Funktion, Prüfstufen, Pflichtgrad, aktueller Status, Befund, letzte erfolgreiche Prüfung, Version, Nachweis und offene Maßnahme.

Frühere Auditstände werden nicht still überschrieben. Neue Bewertungen erzeugen neue Revisionen oder Ereignisse. Die Historie bleibt vollständig nachvollziehbar.

Stufe IV beantwortet die Frage: Ist der vollständige Prüfvorgang neutral, revisionsfähig, angemessen eskaliert und im Rollenstatus nachvollziehbar abgeschlossen?

Pflichtgrade im Rollen-Audit

Das Funktionsregister unterscheidet zwischen MUSS, SOLL und KANN.

Eine MUSS-Funktion ist für die sichere Rollen- oder Tagesarbeit zwingend. Ein kritischer negativer Befund kann die betroffene Funktion sperren.

Eine SOLL-Funktion wird fachlich erwartet. Ein offener Nachweis ist jedoch nicht in jedem Fall unmittelbar blockierend.

Eine KANN-Funktion ist unterstützend oder optional. Ihr Ausfall führt nicht automatisch zu einer kritischen Gesamtbewertung.

Der Pflichtgrad beeinflusst Gesamtstatus, Maßnahme, Eskalation und Wiederholungsbedarf. Er darf jedoch niemals grundlegende Schutzregeln abschwächen.

Rollenprofil A · Makler

Das Makler-Audit kann unter anderem Makler-Leitstand, Objektmatrix, Objektakte, Widget-Nachweis, Anfragen, Rückrufe, Termine, NotificationCenter sowie Exposé- und Freigabestrecken prüfen.

Jede Funktion wird gegen Company-Scope, Object-Scope, Capability und zulässigen Prozesszustand geprüft. Fremde Mandanten und fremde Objekte müssen zuverlässig abgewiesen werden.

Rollenprofil B · Affiliate beziehungsweise Empfehlungspartner

Im Partnerkontext können Partnerbereich, Partneridentität, Partnercode, Widget- und Nachweisfunktionen, eigene Empfehlungen, Kommunikationswege, reduzierte Statusprojektion sowie Neutraltest und wirtschaftlicher Schutz geprüft werden.

Besondere Bedeutung haben Own-Scope, Referral-Scope, dauerhafte Partnerbindung, der Ausschluss von Selbstfreigabe und die fehlende automatische Auszahlung.

Der Partnercode bleibt ein Attributionsanker. Er ist kein Zugriffsrecht.

Rollenprofil C · Assistenz

Das Assistenz-Audit kann Zuweisungen, Tagesaufgaben, Kommunikationsfunktionen, Fortsetzungsakten, interne Hinweise sowie delegierte Objekt- oder Vorgangssichten prüfen.

Maßgeblich sind gültige Zuweisung, zeitliche Begrenzung, zulässiger Scope, fehlende Rechteunion und sichere Fortsetzung.

Eine Delegation ist keine pauschale Vollmacht.

Positive und negative Prüffälle

Ein vollständiges Rollen-Audit darf nicht nur den erfolgreichen Standardweg prüfen. Es benötigt auch negative Prüffälle, etwa falsche company_id, falsche Rolle, fremde Ressource, abgelaufene Zuweisung, unbekannte Capability, manipulierte Sitzung, parallelen Start, Browserabriss, Timeout oder fehlende Auditspur.

Ein Schutzmechanismus ist erst dann belastbar, wenn auch seine Abweisung reproduzierbar nachgewiesen wurde. Negative Tests sind deshalb kein Fehler des Audits, sondern ein wesentlicher Teil der Abnahme.

Laufsteuerung und Fortsetzung

Das Audit wird serverseitig gestartet und erhält eine eindeutige Run-ID. Die Prüfung arbeitet schrittweise, und jeder Schritt wird kontrolliert fortgesetzt. Parallelstarts werden verhindert.

Browserreload, Browserabriss oder Gerätewechsel dürfen einen gültigen Lauf nicht zerstören. Eine Fortsetzung muss dieselbe Run-ID, Rolle, Mandantenbindung und Registerversion verwenden.

Soft- und Hard-Timeouts verhindern endlose Läufe. Fremde oder veraltete Fortsetzungen werden abgewiesen.

Ergebnis- und Befundlogik

Grün bedeutet, dass eine Funktion vollständig vorhanden, erreichbar, ausführbar, geschützt, neutral und nachgewiesen ist.

Gelb bedeutet, dass die Grundfunktion vorhanden ist, aber ein Teilnachweis oder eine Vertiefung noch offen bleibt.

Rot-Kritisch bezeichnet eine Schutzverletzung mit möglicher Mandanten-, Rollen- oder Wirtschaftswirkung. Rot-Technisch beschreibt einen technischen Ausfall. Rot-Nachweis liegt vor, wenn Audit, Quittung oder Hash fehlen. Rot-Konfiguration kennzeichnet eine fehlende Einrichtung oder Zuordnung.

Jeder gelbe oder rote Befund benötigt einen Klartextgrund, eine Auswirkung, eine Risikoeinordnung und eine konkrete Maßnahme.

Keine automatische Produktivfreigabe

Ein erfolgreiches Rollen-Audit bestätigt die technische und fachliche Funktionsfähigkeit im geprüften Kontext. Es erzeugt jedoch keine wirtschaftliche Anerkennung, Provision, Auszahlung, rechtlich bindende Freigabe oder unkontrollierte Veröffentlichung.

Technische Prüfaufträge dürfen entstehen. Produktivfreigaben bleiben einem eigenen, berechtigten Abnahmeprozess vorbehalten.

Der Agent darf überwachen und Prüfaufträge erzeugen, aber keine ungeprüfte Freigabe vornehmen.

Revisionsfähiger Abschluss

Das vollständige Rollen-Audit erzeugt eine ausführliche Befundliste, Rollen- und Mandantenbezug, Prüfstufen je Funktion, Neutralitätsbestätigung, Auditereignisse, PDF, Hash, aktualisierten Rollenstatus und technische Folgeaufträge.

Jeder Lauf bleibt über seine Run-ID eindeutig identifizierbar. App-, Register-, Audit- und PDF-Version werden mitgeführt.

Eine neue Bewertung oder eine neue PDF erzeugt eine neue Revision. Der frühere Stand bleibt unverändert erhalten.