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

Grün · Vollständig bestätigt

Eine Funktion wird nicht bereits grün, weil eine Seite geöffnet werden kann oder eine Route erreichbar ist. Grün setzt voraus, dass die gesamte vorgesehene Prüfkette erfolgreich durchlaufen wurde.

Dazu gehören mindestens:

• Funktion oder Route vorhanden,
• richtiges Ziel erreichbar,
• Mandant korrekt gebunden,
• Rolle gültig und passend,
• Capability vorhanden,
• Scope korrekt,
• Prozesszustand zulässig,
• technische Ausführung erfolgreich,
• Schutzbedingungen erfüllt,
• Abschluss und Nachweis vorhanden.

Grün bedeutet damit: Die Funktion ist im geprüften Kontext vollständig arbeitsbereit.

Der technische Baustein muss im tatsächlich aktiven Systemstand vorhanden sein. Dazu können Route, Controller, Service, Tabelle, View, API-Endpunkt oder Funktionsregistereintrag gehören. Eine bloße Planung, frühere Version oder nicht registrierte Komponente genügt nicht.

Auch die Zielbindung muss stimmen. Die Funktion darf nicht nur irgendeine Antwort liefern, sondern muss zum vorgesehenen Rollen- und Arbeitsziel führen. Der Makler erreicht seinen eigenen Leitstand, der Empfehlungspartner ausschließlich den eigenen Partnerbereich und die Assistenz nur gültig zugewiesene Aufgaben.

Eine Weiterleitung auf eine falsche Seite oder eine fremde Datenprojektion wäre kein grüner Befund.

Mandant und Rolle müssen ebenfalls eindeutig gebunden sein. Die aktive Rolle ist gültig, zeitlich wirksam, dem richtigen Mandanten zugeordnet und für die Funktion vorgesehen. Ein Ergebnis aus einem anderen Rollen- oder Mandantenkontext darf nicht übernommen werden. Mehrfachrollen werden nicht vereinigt.

Grün gilt deshalb immer nur für den konkret geprüften Kontext.

Zusätzlich müssen Capability und Scope erfüllt sein. Die aktive Rolle benötigt die erforderliche Berechtigung, und die aufgerufene Ressource muss zum zulässigen Datenraum gehören. Dazu können ein eigenes oder zugewiesenes Objekt, eine eigene Empfehlung, eigene Nachweise oder eine gültig delegierte Assistenzaufgabe gehören.

Fremde Ressourcen werden serverseitig abgewiesen. Eine sichtbare Schaltfläche ersetzt diese Prüfung nicht.

Grün bedeutet außerdem, dass die Funktion tatsächlich ausgeführt wurde. Der vorgesehene Prüfschritt wurde kontrolliert ausgelöst, das Soll-Ergebnis erreicht und der Vorgang mit einem definierten Abschluss beendet.

Offene Timeouts, Fehlerantworten, unklare Zwischenzustände oder unerledigte Folgeoperationen sind mit einem grünen Status nicht vereinbar. Ein lediglich begonnener oder hängender Prozess ist nicht grün.

Auch die Schutzbedingungen müssen vollständig bestätigt sein. Die Sitzung ist sicher, Mandanten- und Rollenbindung wirken Fail-Closed, Fremdscope ist ausgeschlossen, der Neutraltest verwendet 0,00 EUR und der Wirtschaftsmodus bleibt LOCKED.

Es entstehen keine Forderung, keine Provision, keine Auszahlung, keine Kundenbuchung und keine Produktivfreigabe. Grün bestätigt deshalb nicht nur die technische Ausführung, sondern auch die Schutzwirkung der Funktion.

Zum grünen Abschluss gehört schließlich eine belastbare Nachweisspur. Vorhanden sind mindestens Run-ID, Prüfzeitpunkt, Mandant, Rolle, Nutzer, geprüfte Version, Ergebnis, Nachweis-Hash und Quittung beziehungsweise Protokoll.

Ein funktionierender Vorgang ohne vollständige Auditspur ist nicht grün. Grün bedeutet daher: technisch erfolgreich und revisionsfähig belegt.

Praktisch beantwortet Grün die Frage:

Kann ich diese Funktion in meinem aktuellen Arbeitskontext sicher und nachvollziehbar verwenden?

mit:

Ja. Die Funktion ist vorhanden, erreichbar, geschützt, ausführbar und vollständig nachgewiesen.

Ein grüner Befund erzeugt normalerweise keinen weiteren Handlungsbedarf. Die Funktion bleibt regulär nutzbar. Eine erneute Prüfung wird erst bei neuem Tageskontext, relevanter Versionsänderung, verändertem Funktionsregister oder einem neuen technischen Befund erforderlich.

Gelb · Nutzbar, aber noch nicht vollständig bestätigt

Gelb bedeutet nicht automatisch, dass eine Funktion ausgefallen ist. Die Grundfunktion ist in der Regel vorhanden, erreichbar und grundsätzlich nutzbar. Es fehlt jedoch noch eine vollständige Bestätigung.

Ein Teilnachweis, eine vertiefte Prüfung oder eine fachliche Zuordnung kann offen sein. Solange kein unmittelbar erkennbares kritisches Risiko besteht, kann die Arbeit grundsätzlich fortgesetzt werden, soweit der konkrete Befund nichts anderes verlangt.

Ein gelber Status kann entstehen, wenn eine Funktion erreichbar, aber noch nicht vollständig im Browser abgenommen wurde, ein technischer Teilnachweis fehlt, Audit- oder Hashbezug noch vertieft geprüft werden müssen, eine nichtkritische Konfiguration unvollständig ist oder ein neuer Versionsstand noch nicht vollständig verglichen wurde.

Auch ein noch nicht dokumentierter negativer Prüffall oder eine nur teilweise abgeschlossene Pilotabnahme kann zu Gelb führen.

Gelb trennt bewusst zwischen vorhanden, technisch installiert und vollständig abgenommen. Eine Funktion kann vorhanden sein, ohne bereits vollständig belastbar zu sein.

Beispiele dafür sind:

• Route und Controller sind vorhanden, aber der negative Object-Scope-Test fehlt.
• Das Dashboard ist erreichbar, einzelne Datenquellen sind jedoch noch nicht Ende-zu-Ende bestätigt.
• Ein Nachweis liegt vor, die Quittungskette ist aber noch unvollständig.

Diese Differenzierung verhindert ein falsches Grün.

Gelb kann auch bedeuten, dass die fachliche Funktion arbeitet, aber ein ergänzender Nachweis offen bleibt. Dazu gehören etwa eine noch ausstehende Browserabnahme, Hashprüfung, Rollen-Negativprüfung, Wiederanlaufprüfung oder PDF-Verknüpfung.

Der Nutzer muss dabei nicht mit technischen Einzelheiten überladen werden. S•U•S•I erklärt knapp, was bereits funktioniert, welcher Nachweis noch fehlt und ob weitergearbeitet werden kann.

In anderen Fällen ist eine vertiefte Wirkungskontrolle erforderlich. Eine Zustellung kann funktionieren, während das Retry-Verhalten noch offen ist. Ein Dashboard kann korrekt lesen, während eine schreibende Folgeaktion noch nicht freigegeben ist. Eine Empfehlung kann angelegt werden, während jede wirtschaftliche Folge weiterhin gesperrt bleibt.

Gelb verhindert damit, dass eine Teilfunktion fälschlich als vollständig produktionsreif dargestellt wird.

Gelb darf nicht pauschal blockieren

Ein gelber Befund führt nicht automatisch zur Sperre des gesamten Arbeitsraums. Die Wirkung bleibt auf die betroffene Funktion begrenzt.

S•U•S•I benennt:

• was bereits nutzbar ist,
• welcher Teil offen bleibt,
• ob eine Einschränkung besteht,
• welcher nächste Schritt erforderlich ist.

Nicht betroffene Funktionen bleiben verfügbar. Das System vermeidet damit sowohl falsche Entwarnung als auch unnötige Alarmisierung.

Gelb benötigt eine konkrete Begründung

Unzureichend wäre:

Status: Gelb.

Erforderlich ist eine konkrete Einordnung, beispielsweise:

Der Makler-Leitstand ist erreichbar und mandantengebunden. Der negative Fremdobjekttest ist noch nicht vollständig dokumentiert. Die Lesesicht kann weiterverwendet werden; schreibende Objektaktionen bleiben bis zur Nachprüfung begrenzt.

Die Erklärung muss zur tatsächlichen Ursache passen. Gelb darf kein Sammelstatus für unklare oder unzureichend analysierte Zustände sein.

Jeder gelbe Befund benötigt einen fachlichen Befundcode und eine geeignete Maßnahme.

Mögliche Maßnahmen bei Gelb

Ein gelber Befund kann zu einer gezielten Nachprüfung, einem vollständigen Rollen-Audit, einer Browserabnahme, einem Negativtest, einer Hash- oder Quittungsprüfung, einer Konfigurationsprüfung oder einer Beobachtung im Hintergrund-QM führen.

Die Maßnahme richtet sich immer nach der Ursache. Gelb bedeutet nicht automatisch, dass sofort ein Reparaturpatch erforderlich ist. Es kann auch einen kontrollierten Beobachtungszustand kennzeichnen.

Gelb darf jedoch nicht dauerhaft ungeklärt bleiben. Jeder gelbe Status benötigt Ursache, Zuständigkeit, nächsten Schritt, Prüfziel und gegebenenfalls eine Frist.

Wiederkehrende gelbe Befunde werden im Audit oder Hintergrund-QM zusammengeführt. Daraus können technische Prüfaufträge, Priorisierungen, Folgepatches oder vertiefte Analysen entstehen.

Ein geklärter gelber Befund führt anschließend entweder zu Grün oder zu einer präziseren roten Klassifikation.

Der entscheidende Unterschied zwischen Grün und Gelb

Grün bedeutet:

• Funktion vorhanden,
• Ziel richtig,
• Schutz vollständig,
• Ausführung erfolgreich,
• Abschluss vorhanden,
• Nachweis vollständig.

Gelb bedeutet:

• Grundfunktion nutzbar,
• kein unmittelbar kritisches Risiko,
• aber mindestens eine Bestätigung, Vertiefung oder Nachweiskomponente ist offen.

Grün ist vollständige Bestätigung. Gelb ist kontrollierte Unvollständigkeit.

Beide Zustände sind fachlich sinnvoll, solange ihre Bedeutung klar und nachvollziehbar erklärt wird.

Gelb ist nicht „fast grün“ ohne Begründung

Gelb darf nicht als unscharfer Zwischenstatus verwendet werden. Es muss eindeutig feststehen, welches Kriterium nicht grün ist, warum der Befund nicht kritisch rot ist, welche Nutzung weiterhin zulässig bleibt und welche Maßnahme zur Klärung führt.

Der Status muss reproduzierbar aus Prüfdaten abgeleitet werden. Eine manuelle Bauchentscheidung ohne Nachweis ist unzulässig.

Grün darf nicht zu früh vergeben werden

Ein erfolgreicher HTTP-Aufruf genügt nicht. Eine sichtbare Karte genügt nicht. Ein vorhandener Datenbankeintrag genügt nicht. Auch ein einzelner positiver Standardfall genügt nicht.

Grün benötigt die vollständig definierte Prüftiefe. Fehlende Schutz-, Scope- oder Nachweisprüfungen dürfen nicht durch eine ansonsten funktionierende Oberfläche verdeckt werden.

Diese Regel verhindert Scheinsicherheit.

Bedeutung für Tagescheck, Audit und Hintergrund-QM

Im kurzen Tagescheck kann Grün bestätigen, dass die kritischen Tagesfunktionen bereitstehen. Gelb kann bedeuten, dass die Arbeit grundsätzlich möglich ist, ein nichtkritischer Teilnachweis offen bleibt und eine vertiefte Prüfung empfohlen wird.

Der Tagescheck muss nicht jeden gelben Befund unmittelbar vollständig lösen. Er kann ihn an Rollen-Audit, Hintergrund-QM oder einen technischen Prüfauftrag übergeben.

Der Nutzer erhält dennoch eine klare und ruhige Tagesstellungnahme.

Im vollständigen Rollen-Audit wird Gelb genauer untersucht. Dabei wird festgestellt, welche Prüfstufe offen ist: Vorhandensein, Erreichbarkeit, Ausführung, neutraler Soll-Ist-Test oder Auditspur.

Das Hintergrund-QM erkennt wiederkehrende gelbe Befunde, versionsbezogene Muster, ähnliche technische Schwächen und offene Nachweise. Diese Auswertung dient der Systemverbesserung und nicht der Bewertung einzelner Nutzer.

Wiederkehrendes Gelb kann auf Konfigurationsdrift, fehlende Negativtests, instabile Dienste oder unvollständige Nachweisketten hinweisen.

Die Rolle von S•U•S•I

Der QM-Service liefert die strukturierten Prüfergebnisse. S•U•S•I formuliert daraus eine verständliche Stellungnahme.

Sie benennt Gesamtstatus, geprüfte Funktionen, offenen Punkt, praktische Auswirkung, nächste Maßnahme und den Ort des Nachweises.

S•U•S•I erfindet keine freie Bewertung. Die Stellungnahme muss aus den dokumentierten Prüfdaten ableitbar bleiben.

Eine grüne Stellungnahme kann lauten:

Die für den heutigen Maklerkontext benötigten Kernfunktionen sind erreichbar, mandantengebunden und geschützt. Sitzung, Dashboard, Objektzugang und Neutraltest wurden vollständig bestätigt. Der Wirtschaftsmodus blieb gesperrt. PDF und Arbeitsprotokoll wurden erzeugt.

Eine gelbe Stellungnahme kann lauten:

Die benötigten Kernfunktionen sind grundsätzlich nutzbar. Für den Objektzugang fehlt noch die vollständige Dokumentation des negativen Fremdobjekttests. Es besteht derzeit kein unmittelbares Kunden- oder Wirtschaftsrisiko. Die vertiefte Prüfung wurde als Auditauftrag vorgemerkt.

Beide Aussagen gehen über eine bloße Ampelfarbe hinaus und schaffen Orientierung, ohne unnötig zu alarmieren.

Daten- und Statuslogik

Der Gesamtstatus wird aus den Einzelbefunden berechnet. Berücksichtigt werden Pflichtgrad, Schutzrelevanz, Funktionsstatus, Nachweisstatus und wirtschaftliche Neutralität.

Ein KANN-Befund darf nicht ohne Weiteres den gesamten Tagesstatus auf Gelb setzen. Ein offener MUSS-Nachweis kann Gelb oder bei Schutzwirkung Rot erzeugen.

Die Bewertungsregeln müssen versioniert sein. Neue Regeln dürfen alte Nachweise nicht rückwirkend verändern.

Nachweis und Revision

Grün und Gelb werden jeweils mit Run-ID, Befundcode, Funktionsbezug, Pflichtgrad, Klartextgrund, Maßnahme, Hash und Version dokumentiert.

Ein späterer grüner Befund löscht den früheren gelben Befund nicht. Er ergänzt die Historie als neue Prüfung.

Dadurch bleibt nachvollziehbar, wann ein offener Punkt bestand und wie er geschlossen wurde.