Was in die Dokumentation gehört, wenn eine Automatisierung ans Team übergeben wird

Kurz gesagt: Damit eine zweite Person eine Automatisierung tatsächlich übernehmen kann, braucht sie vier Dinge: eine Zugangsliste (welches System, welcher Zugang, wo hinterlegt), eine klare Zuständigkeit (wer reagiert bei welcher Fehlermeldung), konkrete Wiederherstellungsschritte für die wahrscheinlichsten Ausfälle – und, falls personenbezogene Daten verarbeitet werden, eine Übersicht der beteiligten Daten und Systeme. Ob die Übergabe funktioniert, zeigt sich nicht am Lesen der Doku, sondern erst daran, ob die übernehmende Person einen echten Fehler ohne Rückfrage an die bauende Person löst.

Der Rest dieses Beitrags geht das an einer durchgehenden, ausdrücklich erfundenen Übergabe durch – mit den Dokumenten, die dabei entstehen, und den zwei Stellen, an denen eine unvollständige Übergabe später teuer wird.

Voraussetzungen, bevor eine Übergabe überhaupt möglich ist

Eine Übergabe kann nur so gut sein wie das, was vorher schon existiert. Drei Dinge sollten stehen, bevor jemand anderes übernimmt:

• Eigene Zugänge statt geteilter Logins. Nach dem BSI-Baustein ORP.4 zum Identitäts- und Berechtigungsmanagement muss jede Benutzerkennung eindeutig einer Person zugeordnet sein; gemeinsam genutzte Konten sind nicht vorgesehen. Wenn zwei Personen sich denselben Zugang zu einem Postfach oder einer Automatisierungsplattform teilen, lässt sich später nicht mehr sagen, wer was verändert hat – und die Übergabe wird zur Übergabe eines Passworts statt einer Zuständigkeit.
• Ein Ort für Zugänge, der nicht an eine Person gebunden ist. Ein Passwort-Manager mit Team-Freigabe reicht; eine private Notiz oder ein Chat-Verlauf nicht, weil beides mit dem Gerät oder der Erinnerung einer einzelnen Person verschwindet.
• Eine Fehlerbenachrichtigung, die jemand tatsächlich sieht. Ohne eine E-Mail, eine Chat-Nachricht oder ein Dashboard, das bei einem Fehlschlag anspringt, merkt niemand, dass etwas steht – die beste Übergabedokumentation hilft nichts, wenn der Ausfall erst durch eine Kundenbeschwerde auffällt.

Fiktive Übergabe: die Rechnungsautomatisierung wechselt von Dana zu Tom

Fiktive Übung, keine echte Kundensituation: Dana hat vor einem Jahr eine Automatisierung gebaut, die eingehende Rechnungen aus einem Postfach liest, Lieferant und Betrag erkennt, sie einer Kostenstelle zuordnet und ins Buchhaltungssystem überträgt. Dana wechselt die Abteilung; Tom übernimmt die Betreuung.

Die Zugangsliste

| System | Zugangsart | Wo hinterlegt | Wer sonst Zugriff hat | |---|---|---|---| | Rechnungspostfach | eigenes Nutzerkonto von Dana, jetzt umgestellt auf Toms Konto | Team-Passwort-Manager, Ordner „Rechnungsautomatisierung" | IT-Admin (Notfallzugriff) | | Automatisierungsplattform | API-Schlüssel, an das Postfach-Konto gebunden | Team-Passwort-Manager | – | | Buchhaltungssystem | Servicekonto mit eingeschränkten Rechten (nur Buchungen anlegen) | Team-Passwort-Manager | Buchhaltung |

Die Zuständigkeiten

| Was passiert | Wer reagiert | Bis wann | |---|---|---| | Automatisierung meldet einen Fehlschlag | Tom | innerhalb eines Arbeitstages | | Eine Rechnung wird falscher Kostenstelle zugeordnet | Tom prüft, Buchhaltung korrigiert die Buchung | innerhalb von zwei Arbeitstagen | | Der Lieferant ändert sein Rechnungsformat | Tom passt die Erkennung an oder meldet es an die Umsetzung zurück | nach Aufwand, kein fester Termin |

Zwei Wiederherstellungsschritte für die wahrscheinlichsten Ausfälle

Fall 1: Der API-Schlüssel zum Postfach ist abgelaufen. Die Automatisierung meldet ab diesem Zeitpunkt jeden Lauf als Fehler.

1. Im Team-Passwort-Manager nachsehen, wann der Schlüssel zuletzt erneuert wurde.
2. Einen neuen Schlüssel über die Postfach-Verwaltung erzeugen (nicht über das private Konto einer einzelnen Person).
3. Den Schlüssel in der Automatisierungsplattform hinterlegen und einen Testlauf mit einer bekannten Beispielrechnung starten.
4. Erst danach den Fehlerstapel der letzten Tage manuell nachbearbeiten – nicht automatisch neu einspielen, ohne den Stapel vorher zu sichten.

Fall 2: Eine Rechnung wird der falschen Kostenstelle zugeordnet. Das fällt meist erst bei der Buchhaltung auf, nicht bei der Automatisierung selbst.

1. Die betroffene Rechnung im Postfach oder Dokumentenarchiv wiederfinden und prüfen, welcher Text zur falschen Zuordnung geführt hat.
2. Die Buchung im Buchhaltungssystem korrigieren – das macht die Automatisierung nicht rückwirkend.
3. Prüfen, ob derselbe Lieferant oder dieselbe Formulierung mehrfach betroffen ist. Wenn ja, ist es kein Einzelfall, sondern eine Lücke in der Erkennungsregel.
4. Die Lücke entweder selbst in der Zuordnungsregel schließen oder – wenn das die eigene Zuständigkeit übersteigt – an die Umsetzung zurückmelden, mit dem konkreten Beispiel.

Erwartetes Ergebnis

Nach dieser Übergabe kann Tom, ohne Dana zu fragen: sehen, welche Systeme beteiligt sind, im Fehlerfall selbst nachvollziehen, was passiert ist, einen abgelaufenen Zugang erneuern und eine falsch zugeordnete Rechnung korrigieren. Was Tom weiterhin nicht allein entscheiden sollte, ist eine grundlegende Änderung der Zuordnungsregel bei wiederkehrenden Lücken – das bleibt eine Rückmeldung an die Stelle, die den Ablauf ursprünglich eingerichtet hat, ähnlich wie fachliche Entscheidungen in einer Kanzlei bei der Kanzlei bleiben und nicht an eine Automatisierung delegiert werden.

Fehlerprüfung: wie ihr testet, ob die Übergabe wirklich funktioniert

Diese Schritte sind eine Empfehlung für die eigene Prüfung, kein Bericht über einen bereits durchgeführten Testlauf: Löst absichtlich einen der oben beschriebenen Fehlerfälle aus, während die bauende Person noch erreichbar, aber bewusst nicht eingebunden ist – zum Beispiel durch einen testweise ungültig gemachten Zugang in einer Testumgebung. Löst die übernehmende Person den Fall anhand der Dokumentation, ist die Übergabe belastbar. Braucht sie eine Rückfrage, zeigt genau diese Rückfrage, welche Zeile in der Dokumentation fehlt – und die wird ergänzt, bevor die bauende Person tatsächlich nicht mehr erreichbar ist.

Wo eine unvollständige Übergabe rechtlich eng wird

Wenn die Automatisierung personenbezogene Daten verarbeitet – etwa Namen und Kontodaten von Mandanten oder Mitarbeitenden –, reicht die reine Betriebsdokumentation nicht. Nach Art. 30 DSGVO müssen Verantwortliche ein Verzeichnis ihrer Verarbeitungstätigkeiten führen, das unter anderem Zwecke, Kategorien der betroffenen Daten und Löschfristen enthält. Übernimmt jemand eine Automatisierung, ohne dass dieses Verzeichnis mitübergeben wird, kennt die übernehmende Person ihre eigenen Pflichten nicht – das ist keine Frage von Sorgfalt mehr, sondern eine Lücke, die im Zweifel bei einer Prüfung durch die Aufsichtsbehörde auffällt. Geteilte Logins statt eigener Zugänge verschärfen das zusätzlich, weil sich dann nicht mehr nachvollziehen lässt, wer im Zweifel worauf zugegriffen hat.

Wo sich der Aufwand nicht lohnt

Nicht jede Automatisierung braucht eine vollständige Übergabeakte mit Zugangsliste, Zuständigkeitstabelle und Wiederherstellungsschritten. Ein Ablauf, der in wenigen Wochen ohnehin ersetzt wird, bei einem Ausfall niemanden außer der bauenden Person selbst betrifft und keine sensiblen Daten berührt, rechtfertigt diesen Aufwand nicht – hier reicht eine kurze Notiz. Der Aufwand einer vollständigen Übergabe lohnt sich dort, wo ein Ausfall bemerkt wird, wo mehr als eine Person betroffen ist oder wo Daten im Spiel sind, für die jemand haftet.

Der nächste Schritt

Wenn eine bestehende Automatisierung bereits Fehler zeigt, deren Ursache unklar ist, hilft als Einstieg unser Beitrag zum systematischen Finden von n8n-Workflow-Fehlern – die dort beschriebene Vorgehensweise lässt sich auf die Fehlersuche bei der Übergabe übertragen. Wollt ihr eine bestehende Automatisierung so dokumentieren oder übergeben, dass sie ein zweites Team-Mitglied tatsächlich betreiben kann, ist das eine passende Frage für unsere KI-Beratung.