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

Kein automatischer Start ohne verlässlichen Dienstbeginn

Das System darf nicht allein aufgrund einer ungefähren Uhrzeit annehmen, dass ein Nutzer seinen Dienst beginnt. Ein automatischer Lauf wäre technisch und organisatorisch unsauber, wenn nicht eindeutig feststeht, welcher Nutzer arbeitet, für welchen Mandanten, in welcher Rolle, in welcher Schicht, an welchem Tag und mit welchem Funktionsregister.

Ohne belastbare Dienstplan- oder Zeitinformation bleibt der automatische Start gesperrt. Auch ein gewöhnlicher Kalendereintrag genügt nicht automatisch als Dienstbeginn. Die Systemlogik benötigt eine ausdrücklich definierte, geprüfte und freigegebene Zeitquelle.

Fehlt diese Grundlage, fällt der Ablauf auf das normale freiwillige Tagesangebot zurück.

Automatik ist standardmäßig ausgeschaltet

Der Ausgangszustand lautet:

pre_shift_automation = off

Ein neu angelegter Nutzer erhält keine automatische Vorprüfung. Auch eine neue Rolle oder ein neuer Mandant übernimmt keine frühere Zustimmung stillschweigend.

Die Automatik darf nicht durch ein Update, einen Tarifwechsel, Rollenwechsel, eine neue App-Version oder eine Administratorentscheidung ohne Nutzerbezug unbemerkt aktiviert werden.

Die Aktivierung erfolgt ausschließlich über einen kontrollierten Zustimmungsprozess. Der Zustand aus ist der sichere Standard und kein unvollständiger Systemzustand.

Stufe A · Anbieten

In der ersten Ausbaustufe bleibt der Ablauf vollständig manuell. S•U•S•I kann vor einem geplanten Dienstbeginn einen Hinweis anzeigen und den Tagescheck anbieten.

Das Angebot erklärt den vorgesehenen Zeitpunkt, den geplanten Prüfumfang, die erwartete Dauer, die wirtschaftliche Neutralität und die spätere Nachweisform. Der Nutzer muss den Lauf aktiv starten. Ohne manuellen Klick geschieht nichts.

Dadurch wird zunächst geprüft, ob Zeitpunkt, Inhalt und Nutzerführung in der Praxis sinnvoll sind.

Das Angebot darf nicht zu einem beliebigen oder technisch geratenen Zeitpunkt erscheinen. Es benötigt einen nachvollziehbaren zeitlichen Bezug, etwa eine geplante Schicht, einen freigegebenen Dienstplan, einen bestätigten Tagesbeginn oder eine ausdrücklich gepflegte Arbeitszeit.

Der Nutzer muss erkennen können, warum die Prüfung gerade zu diesem Zeitpunkt angeboten wird. Eine falsche oder veraltete Zeitzuordnung darf keinen automatischen Lauf auslösen.

Ein manueller Start in Stufe A gilt ausschließlich für diesen einzelnen Lauf. Daraus entsteht keine automatische Zustimmung für zukünftige Tage. Einzelentscheidung und dauerhafte Einwilligung werden technisch getrennt gespeichert.

Stufe A dient der praktischen Erprobung. Geprüft wird, ob der Zeitpunkt passt, die Einladung verständlich ist, der Lauf rechtzeitig abgeschlossen wird, Rolle und Mandant korrekt zugeordnet sind und die Quittierung funktioniert.

Erst nach stabiler Erprobung darf die nächste Stufe vorbereitet werden. Eine sichtbare Funktion allein ist noch keine Freigabe zur Automatisierung.

Stufe B · Merken

In der zweiten Stufe kann der Nutzer ausdrücklich zustimmen, dass S•U•S•I den gewünschten Ablauf künftig berücksichtigt.

Die Zustimmung muss ausdrücklich, verständlich, freiwillig, protokolliert und jederzeit widerrufbar sein. Eine vorangekreuzte Option oder versteckte Klausel reicht nicht aus.

Vor der Zustimmung muss klar sein, welcher Vorgang automatisiert werden soll, zu welchem Zeitpunkt, für welche Rolle, für welchen Mandanten und mit welchem Ergebnis.

Die Zustimmung gilt nicht global für sämtliche Arbeitskontexte eines Nutzers. Sie wird mindestens an Nutzer, Mandant, Rolle, Automatiktyp, Zeitquelle, Gültigkeitsbeginn und Zustimmungsrevision gebunden.

Ein Nutzer mit mehreren Rollen kann unterschiedliche Einstellungen besitzen. Im Maklerkontext kann die Automatik aktiviert sein, während sie im Affiliate-Kontext ausgeschaltet bleibt. Ein Mandantenwechsel übernimmt die Zustimmung nicht.

Kontextwechsel statt Zustimmungsunion ist verbindlich.

Der Nutzer kann die gespeicherte Zustimmung jederzeit widerrufen. Der Widerruf wirkt für zukünftige automatische Läufe. Bereits abgeschlossene Nachweise bleiben unverändert erhalten.

Der Widerruf darf keine Zugangssperre, keinen negativen Status, keine arbeitsrechtliche Bewertung und keine Eskalation auslösen. Danach fällt das System auf das freiwillige Tagesmodell zurück.

Ändern sich wesentliche Grundlagen, kann eine neue Zustimmung erforderlich werden. Dazu gehören ein anderer Mandant, eine andere Rolle, eine neue Zeitquelle, ein deutlich erweiterter Prüfumfang, eine geänderte Automatiklogik oder eine neue personenbezogene Verarbeitung.

Die Entscheidung wird anhand einer versionierten Zustimmungs- und Policylogik getroffen. Der Nutzer muss erkennen können, welcher Regelversion er zugestimmt hat.

Gespeichert wird nur, was für die Automatik erforderlich ist: Zustimmung, Kontext, Zeitpunkt, Gültigkeit, Widerruf und Regelversion. Persönliche Begründungen, Arbeitsgewohnheitsprofile, Zuverlässigkeitsbewertungen, Häufigkeitsrankings und Anwesenheitsinterpretationen sind nicht erforderlich.

Die Speicherung bleibt datensparsam und dient ausschließlich der kontrollierten Ablaufsteuerung.

Stufe C · Automatisieren

Ein vollautomatischer Lauf wird erst zugelassen, wenn Stufe A und B technisch sowie organisatorisch abgenommen sind.

Erforderlich sind eine ausdrückliche Zustimmung, eine stabile Zeitquelle, ein eindeutiger Nutzerkontext, sichere Mandanten- und Rollenbindung, geprüfte Neutralität, vollständige Auditspur und eine definierte Fehler- und Rückfalllogik.

Erst dann darf der QM-Lauf automatisch vor Dienstbeginn gestartet werden. Die Automatisierung ist eine freigegebene Betriebsart und kein stiller Nebeneffekt eines Cronlaufs.

Der geplante Lauf kann an eine verlässliche Quelle gebunden werden. Dazu können ein freigegebener Dienstplan, ein bestätigtes Schichtmodell, eine autorisierte Zeiterfassung oder ein ausdrücklich gepflegter Arbeitszeitplan gehören.

Die Quelle muss Nutzer, Mandant, Rolle, geplanten Beginn, Zeitzone und Gültigkeit eindeutig liefern. Eine fehlende, widersprüchliche oder veraltete Quelle führt nicht zum Blindstart. In diesem Fall bleibt der Lauf aus oder wird in ein freiwilliges Angebot zurückgestuft.

Vorlaufzeit und Zeitführung

Der automatische Lauf soll vor dem geplanten Dienstbeginn ausreichend Zeit erhalten. Die Vorlaufzeit berücksichtigt die Zielzeit des Tageschecks, mögliche Verzögerungen, technische Fortsetzung und die Bereitstellung des Ergebnisses.

Ein möglicher Ablauf wäre:

Geplanter Dienstbeginn 08:00 Uhr → Prüfbeginn 07:58 Uhr → Ergebnis möglichst vor 08:00 Uhr verfügbar

Die konkrete Vorlaufzeit muss konfigurierbar und rollenbezogen sein. Ein zu früher Lauf kann bis zum tatsächlichen Arbeitsbeginn veralten. Ein zu später Lauf verfehlt den Zweck der präventiven Betriebsbereitschaft.

Sichtbare Dienst- und Prüfzeiten werden in Europe/Berlin verarbeitet. Sommer- und Winterzeit müssen korrekt berücksichtigt werden. Technische Speicherung kann weiterhin in UTC erfolgen.

Geplanter Dienstbeginn, Prüfbeginn, Prüfende und Tagesdatum müssen eindeutig voneinander unterschieden werden. Zeitzonenfehler dürfen keinen Lauf für den falschen Arbeitstag erzeugen.

Der automatische Lauf bleibt nutzerbezogen

Auch bei Automatisierung wird der konkrete Nutzerkontext geprüft. Der Lauf ist kein allgemeiner Server-Healthcheck.

Gebunden bleiben Nutzer, Mandant, Rolle, App-Version, Funktionsregister-Version, Dienstplanreferenz und Zustimmung. Eine allgemeine Hintergrundprüfung ersetzt diesen Bezug nicht.

Der persönliche Vor-Dienstbeginn-Lauf bleibt fachlich von Ebene 3, dem mandantenweiten Hintergrund-QM, getrennt.

Die Vor-Dienstbeginn-Prüfung ist eine mögliche Ausführung von Ebene 1. Das vollständige Rollen-Audit bleibt Ebene 2, das Hintergrund-QM bleibt Ebene 3. Eine automatische Tagesprüfung darf nicht still zu einem vollständigen Audit ausgeweitet werden.

Der kurze Prüfumfang bleibt auch in Stufe C klar begrenzt.

Sichtbare Rückmeldung und vollständiger Nachweis

Ein automatisch ausgeführter Lauf darf nicht unsichtbar bleiben. Beim Öffnen des Arbeitsraums wird angezeigt, dass die Prüfung durchgeführt wurde, wann sie begann und endete, welcher Kontext geprüft wurde, welches Ergebnis vorliegt und wo PDF und Protokoll abrufbar sind.

Ein automatischer Lauf ohne sichtbare Stellungnahme wäre keine vollständige S•U•S•I-Begleitung.

Jeder automatische Lauf erhält Run-ID, Triggerquelle, Dienstplan- oder Zeitreferenz, Zustimmungsreferenz, Rollen- und Mandantenbindung, App- und Registerversion, Start- und Endzeit, Ergebnis, Hash, PDF und Arbeitsprotokoll.

Der Triggergrund wird ausdrücklich dokumentiert, beispielsweise:

trigger = pre_shift_automatic

Dadurch bleibt der Lauf von manuellem Start, erstem Login, Hintergrund-Cron und Auditauftrag unterscheidbar.

Keine Anwesenheits- oder Leistungsbewertung

Die Dienstplanbindung dient ausschließlich der zeitlichen Vorbereitung der Systemprüfung. Sie darf nicht als Nachweis dafür verwendet werden, dass der Nutzer tatsächlich anwesend war, pünktlich begonnen hat, gearbeitet hat oder eine bestimmte Arbeitszeit geleistet hat.

Ein automatisch ausgeführter Lauf ist kein Anwesenheitsbeleg. Ein fehlgeschlagener Lauf ist kein Abwesenheitsbeleg. Das QM bleibt arbeitsrechtlich neutral.

Nutzer ohne Zustimmung arbeiten weiterhin im normalen freiwilligen Modell. Der Zustand Automatik aus ist vollständig zulässig.

Daraus entstehen kein Qualitätsmangel, keine Warnung, keine geringere Berechtigung, kein Personalstatus und keine schlechtere Bewertung.

Die Automatik ist Komfort und Prävention, keine Pflicht.

Neutralität und wirtschaftlicher Schutz

Auch ein automatischer Lauf verwendet ausschließlich neutrale Prüfwerte. Es entstehen kein Lead, keine Kundenbuchung, keine Forderung, keine Provision, keine Auszahlung und keine Produktivfreigabe.

Der Wirtschaftsmodus bleibt LOCKED. Die Automatisierung darf keine zuvor gesperrte wirtschaftliche Wirkung aktivieren.

Die Schutzregeln entsprechen vollständig denen des manuellen Tageschecks.

Verhalten bei unklarem Kontext

Kann vor Dienstbeginn kein eindeutiger Arbeitskontext aufgelöst werden, startet kein Lauf. Gründe können eine fehlende aktive Rolle, widersprüchliche Rollenbindungen, ein fehlender Mandant, eine abgelaufene Zuweisung, eine unklare Dienstplanreferenz oder eine veraltete Zustimmung sein.

Das System protokolliert den Grund. Beim späteren Login kann S•U•S•I den normalen freiwilligen Tagescheck anbieten.

Ein unsicherer Kontext führt zum Abbruch, nicht zu einer geratenen Prüfung.

Dienstplanänderung, Abwesenheit und Gerätewechsel

Wird der Dienstbeginn geändert, muss der geplante Lauf neu bewertet werden. Ein noch nicht gestarteter Lauf kann verschoben, verworfen oder neu gebunden werden.

Ein bereits abgeschlossener Lauf bleibt als historischer Nachweis bestehen. Eine Terminänderung überschreibt keine vorhandene Prüfakte. Doppelte Läufe werden über Tages-Key und Idempotenz verhindert.

Liegt eine eindeutig freigegebene Abwesenheitsinformation vor, wird kein automatischer Tageslauf gestartet. Die konkrete Abwesenheitsursache wird jedoch nicht unnötig im QM-Nachweis vervielfältigt.

Es genügt die technische Aussage, dass für diesen Tageskontext kein geplanter Lauf vorgesehen war. Medizinische oder personalrechtliche Gründe werden nicht gespeichert.

Der automatische Lauf bleibt serverseitig an den Nutzerkontext gebunden und nicht an ein bestimmtes Browserfenster. Beim späteren Login wird das Ergebnis in einer sicheren Sitzung angezeigt.

Ein Gerätewechsel darf keinen zweiten Lauf erzeugen, keine fremde Quittung anzeigen und keinen Kontext vermischen. Vor der Anzeige werden Authentifizierung und Scope erneut geprüft.

Fehler- und Rückfalllogik

Kann der automatische Lauf nicht sicher durchgeführt werden, gilt: kein Blindversuch, keine unendliche Wiederholung und keine stille grüne Annahme.

Der Lauf kann kontrolliert abgebrochen, ein technischer Befund gespeichert, ein begrenzter Retry ausgeführt, ein manueller Tagescheck angeboten oder ein vollständiges Audit empfohlen werden.

Der Nutzer erhält eine verständliche Stellungnahme. Die Systemnutzung bleibt grundsätzlich möglich, sofern kein unabhängiger kritischer Schutzbefund vorliegt.

Rolle von Cron und Agent

Cron kann den geplanten Prüflauf zum vorgesehenen Zeitpunkt anstoßen. Der Agent überwacht Laufstart, Lease, Heartbeat, Unterbrechung, Wiederaufnahme, Timeout und Finalisierung.

Der QM-Service führt die fachliche Prüfung aus. S•U•S•I formuliert die Stellungnahme.

Cron und Agent dürfen keine automatische fachliche oder wirtschaftliche Freigabe erzeugen. Automatisierung bedeutet kontrollierte Ausführung, nicht freie Entscheidungsmacht.

Schutz vor Doppel- und Mehrfachläufen

Für denselben Tages-Key darf nur ein relevanter Lauf bestehen. Dienstplanänderungen, wiederholte Cron-Trigger oder parallele Worker dürfen keinen Doppelstart verursachen.

Die Sperre berücksichtigt Nutzer, Mandant, Rolle, Datum, App-Version und Registerversion. Wiederholte Trigger werden idempotent behandelt. Ein bereits abgeschlossener gültiger Lauf wird nicht erneut gestartet.

Kontrollierter Rollout

Die Automatik wird nicht für alle Nutzer gleichzeitig aktiviert. Ein sinnvoller Rollout beginnt mit einem internen Test, führt über einzelne freiwillige Pilotnutzer und ausgewählte Rollen oder Mandanten und endet erst nach dokumentierter Auswertung in einer breiteren optionalen Freigabe.

Jede Stufe benötigt technische Prüfung, Datenschutzprüfung, Browserabnahme, Rückfalloption und einen dokumentierten Zustimmungsfluss.

Bei kritischen Befunden wird die Automatik deaktiviert und auf das manuelle Modell zurückgestellt.