Zum Inhalt springen
← Impulse

So gestalten Sie eine manuelle Prüfschleife für Automatisierungen

Eine manuelle Prüfschleife macht Ausnahmen in der Automatisierung zu verständlichen, zuweisbaren und nachvollziehbaren Fällen – mit klaren Aktionen und eindeutigen Abschlusskriterien.

Oberfläche einer manuellen Prüfschleife mit Fällen, Status, Zuständigkeiten und Lösungsaktionen.

Kann eine Automatisierung einen Fall nicht abschließen, überträgt eine isolierte Warnmeldung das Problem oft an eine Person, ohne ihr die nötigen Mittel zur Lösung zu geben. Die Folge können eine mühsame Suche nach Kontext in verschiedenen Systemen, uneinheitliche Entscheidungen oder Fälle sein, die ohne zuständige Person unbearbeitet bleiben. Eine gut gestaltete Arbeitsliste macht aus dieser Unterbrechung einen operativen Ablauf: Sie stellt den Fall dar, zeigt den Handlungsbedarf und ermöglicht die Entscheidung über die nächsten Schritte.

Es geht nicht darum, eine weitere Aufgabenliste zu erstellen. Ziel ist ein konkreter, klar eingegrenzter menschlicher Eingriff, der in den automatisierten Prozess eingebettet ist. Dazu muss das Design festlegen, wann ein Fall angelegt wird, welche Informationen angezeigt werden, welche Aktionen möglich sind, wer die Verantwortung übernimmt und wie der Abschluss bestätigt wird.

Wann eine Prüfschleife nötig ist und wann eine Warnmeldung genügt

Wann eine Prüfschleife nötig ist und wann eine Warnmeldung genügt

Eine Warnmeldung reicht aus, wenn lediglich über ein Ereignis informiert werden muss und weder eine Untersuchung noch eine Entscheidung oder Datenänderung erforderlich ist. Ein Fall in einer Prüfschleife ist dagegen sinnvoll, wenn jemand Belege prüfen, zwischen Alternativen wählen, Angaben korrigieren oder einen Schritt ausführen muss, den die Automatisierung nicht sicher erledigen kann.

Bevor Sie die Oberfläche entwickeln, sollten Sie den Grund für den Eingriff und das gewünschte Ergebnis bestimmen. Eine Person um die Bestätigung einer unsicheren Angabe zu bitten, ist beispielsweise etwas anderes, als sie um die Genehmigung eines Vorgangs oder um das Anfordern zusätzlicher Informationen zu bitten. Für jeden Grund braucht es eine verständliche Regel dafür, wann ein Fall angelegt wird, und einen klar definierten Ausgang.

  • Verwenden Sie eine Warnmeldung, wenn keine individuelle Nachverfolgung und keine Entscheidung erforderlich sind.
  • Verwenden Sie eine Prüfschleife, wenn Arbeit aussteht und eine zuständige Person, ein Status sowie eine Abschlussbedingung festgelegt werden müssen.
  • Überprüfen Sie den Prozess, wenn die meisten Fälle in einer wiederkehrenden manuellen Tätigkeit enden. Möglicherweise müssen die Automatisierung oder ihre Regeln angepasst werden.

Die Prüfschleife sollte außerdem nicht zum Sammelbecken für beliebige technische Fehler werden. Infrastruktur- oder Integrationsausfälle können andere Werkzeuge und Zuständigkeiten erfordern. Trennen Sie operative Probleme, die eine nutzende Person lösen kann, von Vorfällen, die technische Unterstützung benötigen.

Welchen Kontext prüfende Personen benötigen

Die Person sollte den Fall verstehen können, ohne ihn von Grund auf neu rekonstruieren zu müssen. Zeigen Sie zuerst die Informationen, die erklären, warum der Fall zur Prüfung vorgelegt wurde und welche Entscheidung erforderlich ist. Zum Mindestkontext gehören in der Regel der Ursprung, der Grund, die möglichen Auswirkungen, der relevante Verlauf und der erwartete nächste Schritt. Vermeiden Sie Felder ohne Bezug zur anstehenden Entscheidung.

Machen Sie deutlich, welche Angaben bestätigt und welche abgeleitet oder noch zu prüfen sind. Hat das System eine Abweichung festgestellt, zeigen Sie – sofern verfügbar – die verglichenen Werte und deren Herkunft. Gibt es eine Frist oder mögliche Folgen einer Verzögerung, stellen Sie diese klar dar, ohne bei jedem Fall eine falsche Dringlichkeit zu erzeugen.

  • Ursprung: Welcher Prozess oder welches Ereignis hat den Fall erstellt?
  • Grund: Welche Bedingung hat den Abschluss der Automatisierung verhindert?
  • Auswirkung: Welcher Teil des Prozesses wartet auf eine Lösung?
  • Verlauf: Frühere Versuche, Änderungen und relevante Entscheidungen.
  • Nächster Schritt: Was kann die Person tun und was geschieht danach?

Ermöglichen Sie bei Bedarf den Zugriff auf zusätzliche Details, aber zwingen Sie niemanden, für eine übliche Prüfung mehrere Ansichten zu öffnen. Auch der Datenschutz gehört zum Design: Zeigen Sie nur die für die Aufgabe erforderlichen Daten an und steuern Sie den Zugriff entsprechend den Zuständigkeiten im Team.

Status und Aktionen müssen unterschiedliche Entscheidungen ausdrücken

Status beschreiben, an welcher Stelle sich ein Fall befindet; Aktionen halten fest, was jemand getan hat. Verwechseln Sie beides nicht. Ein Status wie „ausstehend“ erklärt nicht, ob der Fall auf eine Person, auf externe Informationen oder auf eine spätere Prüfung wartet. Legen Sie Status fest, die eine operative Situation beschreiben und einen gültigen Übergang ermöglichen.

Ein einfacher Ablauf kann zwischen neu eingegangenen, in Prüfung befindlichen, auf Informationen wartenden, eskalierten und gelösten Fällen unterscheiden. Nicht jede Organisation braucht dieselben Bezeichnungen. Jeder Status sollte aber zwei Fragen beantworten: Wer muss jetzt handeln, und welche Bedingung ermöglicht den nächsten Schritt?

Trennen Sie außerdem die Aktionen Prüfen, Korrigieren, Genehmigen und Zurückgeben. Die Oberfläche sollte die Wirkung jeder Aktion erläutern. Eine Korrektur kann einen Wert ändern, eine Genehmigung die Fortsetzung erlauben und eine Rückgabe weitere Informationen anfordern oder den Fall an ein anderes Team senden. Ist eine Aktion unumkehrbar oder mit erheblichen Folgen verbunden, verlangen Sie eine angemessene Bestätigung und zeigen Sie an, wohin der Fall anschließend gelangt.

Vermeiden Sie mehrdeutige Schaltflächen wie „Fertig“, wenn daraus nicht hervorgeht, was abgeschlossen wurde. Bestätigen Sie nach einer Aktion das Ergebnis und aktualisieren Sie den sichtbaren Status. Schlägt der Vorgang fehl, bewahren Sie die bereits geleistete Arbeit und erklären Sie, wie es weitergeht, statt die Person im Unklaren darüber zu lassen, ob die Änderung gespeichert wurde.

Zuweisung, Priorität und Fristen: Fälle nicht aus dem Blick verlieren

Für die Prüfschleife braucht es eine klare Zuständigkeitsregel. Fälle können einer Person, einem Team oder einer gemeinsamen Warteschlange zugewiesen werden. Es muss jedoch erkennbar sein, wer für den nächsten Schritt verantwortlich ist. Legen Sie bei einer gemeinsamen Warteschlange fest, wie ein Fall übernommen wird und was geschieht, wenn ihn bereits jemand bearbeitet. So lassen sich doppelte Arbeit und gleichzeitige, widersprüchliche Entscheidungen vermeiden.

Die Priorität sollte auf nachvollziehbaren Kriterien beruhen, etwa auf den betrieblichen Auswirkungen oder einer tatsächlichen Frist. Sie ist kein Ersatz für eine Kapazitätsplanung. Wenn alles als dringend erscheint, hilft die Priorisierung nicht mehr bei der Entscheidung. Fristen brauchen eine vereinbarte Bedeutung: Sie können einen Nachfasszeitpunkt angeben, eine Eskalation auslösen oder eine Zusage markieren. Zeigen Sie, welche dieser Folgen gilt.

  • Legen Sie fest, welche Ereignisse einen Fall zuweisen, freigeben oder neu zuweisen.
  • Machen Sie die aktuell zuständige Person sowie die Wartezeit oder Wartebedingung sichtbar.
  • Planen Sie den Umgang mit Abwesenheiten, Schichtwechseln und fehlender Kapazität.
  • Richten Sie einen Weg ein, um Fälle ohne Zuständigkeit und doppelte Fälle zu erkennen.

Entscheidungen dokumentieren, eskalieren und Fälle abschließen

Die Nachvollziehbarkeit sollte erklären, was entschieden wurde, wer die Entscheidung getroffen hat, wann dies geschah und welche relevanten Informationen dabei vorlagen. Erfassen Sie die Aktion und die nötigen Datenänderungen, damit sich der Ablauf rekonstruieren lässt. Verlassen Sie sich nicht ausschließlich auf freie Kommentare. Ein Kommentar kann Kontext liefern, sollte aber keine strukturierte Begründung ersetzen, wenn der Prozess eine Klassifizierung von Entscheidungen erfordert.

Kann die zuständige Person den Fall nicht lösen, bieten Sie einen Eskalationsweg mit eindeutigem Ziel und Grund an. Eine Eskalation darf nicht bedeuten, dass die Verantwortung einfach aufgegeben wird: Das System sollte zeigen, wer den Fall erhält, und dessen Status weiterhin sichtbar halten. Fehlen Informationen, dokumentieren Sie, was angefordert wurde und wer für den nächsten Schritt zuständig ist.

Definieren Sie den Abschluss als überprüfbare Bedingung und nicht als isolierte Schaltfläche. Ein Fall könnte abgeschlossen werden, wenn die Entscheidung dokumentiert ist und der automatisierte Prozess das Ergebnis erhalten hat, oder wenn festgehalten wurde, dass der Vorgang nicht fortgesetzt werden kann. Kann das System nicht bestätigen, dass die Automatisierung die Arbeit wieder aufgenommen hat, sollte der Fall als noch nicht bestätigt angezeigt werden, statt einen vermeintlichen Erfolg zu melden.

Kennzahlen, die Reibung bei der Prüfung sichtbar machen

Die Anzahl der Fälle allein sagt nicht aus, ob die Prüfschleife gut funktioniert. Kombinieren Sie sie mit Kennzahlen, die Arbeitsaufwand und Prozessqualität erklären: etwa der Dauer, die Fälle in den einzelnen Status verbringen, der Zahl der Neuzuweisungen, der Häufigkeit von Rückgaben und dem Anteil der Fälle, die bei der ersten Prüfung gelöst werden.

Betrachten Sie diese Daten zusammen mit dem jeweiligen Eingangsgrund. Eine lange Wartezeit kann auf fehlende Kapazität, unvollständige Informationen oder eine externe Abhängigkeit zurückgehen. Häufige wiederholte Korrekturen können darauf hindeuten, dass die Automatisierung einen Wert falsch erfasst oder die Anweisungen unklar sind. Kennzahlen sollten eine Untersuchung anstoßen und nicht automatisch der prüfenden Person die Schuld zuschreiben.

Checkliste vor der Inbetriebnahme

Checkliste vor der Inbetriebnahme

Testen Sie die Prüfschleife gemeinsam mit den Personen, die die Arbeit ausführen, und anhand repräsentativer Szenarien – auch solcher, die sich nicht beim ersten Versuch lösen lassen. Prüfen Sie, ob sie erklären können, warum ein Fall angezeigt wird, die passende Aktion auswählen und vorhersehen können, was danach geschieht.

  • Gibt es für jeden Ausnahmegrund eine Reaktion und eine Abschlussbedingung?
  • Reicht der Kontext für eine Entscheidung aus, ohne dass unnötig in anderen Systemen gesucht werden muss?
  • Zeigen die Status an, wer handeln muss und was noch fehlt?
  • Unterscheiden die Aktionen klar zwischen Prüfen, Korrigieren, Genehmigen und Zurückgeben?
  • Verhindert die Zuweisung Fälle ohne Zuständigkeit und doppelte Arbeit?
  • Bleibt eine nützliche Dokumentation von Entscheidungen und Änderungen erhalten?
  • Sind für Eskalationen und das Warten auf Informationen zuständige Personen sichtbar?
  • Helfen die Kennzahlen, Reibung zu finden, ohne die Bewertung auf die Fallzahl zu reduzieren?

Eine wirksame Prüfschleife macht die Arbeit sichtbar, die eine Automatisierung nicht abschließen konnte. Erklärt jeder Fall seinen Grund, bietet eine passende Aktion und hält das Ergebnis der Entscheidung fest, wird der menschliche Eingriff von einer undurchsichtigen Unterbrechung zu einem Bestandteil des Prozesses.

Fuentes y referencias

  1. Web standardsW3C
  2. OWASP Cheat Sheet SeriesOWASP Foundation
  3. Web performanceweb.dev