Zuerst muss klar sein, was regelmäßig passiert: Eingang, gewünschtes Ergebnis und beteiligte Systeme. Ein Prozess, dessen Ziel jede Woche wechselt, ist eine andere Aufgabe als die tägliche Übertragung definierter Daten. Die Beschreibung sollte so konkret sein, dass zwei Personen denselben Fall gleich zuordnen.
Automatisierbar ist nicht dasselbe wie automatisierungswürdig
Eine wiederkehrende Aufgabe ist nicht allein deshalb ein sinnvoller Automatisierungskandidat. Zuerst sollte klar sein, welchen Nutzen die Veränderung bringt, ob die Regeln stabil genug sind und wer für Fehler verantwortlich bleibt. Ein oft ausgeführter, aber selten wichtiger Vorgang kann weniger Priorität verdienen als eine kleine Zahl zeitkritischer Freigaben. Dieser Leitfaden hilft, einen fachlichen Prüfauftrag zu formulieren; er ersetzt keine technische Machbarkeitsprüfung des konkreten Systems.
1. Einen klaren Auslöser und ein eindeutiges Ende definieren
Beschreiben Sie, welches Ereignis den Ablauf startet und woran der erfolgreiche Abschluss erkannt wird. „Wenn eine E-Mail ankommt“ ist meist zu breit. Welche Adresse, welcher Betreff oder welche fachlichen Daten machen sie zu einem gültigen Vorgang? Ebenso muss ein Teilerfolg vom Gesamtabschluss unterschieden werden. Das Speichern einer Anfrage ist nicht dasselbe wie deren erfolgreiche Zuordnung an den zuständigen Bearbeiter. Ein sichtbarer Zustand hilft, offene und abgeschlossene Arbeit auseinanderzuhalten.
2. Regeln, Daten und Verantwortung prüfen
Eine Regel kann nur verlässlich ausgeführt werden, wenn die notwendigen Daten verfügbar und ausreichend verständlich sind. Prüfen Sie Pflichtfelder, Datenformate, Dubletten, gültige Werte und Verantwortliche für Korrekturen. Auch bei einer technischen Schnittstelle kann die fachliche Bedeutung unklar sein: Bedeutet „erledigt“ abgeschlossen, versendet oder lediglich intern geprüft? Solche Unterschiede sollten vor der Umsetzung aufgelöst werden.
| Voraussetzung | Prüffrage | Bei fehlender Voraussetzung |
|---|---|---|
| Regel | Lassen sich Normal- und Ausnahmefall unterscheiden? | Zuerst fachliche Regel klären. |
| Daten | Sind benötigte Felder zugänglich und ausreichend verlässlich? | Datenverantwortlichen und Bereinigung bestimmen. |
| System | Gibt es eine zulässige Anbindung? | Technische Machbarkeit separat prüfen. |
| Verantwortung | Wer bearbeitet fehlerhafte Vorgänge? | Keinen unbeaufsichtigten Start freigeben. |
3. Wiederholungen ohne doppelte Wirkung behandeln
Viele Integrationen erhalten Ereignisse erneut oder werden nach einem Fehler wieder gestartet. Fachlich muss geklärt sein, wann ein Vorgang derselbe Vorgang bleibt. Ein erneuter Import darf beispielsweise nicht ohne Prüfung einen zweiten Auftrag erzeugen. Eine eindeutige Kennung und ein nachvollziehbarer Bearbeitungsstatus können die technische Umsetzung unterstützen. Wie das konkret umgesetzt wird, hängt von den Zielsystemen ab. Im Beratungsauftrag genügt nicht der Satz „Dubletten vermeiden“; die erwartete Behandlung eines Wiederholungsfalls muss beschrieben sein.
4. Den Fehlerweg so ernst nehmen wie den Erfolgsweg
Legen Sie fest, wie ein fehlgeschlagener Schritt erkannt, gemeldet und erneut bearbeitet wird. Ein Systemausfall darf nicht durch eine unendliche Folge neuer Versuche verdeckt werden. Ein manueller Rückfallweg braucht eine zuständige Person und genug Informationen, um den Vorgang fortzusetzen. Bei externen Aktionen ist zusätzlich zu klären, ob ein Schritt bereits ausgeführt wurde, bevor ein Timeout auftrat. Das verhindert, dass eine Wiederholung versehentlich erneut auslöst.
- Unvollständige Eingabe kontrolliert zurückweisen oder zur Klärung stellen.
- Zeitüberschreitung sichtbar machen und begrenzte Wiederholungen planen.
- Schon ausgeführte Teilschritte dokumentieren.
- Eskalation an eine tatsächlich verfügbare Rolle definieren.
5. Berechtigungen und Datenminimierung vorsehen
Ein Automatisierungskonto sollte nicht vorsorglich volle Administratorrechte erhalten. Beschreiben Sie die benötigten Aktionen und Daten möglichst eng. Protokolle müssen Fehler erklären können, aber nicht jedes vertrauliche Dokument vollständig kopieren. Vor dem Einsatz externer Dienste sind Datenwege und Freigaben zu prüfen. Diese Fragen gehören in die Anforderungsliste, auch wenn der technische Umsetzer später die konkrete Lösung auswählt. Eine erfolgreiche Testausführung ist keine Prüfung der gesamten Sicherheits- oder Datenschutzlage.
6. Ein belastbares Nutzenszenario rechnen
Trennen Sie theoretisch frei werdende Bearbeitungszeit von zusätzlicher Kontrolle und laufenden Kosten. Eine frei werdende Stunde senkt nicht automatisch die monatliche Auszahlung. Sie kann stattdessen für schnellere Antwort, höhere Qualität oder zusätzliche Arbeit verwendet werden. Notieren Sie, welcher Effekt tatsächlich beabsichtigt ist.
7. Mit einem begrenzten Pilot starten
Vereinbaren Sie Testfälle für normalen Eingang, Dublette, unvollständige Daten, nicht berechtigten Zugriff und vorübergehend nicht erreichbares Zielsystem. Prüfen Sie auch, ob ein zuständiger Mitarbeiter den Fehler ohne Entwicklerhilfe erkennen kann. Erst wenn die Ergebnisse gegen die zuvor festgelegten Kriterien bewertet sind, wird über einen breiteren Start entschieden. Der Test darf auch zeigen, dass eine einfache Prozessänderung das Problem kostengünstiger löst.
Weitere Formate
Die Textfassung bleibt für technische Workflows und KI-Arbeitsaufträge verfügbar.
Welche Entscheidung am Ende stehen sollte
Eine sinnvolle Entscheidung lautet nicht nur „automatisieren“. Sie benennt Umfang, erwarteten Nutzen, verantwortliche Person, Voraussetzungen und Prüfkriterien. Gibt es offene Grundlagen, kann das Ergebnis „noch nicht“ sein. Dokumentieren Sie den Grund: fehlender Datenzugriff, zu wechselhafte Regeln, hoher Fehlerfolgeschaden oder unklarer Betrieb. So bleibt die Analyse nutzbar und lässt sich später gezielt aktualisieren, statt bei jeder neuen Tool-Demo von vorn zu beginnen.