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

Revisionsfähige Prüfdaten als Grundlage

Die Kennzahlen entstehen aus strukturierten Daten der Tagesprüfungen, vollständigen Rollen-Audits, Hintergrundläufe, Ereignisspur, Agenten- und Workerzustände sowie PDF- und Arbeitsprotokolle.

Jede Kennzahl muss auf konkrete Run-IDs, Mandanten, Prüfebenen, Versionen, Zeiträume und Befundklassen zurückgeführt werden können.

Unvollständige oder nicht belastbar gebundene Läufe dürfen die Statistik nicht still verfälschen. Bewertungs- und Berechnungsregeln werden versioniert. Neue Regelstände schreiben ältere Auswertungen nicht rückwirkend um.

Anteil erfolgreich abgeschlossener Läufe

Die Abschlussquote zeigt, wie viele technisch gestartete QM-Läufe einen definierten Abschluss erreichen.

Ein technisch erfolgreicher Lauf wurde kontrolliert gestartet, vollständig oder regelgerecht beendet, bewertet und nachweisbar abgeschlossen.

Die Quote kann getrennt dargestellt werden nach Prüfebene, Mandant, Rollenprofil, App-Version, Funktionsregister-Version und technischer Funktionsgruppe.

Eine hohe Abschlussquote weist auf eine stabile Prüf- und Betriebsarchitektur hin. Sie sagt nichts über die Leistung einzelner Nutzer aus.

Abschluss ist nicht automatisch Grün

Ein Lauf kann technisch erfolgreich abgeschlossen werden und dennoch Gelb, Rot-Nachweis oder Rot-Konfiguration ergeben.

Deshalb müssen mindestens zwei Kennzahlen getrennt werden:

• technische Abschlussquote
• fachliche Statusverteilung

Andernfalls würde ein vollständig diagnostizierter roter Befund fälschlich als technischer Laufabbruch erscheinen.

Gerade die Fähigkeit, Fehler kontrolliert zu erkennen, zu klassifizieren und nachweisbar abzuschließen, ist ein Qualitätsmerkmal.

Berechnung der Abschlussquote

Eine mögliche Berechnung lautet:

erfolgreich abgeschlossene Läufe ÷ alle regulär gestarteten Läufe × 100

Freiwillig verschobene oder abgelehnte Prüfungen gehören nicht in den Nenner. Sie sind keine fehlgeschlagenen Läufe.

Nutzerentscheidung und technischer Fehlschlag bleiben statistisch getrennt.

Timeout-Quote

Die Timeout-Quote zeigt, wie häufig Prüfungen oder einzelne Funktionen ihre festgelegte Laufzeitgrenze überschreiten.

Sie kann nach Tagescheck, Rollen-Audit, Hintergrundlauf, Service, Worker, Funktionsgruppe und Version ausgewertet werden.

Timeouts können auf langsame Dienste, instabile externe Abhängigkeiten, blockierte Worker, Datenbankprobleme, fehlerhafte Finalisierung oder zu umfangreiche Prüfschritte hinweisen.

Ein Timeout ist eine technische Kennzahl. Er beschreibt nicht, wie schnell ein Nutzer gearbeitet hat.

Soft- und Hard-Timeout getrennt betrachten

Ein Soft-Timeout kennzeichnet eine auffällige Verzögerung. Ein Hard-Timeout unterbricht oder beendet den Lauf kontrolliert.

Beide Werte sollten getrennt ausgewertet werden. Dadurch wird sichtbar, welche Funktionen lediglich langsam reagieren, welche tatsächlich abbrechen und welche zuverlässig innerhalb der Zielzeit liegen.

Für Ebene 1 sind insbesondere der Zielwert von ungefähr 15 Sekunden und die harte Grenze von etwa 30 Sekunden relevant.

Timeout-Analyse bis zum Prüfschritt

Das Ereignis-Tracking erlaubt die Lokalisierung des letzten erfolgreichen Prüfschritts.

Dadurch kann nicht nur eine allgemeine Timeout-Quote, sondern eine funktionsbezogene Betrachtung entstehen.

Beispielsweise:

• Sitzungsprüfung: 100 Prozent erfolgreich
• Dashboard: 99 Prozent
• Rückrufdienst: 82 Prozent
• PDF-Finalisierung: 96 Prozent

So entstehen konkrete technische Verbesserungsaufträge statt pauschaler Aussagen wie Das System ist langsam.

PDF-Erzeugungsquote

Die PDF-Erzeugungsquote zeigt, bei wie vielen abgeschlossenen Läufen das revisionsfähige QM-Protokoll vollständig erzeugt und gebunden wurde.

Erforderlich sind eine vorhandene und technisch lesbare PDF, korrekte Run-ID, vollständige Pflichtabschnitte, gebildeter PDF-Hash und eine gültige Datenbankverknüpfung.

Ein abgeschlossener Prüflauf ohne gültige PDF ist nachweisseitig unvollständig. Die fachliche Funktion kann dennoch gearbeitet haben.

Dieser Unterschied wird als Rot-Nachweis sichtbar.

PDF-Erzeugung und PDF-Integrität

Zwei getrennte Kennzahlen sind sinnvoll:

• PDF-Erzeugungsquote: Wurde eine Datei erzeugt?
• PDF-Integritätsquote: Stimmen Datei, Hash, Payload und Run-Zuordnung überein?

Eine vorhandene Datei allein ist noch kein belastbarer Nachweis.

Die Integritätsquote prüft die vollständige revisionsfähige Bindung.

Nutzen der PDF-Kennzahlen

Die PDF-Kennzahlen helfen dabei, instabile Generatoren, Hash- und Storageprobleme, Unterschiede zwischen Generatorversionen sowie wiederkehrende Rot-Nachweis-Muster früh zu erkennen.

Die Auswertung bezieht sich ausschließlich auf die Dokumentationsarchitektur und nicht auf Nutzerverhalten.

Häufigkeit roter Konfigurationsbefunde

Rot-Konfiguration zeigt, dass eine notwendige Einrichtung oder Zuordnung fehlt.

Typische Ursachen sind:

• fehlende Rollenbindung,
• fehlendes Funktionsregister,
• unvollständige Capability-Zuweisung,
• fehlende Assistenzzuweisung,
• fehlendes Policy-Profil,
• unvollständiger Mandantenkontext.

Die Häufigkeit dieser Befunde zeigt, wo Plattform, Onboarding oder Administrationsprozesse noch nicht sauber eingerichtet sind.

Die Kennzahl kann nach Modul, Rolle, Mandant, Version und Konfigurationstyp ausgewertet werden.

Konfigurationsfehler sind kein Nutzerfehler

Ein fehlendes Rollenprofil ist kein Versäumnis eines Beschäftigten. Eine fehlende Zuweisung ist keine schlechte Arbeitsleistung.

Die Kennzahl richtet sich auf Einrichtungsqualität, Onboarding, Administration und Systemkonfiguration.

Sie darf nicht personenbezogen zur Verantwortungs- oder Leistungsbewertung verwendet werden.

Wiederkehrende Konfigurationsfehler als Verbesserungsauftrag

Häufen sich bestimmte Konfigurationsbefunde, kann dies auf unklare Einrichtungsprozesse, fehlende Standardprofile, unvollständige Migrationen, widersprüchliche Rollenmodelle oder mangelnde Validierung hinweisen.

Daraus können bessere Setup-Assistenten, Preflight-Prüfungen, Pflichtfeldlogik, Rollen- und Capability-Vorlagen sowie gezielte Folgepatches entstehen.

Die Kennzahl dient der Beseitigung struktureller Ursachen.

Mittlere Laufdauer

Die mittlere Laufdauer beschreibt die technische Zeit vom Start bis zum kontrollierten Abschluss.

Sie kann getrennt berechnet werden für Ebene 1, Ebene 2, Ebene 3, Funktionsgruppen, Versionen und Mandantenklassen.

Für die Tagesprüfung ist ein stabiler Wert nahe dem 15-Sekunden-Ziel besonders wichtig.

Veränderungen über mehrere Versionen können Performance-Regressionen sichtbar machen.

Der Durchschnitt allein genügt nicht

Ergänzend sollten Median, Perzentile, maximale reguläre Laufzeit, Anteil über Zielzeit und Anteil über Hard-Timeout ausgewertet werden.

Ein Durchschnitt kann wenige sehr langsame Läufe verdecken. Perzentile zeigen besser, wie zuverlässig die Mehrheit der Prüfungen arbeitet.

Laufdauer ist ausschließlich Systemperformance

Gemessen werden die Laufzeiten von QM-Service, Diensten, Workern, Datenbank, PDF-Erzeugung und Finalisierung.

Nicht gemessen werden Denkzeit, Arbeitsgeschwindigkeit, Bearbeitungsdauer fachlicher Aufgaben oder Anwesenheit des Nutzers.

Diese Abgrenzung muss in Dashboards und Berichten sichtbar bleiben.

Weitere zulässige Systemkennzahlen

Ergänzend können ausgewertet werden:

• Verteilung von Grün, Gelb und den vier Rot-Kategorien,
• Retry-Erfolgsquote,
• Dead-Letter-Quote,
• Fortsetzungsquote,
• Hash-Integritätsquote,
• Zeit bis zur technischen Klärung.

Auch diese Kennzahlen bleiben auf Funktionen, Dienste, Versionen, Mandantenkonfigurationen und technische Abläufe bezogen.

Verteilung der Befundklassen

Die Verteilung von Grün, Gelb, Rot-Kritisch, Rot-Technisch, Rot-Nachweis und Rot-Konfiguration zeigt, welche Fehlerarten dominieren.

Sinnvolle Dimensionen sind Anwendungsversion, Funktionsgruppe, Mandantenkonfiguration, Prüfprofil und Zeitraum.

Die Verteilung darf nicht zu einer Rangliste von Nutzern oder Teams werden.

Retry-Erfolgsquote

Die Retry-Erfolgsquote zeigt, wie viele technisch fehlgeschlagene Prüfschritte durch eine kontrollierte Wiederholung erfolgreich abgeschlossen werden konnten.

Sie hilft bei der Bewertung von Retry-Strategien, Backoff, Worker-Stabilität und externen Abhängigkeiten.

Ein hoher Retry-Erfolg kann positiv sein. Eine hohe Anzahl erforderlicher Wiederholungen kann zugleich auf instabile Grunddienste hinweisen.

Dead-Letter-Quote

Die Dead-Letter-Quote beschreibt den Anteil der Prüfaufträge, die nach begrenzten Wiederholungen nicht abgeschlossen werden konnten.

Sie kann auf dauerhaft fehlerhafte Prozesse, unzureichende Fehlerbehandlung, blockierte Abhängigkeiten oder nicht lösbare Konfigurationszustände hinweisen.

Dead Letters bleiben sichtbar und auditierbar. Sie werden nicht still gelöscht.

Fortsetzungsquote

Die Fortsetzungsquote zeigt, welcher Anteil unterbrochener Läufe sicher wiederaufgenommen werden konnte.

Sie bewertet Fortsetzungsakte, Lease- und Heartbeatlogik, Geräte- oder Sitzungswechsel und Wiederanlauf.

Die Kennzahl beschreibt technische Robustheit. Sie bewertet nicht, warum ein Nutzer einen Browser geschlossen hat.

Hash-Integritätsquote

Die Hash-Integritätsquote zeigt, bei welchem Anteil der Läufe Payload-Hash, PDF-Hash und Dokumentverknüpfung vollständig und reproduzierbar bestätigt wurden.

Abweichungen können auf Probleme bei Kanonisierung, Speicherung, Generator, Dateiablage oder Revisionslogik hinweisen.

Diese Kennzahl ist zentral für die Nachweisqualität.

Zeit bis zur technischen Klärung

Für gelbe und rote Befunde kann systembezogen gemessen werden, wann der Befund festgestellt, ein Prüfauftrag erzeugt, eine technische Neubewertung vorgenommen und der Vorgang geschlossen wurde.

Gemessen wird die Bearbeitung eines Systembefunds, nicht die Leistung einer einzelnen Person.

Die Kennzahl unterstützt Betriebs- und SLA-Analysen.

Technische SLA-Überwachung

Qualitätskennzahlen können technische Serviceziele messbar machen.

Beispiele sind:

• 95 Prozent der Tageschecks unter 20 Sekunden,
• weniger als 1 Prozent Hard-Timeouts,
• 99 Prozent erfolgreiche PDF-Bindung,
• kritische Schutzbefunde innerhalb einer definierten Zeit klassifiziert,
• Dead-Letter-Aufträge innerhalb eines Betriebsfensters geprüft.

Die Ziele müssen realistisch, technisch messbar, versioniert sowie mandanten- oder funktionsbezogen sein.

SLA betrifft Systeme und Dienste

Ein SLA-Befund bezieht sich auf Verfügbarkeit, Laufzeit, Fehlerquote, Nachweisqualität und Wiederanlauf.

Er bezieht sich nicht auf Antwortgeschwindigkeit von Beschäftigten, Anzahl erledigter Aufgaben, Anwesenheit oder persönliche Produktivität.

Technische SLA und Personalbewertung dürfen nicht vermischt werden.

SLA-Abweichung als technischer Befund

Wird ein Zielwert nicht erreicht, entstehen technische Beobachtung, Trendbefund, Prüfauftrag oder gegebenenfalls ein Folgepatch.

Eine SLA-Abweichung löst keine automatische Schuldzuweisung aus.

Ursache und betroffene Systemschicht werden getrennt untersucht.

Kennzahlen als Grundlage der Pilotabnahme

Im Pilotbetrieb zeigen Kennzahlen, ob die neue QM-Architektur stabil arbeitet.

Bewertet werden können Abschlussquote, Laufzeiten, Timeout-Quote, Nachweisqualität, Anzahl kritischer Schutzbefunde, Wiederanlauf, PDF-Erzeugung sowie Mandanten- und Scope-Abweisungen.

Die Pilotabnahme stützt sich damit nicht nur auf einzelne erfolgreiche Screenshots, sondern auf reproduzierbare technische Daten.

Positive und negative Prüffälle

Eine belastbare Pilotkennzahl berücksichtigt nicht nur erfolgreiche Standardfälle.

Auch korrekt abgewiesene Vorgänge zählen als Systemqualität, etwa:

• fremder Mandant abgewiesen,
• fremdes Objekt gesperrt,
• unbekannte Capability abgelehnt,
• manipulierte Fortsetzung verworfen.

Diese negativen Tests bestätigen die Schutzarchitektur. Sie dürfen nicht als Fehlerrate interpretiert werden.

Abnahmekennzahlen benötigen Kontext

Eine Zahl ohne Prüfumfang ist wenig aussagekräftig.

Jeder Bericht sollte deshalb geprüfte Version, Funktionsregister, Mandantenumfang, Rollenprofile, Zeitraum, Anzahl der Läufe, ausgeschlossene Testfälle und Bewertungsregeln enthalten.

So werden unzulässige Vergleiche unterschiedlicher technischer Stände vermieden.

Kennzahlen führen zu konkreten Maßnahmen

Wiederkehrende Muster werden in technische Arbeitspakete übersetzt.

Beispielsweise:

• hohe Timeout-Quote beim Rückrufdienst → Service- und Workerprüfung,
• niedrige PDF-Quote → Generator- und Hashprüfung,
• häufig Rot-Konfiguration → Setup- und Rollenprozess verbessern,
• lange Finalisierung → Abschlussservice optimieren.

Kennzahlen sind kein Selbstzweck. Sie müssen in Befund, Ursache, Maßnahme und erneute Prüfung überführt werden.

Vorher-Nachher-Vergleich

Nach einem Patch oder einer neuen Version kann geprüft werden, ob sich Laufzeiten verbessert, Timeouts reduziert, PDF-Integrität erhöht oder Konfigurationsbefunde verringert haben.

Der Vergleich bleibt an Version, Register, Zeitraum und vergleichbaren Prüfumfang gebunden.

Nur so können Verbesserungen belastbar nachgewiesen werden.

Keine Schönung durch Löschung

Frühere Kennzahlen bleiben als historische Auswertung erhalten.

Ein später besserer Stand überschreibt den früheren nicht.

Fehlerhafte Berechnungen werden markiert, korrigiert und durch eine neue Auswertungsrevision ersetzt.

Damit bleibt auch die Entwicklung der Qualitätsmessung revisionsfähig.

Gesperrte Auswertungen

Unzulässig sind Rankings danach, wie oft Nutzer den freiwilligen Tagescheck gestartet, verschoben oder für den Tag abgelehnt haben.

Das Fail-Open-Modell würde seine Glaubwürdigkeit verlieren, wenn freiwillige Entscheidungen später als Compliance-, Zuverlässigkeits- oder Leistungswert verwendet würden.

Heute nicht bleibt eine legitime Nutzungsentscheidung und darf nicht als mangelnde Kooperation, Qualitätsverweigerung oder negatives Verhalten ausgelegt werden.

Keine Leistungs- oder Produktivitätsvergleiche

Aus QM-Daten dürfen keine Aussagen entstehen wie:

• Mitarbeiter A arbeitet schneller als Mitarbeiter B.
• Team X hat mehr grüne Läufe.
• Nutzer Y benötigt zu lange.
• Person Z beginnt den Arbeitstag später.

Die technische Laufzeit gehört dem System. Der Ampelstatus gehört der geprüften Funktion. Der Zeitpunkt gehört dem Systemereignis.

Keiner dieser Werte beschreibt persönliche Leistung.

Keine Anwesenheits- oder Arbeitszeitmessung

Loginzeit, QM-Zeitpunkt und Tagesgruß dürfen nicht als Arbeitsbeginn, Anwesenheitsnachweis, Arbeitszeit oder Pausenzeit interpretiert werden.

Der erste Login ist lediglich ein technischer Triggerpunkt.

Auch automatische Vor-Dienstbeginn-Prüfungen sind kein Anwesenheitsbeleg.

Keine Vergütungs- oder Personalentscheidung

QM-Kennzahlen dürfen keinen automatischen Einfluss auf Gehalt, Bonus, Provision, Beförderung, Abmahnung oder Einsatzplanung haben.

Das QM bewertet Systeme. Personal- und Vergütungsentscheidungen liegen außerhalb dieses Datenzwecks.

Zweckbindung und Datenschutz

Kennzahlen dürfen ausschließlich für technische Qualitätsverbesserung, Betriebsüberwachung, Pilotabnahme, SLA-Prüfung und Revisionsnachweis verwendet werden.

Eine spätere Zweckänderung benötigt eine eigene Prüfung, Governance-Entscheidung und gegebenenfalls eine neue Rechtsgrundlage.

Sie darf nicht still erfolgen.

Aggregation und Pseudonymisierung

Für viele technische Auswertungen sind keine Klarnamen erforderlich.

Geeignete Auswertungsebenen sind Funktionsgruppe, Mandant, Rollenprofil, Version und Zeitraum.

Ein Nutzerbezug bleibt nur dort erhalten, wo er für Fehlerlokalisierung, eigene Nachweissicht oder sicheren Kontext erforderlich ist.

Managementberichte sollten möglichst aggregiert arbeiten.

Rollenbezogene Sichtrechte

Nutzer sehen ihre eigenen Systemnachweise. Technik erhält funktions- und fehlerbezogene Kennzahlen. Betrieb sieht mandantenbezogene Systemtrends. Revision erhält eine zweckgebundene Lesesicht.

Vorgesetzte erhalten keine personenbezogenen Leistungsrankings.

Ein Super-Admin benötigt für Mandantendetails einen sichtbaren und auditierten Prüfkontext.

Auditierbare Kennzahlenberichte

Auch Kennzahlenberichte müssen nachvollziehbar sein.

Dokumentiert werden Datenstand, Zeitraum, Berechnungsregel, Filter, Version, Erstellungszeit und gegebenenfalls Hash.

Ein Dashboardwert ohne nachvollziehbare Berechnung ist keine belastbare Qualitätskennzahl.

Technisches Kennzahlenmodell

Sinnvolle Dimensionen sind:

• Mandant,
• Rollenprofil,
• Prüfebene,
• Funktionsgruppe,
• Funktion,
• App-Version,
• Funktionsregister-Version,
• QM-Regelversion,
• Zeitraum,
• Befundklasse,
• Triggerquelle.

Mögliche Messwerte sind Anzahl gestarteter, abgeschlossener und fehlgeschlagener Läufe, mittlere Laufzeit, Median, Perzentile, Timeouts, PDF-Erzeugungen, Hash-Bestätigungen, Rot-Kategorien, Retries, Dead Letters und sichere Fortsetzungen.

Freiwillige Entscheidungen statistisch trennen

deferred und declined werden nicht in technische Fehlerquoten eingerechnet.

Sie können höchstens für streng aggregierte UX-Auswertungen verwendet werden.

Jeder Bericht muss Nutzerentscheidung, technischen Laufstatus und fachlichen Befundstatus getrennt ausweisen.

Kleine Grundmengen sichtbar machen

Bei wenigen Läufen können Prozentwerte irreführend sein.

Deshalb sollten absolute Anzahl, Prozentwert, Zeitraum und Grundmenge gemeinsam dargestellt werden.

Beispielsweise:

PDF-Erzeugungsquote: 100 Prozent · 20 von 20 abgeschlossenen Läufen

Diese Darstellung ist aussagekräftiger als eine isolierte Prozentzahl.

Qualitätsdashboard für immoSoR

Ein technisches Qualitätsdashboard kann Systemstatus, Abschlussquote, Timeout-Quote, mittlere Laufzeit, PDF- und Hashquote, Befundverteilung, offene Dead Letters, wiederkehrende Konfigurationsfehler und Versionsvergleiche zeigen.

Es enthält keine Rangliste von Menschen. Der Fokus bleibt auf Funktionen, Diensten und Versionen.

Ampellogik für Systemkennzahlen

Grün bedeutet, dass ein technischer Zielwert eingehalten wird. Gelb kennzeichnet Beobachtungsbedarf oder eine leichte Abweichung. Rot zeigt, dass eine definierte technische Schwelle überschritten wurde.

Auch hier benötigt jede Farbe Grund, Zeitraum, betroffene Systemschicht und Maßnahme.

Die Kennzahlenampel darf nicht mit der Rollen- oder Nutzerampel vermischt werden.

Drill-down ohne Personenbewertung

Vom Gesamtwert kann auf Mandant, Version, Funktionsgruppe, Befundklasse und Run-ID vertieft werden.

Ein Drill-down auf personenbezogene Leistungsprofile bleibt ausgeschlossen.

Nutzeridentität wird nur angezeigt, wenn sie für eine konkrete technische Fehleranalyse erforderlich und berechtigt ist.

Verlässlicherer Betrieb

Schwächen werden früher erkannt. Wiederkehrende Fehler werden nicht nur einzeln repariert, sondern systemisch ausgewertet.

Betrieb und Technik erhalten eine gemeinsame, belegbare Datenbasis. Maßnahmen können nach ihrer technischen Wirkung priorisiert werden.

Bessere Patch- und Versionsentscheidungen

Vorher-Nachher-Kennzahlen zeigen, ob ein Patch Laufzeiten verbessert, Fehler reduziert, Nachweise stabilisiert oder neue Regressionen erzeugt.

Patchentwicklung wird dadurch messbarer und revisionsfähiger.

Eine Installation gilt nicht allein wegen eines erfolgreichen Installers als fachlich verbessert.

Belastbare Pilotabnahme

Pilotentscheidungen basieren auf positiven und negativen Tests, Laufzeiten, Fehlerquoten, Nachweisqualität, Wiederanlauf und Schutzbefunden.

Dadurch wird eine Go-/No-Go-Entscheidung nachvollziehbarer.

Einzelne grüne Screenshots reichen nicht als Gesamtbeleg.

Nachweisbarer Qualitätsfortschritt

Verbesserungen werden über mehrere Versionen sichtbar.

Beispielsweise kann die Timeout-Quote sinken, die PDF-Erzeugungsquote steigen, Rot-Konfiguration abnehmen und die mittlere Tageslaufzeit stabiler werden.

Die Plattform kann damit nicht nur behaupten, besser geworden zu sein. Sie kann den Fortschritt belegen.