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

Was das System prüft

Das QM stellt fest, ob die für den aktuellen Arbeitstag erforderlichen Funktionen technisch erreichbar und im richtigen Kontext nutzbar sind. Dazu gehören eine gültige Sitzung, die richtige Mandantenbindung, der aktive Rollen- und Arbeitskontext, erforderliche Capabilities, sichere Datenscopes und eine funktionierende Quittierung.

Betriebsbereitschaft bedeutet dabei mehr als einen erfolgreichen Seitenaufruf. Die vollständige Kette aus Nutzer, Mandant, Rolle, Funktion, Schutz, Ergebnis und Nachweis muss stimmen. Ein technischer Befund darf dennoch niemals als Aussage über die persönliche Arbeitsleistung formuliert werden.

Zusätzlich prüft das System, ob die organisatorischen Schutzgrenzen korrekt wirken. Dazu zählen klare Rollenbindungen, zulässige Zuständigkeiten, aktive Zuweisungen, Mandanten- und Unternehmensgrenzen, Objekt-, Vorgangs- oder Own-Scopes, zeitliche Gültigkeit und sichere Kontextwechsel.

Diese Schutzlogik verhindert Fremdzugriffe, Rechtevermischung, unzulässige Vollaktenzugriffe, ungeprüfte Selbstfreigaben und wirtschaftliche Nebenwirkungen. Eine sichtbare Navigation genügt dafür nicht. Die Schutzentscheidung muss serverseitig und nachvollziehbar durchgesetzt werden.

Auch die Erreichbarkeit einer Funktion wird vollständig betrachtet. Route, Middleware, Controller, Service, Datenprojektion und sichtbare Antwort müssen zusammenwirken. Ein Menüpunkt allein ist kein Funktionsnachweis, und eine vorhandene Route ist noch keine vollständige Abnahme. Eine Funktion gilt erst dann als arbeitsbereit, wenn sie erreichbar, berechtigt, mandantengebunden, ausführbar und nachvollziehbar ist.

Das QM dokumentiert außerdem, welcher Systemzustand tatsächlich geprüft wurde. Die Auditspur kann Run-ID, Nutzer, Rolle, Mandant, Sitzung beziehungsweise Arbeitskontext, Prüfzeitpunkt, Ergebnis, Befundklasse, Neutraltest, Wirtschaftsstatus, Hash und PDF-Verweis enthalten. Diese Daten dienen Nachvollziehbarkeit, technischer Prüfung, Revision, Wiederholung und Fehleranalyse.

Sie dienen ausdrücklich nicht dem Mitarbeiter-Ranking, der Leistungskontrolle, Anwesenheitsüberwachung oder Verhaltensbewertung. Der Protokolleintrag bleibt ein Systemnachweis im Arbeitskontext.

Was das System nicht prüft

S•U•S•I bewertet weder die fachliche noch die persönliche Leistung eines Nutzers. Nicht geprüft werden die Qualität individueller Arbeit, die Anzahl erledigter Aufgaben, Umsatz, Erfolgsquote, Produktivität oder vermeintliche Zuverlässigkeit. Auch wiederkehrende technische Störungen dürfen nicht automatisch einer Person zugerechnet werden.

Das QM stellt fest, ob der digitale Arbeitsplatz funktioniert. Es stellt nicht fest, ob ein Beschäftigter gut, schnell oder erfolgreich arbeitet.

Das System misst auch nicht, wie schnell ein Nutzer Aufgaben erledigt, Seiten öffnet, Datensätze bearbeitet, Rückfragen beantwortet oder Vorgänge abschließt. Die Laufzeit eines QM-Tests betrifft ausschließlich die technische Ausführung. Reaktionszeiten von Diensten und Systemen dürfen technisch ausgewertet werden; Reaktionszeiten von Menschen dürfen daraus nicht abgeleitet werden.

Ebenso wenig dient der erste Login des Tages als Anwesenheits- oder Arbeitszeitnachweis. Er ist lediglich ein möglicher technischer Auslöser für den freiwilligen Tagescheck. Daraus entstehen keine Arbeitszeiterfassung, Präsenzkontrolle, Pausenüberwachung, Abwesenheitsbewertung oder Anwesenheitsstatistik.

Ein nicht gestarteter QM-Lauf bedeutet nicht, dass eine Person nicht gearbeitet hat. Ein später Login bedeutet nicht, dass sie verspätet war. Der Tageszustand beschreibt ausschließlich den geprüften Systemkontext.

Das QM entscheidet außerdem nicht über Provision, Vergütung, Bonus, Beteiligung, Gutschrift oder Auszahlung. Ein grüner Systemtest ist kein wirtschaftliches Erfolgsereignis. Auch ein vollständig nachgewiesener technischer Ablauf ersetzt keine kaufmännische Prüfung. Der Wirtschaftsmodus bleibt während des QM-Laufs LOCKED.

S•U•S•I darf ebenso wenig zu einem Instrument verdeckter Verhaltensanalyse werden. Versteckte Nutzerprofile, heimliche Aktivitätsauswertungen, Klick- oder Navigationsanalysen, Bewegungsprofile innerhalb der Anwendung und verdeckte Bewertungen von Arbeitsgewohnheiten sind ausgeschlossen.

Erfasst werden nur die Daten, die für den technischen Prüf- und Nachweiszweck erforderlich sind. Zweck, Umfang und Ergebnis der Prüfung müssen transparent bleiben. Der Nutzer wird vor dem Start über Dauer, Umfang, Freiwilligkeit, Neutralität und Nachweisform informiert. Transparenz ist eine Schutzbedingung und keine optionale Zusatzkommunikation.

Datenschutz durch Zweckbindung und Datenminimierung

Jeder im QM erhobene Wert benötigt einen klaren technischen Zweck. Zulässig sind die Feststellung der Betriebsbereitschaft, Schutzprüfung, Fehleranalyse, Nachweis, Revision, Wiederholung und Fortsetzung. Unzulässig sind spätere Zweckänderungen in Richtung Personalbewertung, Leistungskontrolle, Vertriebsranking, Vergütungsentscheidung oder Disziplinarmaßnahme.

Diese Zweckbindung gilt für Protokolle, Exporte, Dashboards, Auswertungen sowie Agenten- und Cronberichte. Daten dürfen nicht nachträglich still in einen anderen Bewertungszusammenhang überführt werden.

Gespeichert werden nur die für Prüfung und Nachweis erforderlichen Informationen. Dazu gehören typischerweise technische Identität, Rolle, Mandant, Prüfebene, Run-ID, Zeit, Status, Befund und Hash. Nicht erforderlich sind vollständige Verhaltensprofile, permanente Aktivitätsverläufe, inhaltliche Bewertungen von Arbeitsergebnissen oder unnötige personenbezogene Detaildaten.

Die Nutzeransicht soll nur diejenigen Informationen zeigen, die zur Einordnung des Befunds notwendig sind. Technische Detaildaten können, soweit möglich, rollenbezogen oder aggregiert dargestellt werden.

Transparenz, Sichtrechte und Protokollordnung

Der Nutzer muss erkennen können, dass eine Prüfung stattfindet, warum sie stattfindet, was geprüft wird, welche Daten entstehen und wo der Nachweis gespeichert wird. Im persönlichen Tageskontext gibt es keine stille oder unsichtbare QM-Prüfung.

Hintergrundprüfungen können technisch automatisiert laufen, müssen jedoch mandantenbezogen, protokolliert, zweckgebunden und klar von Personenbewertungen getrennt bleiben. S•U•S•I übersetzt die technischen Befunde anschließend in eine verständliche, rollenbezogene Stellungnahme.

Nicht jeder darf sämtliche QM-Daten sehen. Sichtrechte richten sich nach Rolle, Mandant, Capability, Zuständigkeit und Prüfzweck. Der Nutzer sieht den eigenen Tagesnachweis. Technische Verantwortliche erhalten die für Fehlerbearbeitung erforderlichen Befunde. Revision erhält eine geeignete, möglichst lesende Nachweissicht.

Vorgesetzte erhalten nicht automatisch personenbezogene Leistungsprofile, weil solche Profile nicht Teil des QM-Modells sind. Auch ein Super-Admin besitzt keinen pauschalen Anspruch auf unprotokollierte Vollakteneinsicht.

Das Arbeitsprotokoll beschreibt einen technischen Vorgang. Es kann etwa festhalten, dass ein Tages-QM im Maklerkontext abgeschlossen, eine Mandanten- und Rollenbindung bestätigt, ein Teilnachweis offen oder eine PDF-Quittung erzeugt wurde.

Es enthält keine Aussagen wie Mitarbeiter war langsam, Mitarbeiter hat zu spät begonnen oder Mitarbeiter hat unzureichend gearbeitet. Das Arbeitsprotokoll dokumentiert die Systemumgebung des Arbeitstages und ist kein Personalbericht.

Keine automatische arbeitsrechtliche Folge

Ein gelber oder roter QM-Befund löst keine automatische arbeitsrechtliche Maßnahme aus. Eine verschobene oder abgelehnte Prüfung erzeugt keine Sanktion, und ein technischer Fehler wird nicht automatisch einer Person zugerechnet.

Das System darf weder Abmahnungen vorbereiten noch Beschäftigtenstatus ändern, Zugänge aus Leistungsgründen sperren oder Personalentscheidungen automatisieren. Kritische technische Befunde dürfen ausschließlich die konkret betroffene Funktion schützen oder sperren. Diese Sperre richtet sich gegen ein technisches Risiko, nicht gegen den Menschen.

Systemschutz und Personalführung bleiben deshalb strikt getrennt. Das QM prüft Funktionen, bewertet Schutzbedingungen, dokumentiert technische Befunde und leitet technische Maßnahmen ein. Arbeitsbezogene Bewertungen, Gespräche oder arbeitsrechtliche Entscheidungen gehören in einen anderen Verantwortungsbereich.

Eine technische Auditspur ist keine Beurteilungsakte und darf nicht automatisch zu einer Entscheidungsgrundlage für Personalmaßnahmen werden.

Governance als Teil der Architektur

Die Schutzregeln müssen nicht nur in Texten beschrieben, sondern technisch abgesichert sein. Dazu gehören klar definierte Datenfelder, rollenbezogene Sichtrechte, begrenzte Aufbewahrung, Zweckkennzeichnung, Auditierung von Zugriffen sowie der Ausschluss versteckter Rankingfunktionen und wirtschaftlicher oder personalrechtlicher Automatismen.

Änderungen am QM-Modell müssen darauf geprüft werden, ob neue Daten erhoben werden, sich der Zweck verändert, zusätzliche Rollen Zugriff erhalten oder Auswertungen einen Personenbezug erzeugen. Governance ist damit Bestandteil der Systemarchitektur und nicht nur ein rechtlicher Begleittext.

Diese Grenze gilt auch für spätere Cronberichte, Agentenanalysen, Trenddarstellungen, SLA-Auswertungen und Qualitätsstatistiken. Systemische Trends dürfen ausgewertet werden. Personenbezogene Leistungsprofile dürfen daraus nicht entstehen.

Wiederkehrende Befunde sollen zu Systemverbesserung, Fehlerbehebung und Prozesshärtung führen. Sie sollen niemals zur Bewertung einzelner Beschäftigter verwendet werden.