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

Klassisches Qualitätsmanagement setzt häufig erst dann ein, wenn eine Störung bereits sichtbar geworden ist. Der Nutzer bemerkt ein Problem während eines konkreten Arbeitsvorgangs, der Prozess wird unterbrochen oder verzögert und erst anschließend beginnt die technische Suche nach Ursache, Auswirkung und Zuständigkeit. Das S•U•S•I-QM-Modell verlagert diesen Zeitpunkt nach vorn. Es prüft die technische Betriebsbereitschaft möglichst bevor eine Störung den realen Arbeitsablauf erreicht.

Die bisherige Konzentration auf einzelne technische Komponenten reicht dafür nicht aus. Eine erreichbare Route, ein antwortender Server oder ein vorhandener Controller bestätigen noch nicht, dass der konkrete Nutzer sicher arbeiten kann. Auch eine sichtbare Oberfläche ist noch keine vollständige Abnahme. Entscheidend ist, ob die Funktion im richtigen Mandanten, in der richtigen Rolle, mit gültiger Sitzung, zulässiger Capability und passendem Datenscope arbeitet. Erst diese Verbindung beschreibt den tatsächlichen Arbeitskontext.

Im reaktiven Modell werden Fehler oft erst während einer produktiven Handlung entdeckt. Ein Formular lässt sich nicht speichern, eine Rolle erreicht ihren Arbeitsbereich nicht, ein fremder Datensatz wird irrtümlich aufgelöst oder eine Quittierung bleibt unvollständig. Für den Nutzer entsteht dadurch unnötiger Zeitdruck. Er muss eine technische Störung erklären, obwohl er sie weder verursacht noch kontrollieren kann. Support und Technik arbeiten anschließend rückblickend, während wiederkehrende Schwachstellen möglicherweise längere Zeit unentdeckt bleiben.

Hinzu kommt, dass rein technische Meldungen dem Nutzer häufig keine ausreichende Orientierung geben. Begriffe wie Timeout, Controllerfehler, ungültiger Scope oder fehlender Hash benennen zwar einen technischen Zustand, beantworten aber nicht die entscheidenden Fragen des Arbeitsalltags: Kann weitergearbeitet werden? Welche Funktion ist betroffen? Welche Bereiche bleiben nutzbar? Besteht ein Kunden- oder Wirtschaftsrisiko? Muss der Nutzer selbst handeln? Qualitätsmanagement muss technische Befunde deshalb in verständliche Arbeitsinformationen übersetzen.

Das neue Zielbild bindet den Nutzer früher, aber freiwillig ein. S•U•S•I bietet vor oder während des Tagesstarts einen kurzen Systemcheck an. Der Nutzer kann den Lauf sofort starten, sich später erinnern lassen oder den Hinweis für den betreffenden Tag ausblenden. Keine dieser Entscheidungen erzeugt einen negativen Nutzerstatus oder eine Zugangssperre. Der Nutzer wird damit nicht zum Prüfobjekt, sondern zum informierten Beteiligten. Freiwilligkeit arbeitet Fail-Open, während Mandanten-, Rollen-, Sitzungs- und Wirtschaftsschutz unverändert Fail-Closed bleiben.

Im Mittelpunkt steht die Frage, ob der konkrete Nutzer heute in seinem Rollen-, Mandanten- und Sitzungskontext technisch arbeitsbereit ist. Der kurze Tagescheck konzentriert sich auf die für den aktuellen Arbeitstag wesentlichen Arbeits- und Schutzfunktionen und soll ungefähr 15 Sekunden benötigen. Komplexe Tiefenprüfungen werden nicht in diesen kurzen Lauf gedrängt, sondern dem vollständigen Rollen-Audit oder dem Hintergrund-QM zugeordnet. Dadurch bleibt der Tagesstart ruhig und zielgerichtet.

Die neue Diagnose betrachtet Technik nicht abstrakt, sondern kontextbezogen. Sie verbindet Benutzeridentität, company_id, Rollenbindung, aktiven Arbeitskontext, Sitzung, Capability, Objekt- oder Datensatz-Scope, Funktionsregister, App-Version und wirtschaftliche Sperren. Derselbe technische Dienst kann für einen Nutzer korrekt, für eine andere Rolle unzulässig, für einen fremden Mandanten gesperrt oder in einem veralteten Kontext nicht mehr maßgeblich sein. Qualität wird deshalb immer für den tatsächlich gebundenen Nutzungskontext festgestellt.

Ziel ist eine Frühwarnung ohne Alarmisierung. Fehlende Rollenrechte, falsche Mandantenbindungen, veraltete Sitzungen, nicht erreichbare Kernfunktionen, unvollständige Konfigurationen oder fehlende Nachweise sollen erkannt werden, bevor sie einen Kunden- oder Geschäftsvorgang beeinträchtigen. Gelbe Befunde zeigen einen offenen Prüf- oder Nachweisbedarf, ohne den Arbeitstag automatisch zu blockieren. Rote Befunde werden nach ihrer Ursache unterschieden, damit Schutzverletzungen, technische Ausfälle, Nachweislücken und Konfigurationsfehler jeweils die passende Maßnahme auslösen.

Nach dem Lauf formuliert S•U•S•I eine verständliche fachliche Stellungnahme. Sie benennt den geprüften Umfang, den verfügbaren Systemzustand, vorhandene Auffälligkeiten, betroffene und unbetroffene Funktionen sowie den nächsten technischen Schritt. Grün bestätigt die Tagesbereitschaft. Gelb beschreibt eine grundsätzlich nutzbare Funktion mit offenem Teilnachweis. Rot benennt einen konkreten kritischen, technischen, nachweisbezogenen oder konfigurativen Befund. Die Diagnose bleibt damit verständlich, ohne technische Sachverhalte zu vereinfachen oder zu verdecken.

Die Prüfung endet nicht mit einer flüchtigen Bildschirmanzeige. Der geprüfte Zustand wird revisionsfähig hinterlegt. Dazu gehören insbesondere Run-ID, Nutzer, Mandant, Rolle, Tagesdatum in Europe/Berlin, Start- und Endzeit, Versionsstände, Ergebnisstatus, Neutraltestergebnis, Wirtschaftsstatus, Nachweis-Hash, PDF-Protokoll und Arbeitsprotokolleintrag. Neue Bewertungen ersetzen frühere Nachweise nicht still, sondern erzeugen eine neue Revision. Dadurch bleibt nachvollziehbar, welcher Systemzustand zu welchem Zeitpunkt tatsächlich geprüft wurde.

Auch die wirtschaftliche Neutralität bleibt verbindlich. Der Test arbeitet mit 0,00 EUR und erzeugt keine Forderung, keine Provision, keine Auszahlung, keine Anerkennung, keinen realen Lead und keine Kundenbuchung. Der Wirtschaftsmodus bleibt im Status LOCKED. So kann die technische Kette geprüft werden, ohne den realen Geschäftsbetrieb zu verändern. Auch ein fehlgeschlagener Lauf bleibt wirtschaftlich folgenlos.

Das Modell trennt drei unterschiedliche Prüfebenen. Der kurze Tagescheck prüft freiwillig den aktuellen Nutzerkontext. Das vollständige Rollen-Audit untersucht die Funktions- und Nachweisketten in größerer Tiefe. Das Hintergrund-QM führt regelmäßige mandantenbezogene Prüfungen über Cron und Agentenüberwachung aus. Diese Ebenen ergänzen sich, ersetzen einander jedoch nicht. Gemeinsam bilden sie einen wiederholbaren Qualitätskreislauf aus Erkennen, Prüfen, Einordnen, Nachweisen und Verbessern.

Qualität wird damit nicht mehr nur nachträglich festgestellt. Sie wird täglich sichtbar, nachweisbar und verbesserbar gehalten. Der Schwerpunkt verlagert sich von isolierten technischen Einzelprüfungen zu einer freiwilligen, kontextbezogenen und verständlich erklärten Systemdiagnose. Der Nutzer erhält Orientierung, bevor Unsicherheit entsteht, und das System übernimmt die Verantwortung dafür, seine eigene Betriebsbereitschaft nachzuweisen.

Qualitätsmanagement wird von der nachträglichen Fehlerkontrolle zur freiwilligen, präventiven und nachweisbaren Diagnose der technischen Betriebsbereitschaft im aktuellen Nutzerkontext.