Prozess dokumentieren: Grundlage für eine stabile Automatisierung

Problem und Zielgruppe

Der typische Fehler bei Automatisierungsprojekten passiert nicht bei der Technik, sondern davor: Jemand beschreibt den Prozess aus dem Kopf, „so wie er eigentlich laufen sollte” – und drei Wochen nach dem Go-Live taucht der erste Sonderfall auf, den niemand erwähnt hat. Die Rechnung ohne Bestellnummer. Der Kunde, der per Telefon storniert, während die Automatisierung nur E-Mails kennt. Die Ausnahme, die die Sachbearbeiterin seit Jahren „einfach so” löst, ohne dass es irgendwo steht.

Dieser Artikel richtet sich an Geschäftsführung, Operations, IT und Fachbereich in KMU, die einen Prozess vor der Automatisierung so dokumentieren wollen, dass genau das nicht passiert. Er ist kein allgemeiner Leitfaden zu Geschäftsprozessen – dafür gibt es den Cluster-Artikel zur Prozessautomatisierung –, sondern konzentriert sich auf die eine Frage, an der die meisten Projekte in der Praxis hängen: Wie bekommst du den Ist-Prozess inklusive seiner Sonderfälle vollständig genug auf Papier, dass eine Automatisierung darauf gebaut werden kann, ohne in der ersten Betriebswoche zu scheitern?

Begriffe kurz geklärt

Vier Begriffe, die in diesem Artikel unterschiedliche Dinge bedeuten:

• Prozessdokumentation ist die schriftliche und/oder grafische Beschreibung eines Ist-Prozesses: Schritte, Reihenfolge, Beteiligte, Systeme, Entscheidungspunkte. Sie beschreibt, was tatsächlich passiert – nicht, was im Organigramm stehen sollte.
• BPMN (Business Process Model and Notation) ist eine grafische Notation zur Modellierung von Geschäftsprozessen, seit 2005 von der Object Management Group (OMG) gepflegt und seit Version 2.0 auch als ISO/IEC 19510 international genormt. Der volle BPMN-Standard kennt dutzende Symbole für Events, Activities, Gateways und Flows. Für die meisten KMU-Prozesse ist das mehr, als du brauchst.
• BPMN-light, wie in diesem Artikel verwendet, meint eine reduzierte Untermenge dieser Notation: Start-Ereignis, Aktivitäten (Rechtecke), Entscheidungspunkte (Rauten) und Pfeile für den Ablauf – ergänzt um einen kurzen Steckbrief in Textform. Es ist kein offizieller BPMN-Modus, sondern eine pragmatische Vereinfachung für die Praxis.
• Process Mining ist ein davon zu unterscheidender Ansatz: Statt den Prozess zu beobachten oder zu befragen, wird er aus den Log- und Systemdaten rekonstruiert, die beim tatsächlichen Ablauf entstehen. Das lohnt sich vor allem bei Prozessen mit hohem Volumen in Systemen, die brauchbare Ereignisdaten liefern – für die Mehrzahl der KMU-Prozesse ist die Beobachtung vor Ort schneller und günstiger.

Wie dokumentiert man einen Prozess?

Kurz und direkt: Du beobachtest den Prozess bei der Person, die ihn tatsächlich ausführt, statt ihn nur abzufragen. Du hältst Auslöser, Schritte in ihrer Reihenfolge, beteiligte Systeme, Entscheidungspunkte, das Ende des Prozesses und jede in der Praxis vorkommende Ausnahme fest – idealerweise in einer einfachen grafischen Notation wie BPMN-light plus einem kurzen Steckbrief mit Inputs, Outputs und Rollen. Wichtiger als die gewählte Notation ist, dass die Dokumentation mit der ausführenden Person abgestimmt und gegengelesen wurde, bevor sie als Grundlage für eine Automatisierung dient.

Das praktische Vorgehen in vier Schritten:

1. Beobachten statt befragen. Ein Interview allein liefert die offizielle Version des Prozesses – die Version, die im Organigramm gut aussieht. Sitze stattdessen neben der Person, die den Prozess täglich ausführt, und lass dir mehrere reale Durchläufe zeigen, nicht nur einen. Genau hier tauchen die Abweichungen auf, die in keiner Verfahrensanweisung stehen: der Umweg über eine zweite Software, weil die erste bei bestimmten Fällen nicht mitspielt, oder der informelle Rückruf, der eigentlich nicht vorgesehen ist.

2. Skizzieren, während du beobachtest. Zeichne parallel mit – als grobes Flussdiagramm mit Rechtecken für Schritte und Rauten für Entscheidungen. Das Ziel ist nicht Perfektion beim ersten Durchgang, sondern eine Grundlage, die du danach mit der ausführenden Person durchgehst und korrigieren lässt.

3. Gegenlesen lassen. Zeig die Skizze der Person, die den Prozess ausführt, mit der konkreten Frage: „Was fehlt hier, was nicht jeden Tag passiert, aber doch öfter als einmal im Quartal?” Diese Frage bringt in der Praxis mehr zutage als „gibt es Ausnahmen?” – auf die fast immer die Antwort „eigentlich nicht” kommt, obwohl es sie gibt.

4. Auf die passende Detailtiefe verdichten. Übertrage die Skizze in eine saubere BPMN-light-Darstellung plus Steckbrief (Vorlage unten) – für den Kernprozess, nicht für jeden denkbaren Randfall. Wie tief das im Einzelfall gehen muss, hängt von Häufigkeit und Auswirkung der jeweiligen Variante ab; dazu mehr im Abschnitt zur Detailtiefe.

Process Mining, wie es etwa in Power-Automate-Umgebungen eingesetzt wird, ist hierzu ein alternativer bzw. ergänzender Ansatz: Der tatsächliche Ablauf wird aus Ereignisdaten der beteiligten Systeme rekonstruiert statt beobachtet. Das ist wertvoll bei hochvolumigen, gut protokollierten Prozessen – ersetzt aber nicht das Gespräch mit den Menschen, die die Sonderfälle kennen, die in keinem Log auftauchen, weil sie außerhalb des Systems gelöst wurden.

Welche Inputs und Outputs sind nötig?

Für jeden Schritt im Prozess brauchst du fünf Angaben, sonst lässt er sich später nicht technisch anbinden:

Angabe	Leitfrage	Warum wichtig für die Automatisierung
Input	Was geht in den Schritt hinein (Dokument, Datensatz, Nachricht, Anruf)?	Bestimmt, welche Schnittstelle oder welcher Trigger nötig ist
Quelle	Woher kommt der Input – welches System, welche Person?	Zeigt, ob eine Systemanbindung möglich ist oder ein Medienbruch vorliegt
Format	In welcher Form liegt der Input vor (strukturiert, PDF, freier Text, mündlich)?	Entscheidet, ob klassische Logik reicht oder ob eine Interpretation nötig ist
Output	Was entsteht am Ende des Schritts?	Definiert, was der nächste Schritt oder die Automatisierung erwartet
Abnehmer	Wer oder welches System verwendet den Output weiter?	Bestimmt, wohin das Ergebnis übergeben werden muss

Die häufigste Lücke in der Praxis ist das Format: Ein Prozess, der auf dem Papier „Bestelldaten verarbeiten” heißt, kann in Wirklichkeit strukturierte Datensätze aus einem System, handschriftlich ausgefüllte Formulare und formlose E-Mail-Anhänge gleichzeitig meinen – drei technisch völlig unterschiedliche Fälle unter einem Prozessnamen. Wenn du diesen Unterschied nicht bei der Dokumentation aufdeckst, taucht er beim technischen Umsetzen als teure Überraschung wieder auf.

Wie erfasst man Sonderfälle?

Frag nicht „gibt es Ausnahmen?“ – frag „zeig mir die letzten drei Fälle, die vom Standardweg abgewichen sind, und was ihr da gemacht habt“. Diese Umformulierung ist der wichtigste einzelne Kniff bei der Prozessdokumentation für Automatisierung, weil Menschen Ausnahmen selten als solche benennen, wenn sie routiniert damit umgehen – sie sind für die ausführende Person kein Sonderfall mehr, sondern Alltag.

Für jede gefundene Ausnahme dokumentierst du:

• Auslöser: Woran erkennt man, dass dieser Fall abweicht?
• Häufigkeit: Wie oft kommt das vor – täglich, monatlich, quartalsweise? Eine grobe Einordnung reicht, eine exakte Zahl brauchst du selten.
• Aktuelle Lösung: Wie wird der Fall heute gelöst, und von wem?
• Auswirkung bei Fehlern: Was passiert, wenn die Automatisierung diesen Fall fälschlich wie den Standardfall behandelt?

Aus diesen vier Angaben ergibt sich die eigentliche Entscheidung: automatisieren, teilautomatisieren mit Prüfschritt, oder bewusst beim Menschen belassen. Häufige Sonderfälle mit geringer Auswirkung eignen sich meist für eine eigene Automatisierungsregel. Seltene Sonderfälle mit hoher Auswirkung gehören in aller Regel an einen Menschen – mit einer klaren Eskalationsroute, die selbst Teil der Dokumentation ist, nicht nur ein Nebensatz. Für Fälle dazwischen ist ein Prüfschritt vor der finalen Ausführung oft die pragmatischste Lösung: Die Automatisierung bereitet vor, ein Mensch entscheidet.

Eine Warnung aus der Praxis: Sonderfälle, die bei der Dokumentation übersehen werden, verschwinden nicht – sie tauchen nach dem Go-Live als Störung im Betrieb auf, meist genau dann, wenn niemand mehr genau hinschaut, weil der Prozess ja „automatisiert läuft”. Deshalb lohnt sich der zusätzliche Aufwand, Sonderfälle vor dem Bau zu erfassen, fast immer mehr als der Aufwand, sie danach einzeln nachzurüsten.

Welche Rollen müssen eingebunden werden?

Drei Rollen sind für eine belastbare Prozessdokumentation nicht verhandelbar:

• Ausführende Person(en): Kennt den Prozess aus der täglichen Praxis, liefert die Sonderfälle und muss die Dokumentation gegenlesen. Ohne sie bleibt die Dokumentation die Wunschvorstellung des Prozesseigners – korrekt für den Regelfall, blind für alles andere.
• Fachlich verantwortliche Person: Gibt den dokumentierten Prozess frei, entscheidet über Prioritäten bei widersprüchlichen Angaben und trägt später die Verantwortung für den automatisierten Betrieb.
• Technische Zuständigkeit: Beurteilt, welche Systeme und Schnittstellen für die dokumentierten Inputs/Outputs infrage kommen, und markiert früh, wo ein Medienbruch technisch teuer wird.

In der Praxis bei mir zeigt sich immer wieder: Wird die ausführende Person nur einmal am Anfang befragt und danach nicht mehr eingebunden, fehlen am Ende genau die Details, die den Unterschied zwischen einer Automatisierung machen, die läuft, und einer, die ständig nachjustiert werden muss. Ein zweiter Termin zum Gegenlesen – oft eine halbe Stunde – ist die günstigste Fehlerprävention im ganzen Vorhaben.

Wenn mehrere Abteilungen im Prozess vorkommen (zum Beispiel Vertrieb übergibt an Backoffice, das an Buchhaltung übergibt), brauchst du ausführende Personen aus jeder beteiligten Abteilung – Übergabepunkte zwischen Abteilungen sind erfahrungsgemäß die Stellen mit den meisten unausgesprochenen Sonderfällen, weil jede Seite nur ihren eigenen Teil vollständig kennt.

Welche Detailtiefe ist sinnvoll?

Die Detailtiefe richtet sich nicht danach, wie kompliziert du den Prozess findest, sondern danach, ob jemand, der den Prozess nicht kennt, ihn anhand der Dokumentation korrekt nachvollziehen könnte – Ausnahmen und Fehlerfälle eingeschlossen. Als Faustregel für KMU-Kernprozesse: eine Seite mit BPMN-light-Diagramm plus Steckbrief reicht in den meisten Fällen. Wird es deutlich länger, ist das oft ein Zeichen, dass der Prozess in Wahrheit mehrere unterschiedliche Prozesse unter einem Namen sind – dann lohnt sich eine Aufteilung mehr als ein immer dickeres Dokument.

Für Randfälle gilt ein bewusstes Priorisierungsprinzip: Sehr seltene Sonderfälle mit geringer Auswirkung müssen nicht bis ins letzte Detail modelliert werden. Es reicht, sie als „kommt vor, wird manuell behandelt, nicht Teil der Automatisierung” zu markieren – das ist eine gültige und oft die wirtschaftlich sinnvollste Entscheidung, keine Lücke in der Dokumentation. Die Falle liegt woanders: wenn ein Sonderfall gar nicht erst erkannt wird, weil niemand danach gefragt hat.

Umsetzung: BPMN-light-Vorlage mit Beispiel

Die folgende Vorlage kombiniert ein reduziertes BPMN-Diagramm (in Textform beschrieben) mit einem strukturierten Steckbrief. Sie deckt für die meisten KMU-Prozesse ab, was für eine Automatisierung gebraucht wird, ohne den vollen BPMN-2.0-Symbolumfang der OMG-Spezifikation.

Diagramm-Notation (vereinfacht):

[Start-Ereignis] → [Aktivität 1] → <Entscheidung?> → [Aktivität 2a] → [Ende]
                                          ↓ (Sonderfall)
                                    [Aktivität 2b: Eskalation an Mensch] → [Ende]

Steckbrief-Vorlage:

Feld	Beispiel: Eingangsrechnungen erfassen
Prozessname	Eingangsrechnungen erfassen und zur Freigabe weiterleiten
Auslöser	Rechnung erreicht das zentrale Rechnungs-Postfach
Häufigkeit	Ca. 15–20 Rechnungen pro Werktag (Annahme auf Basis der Beobachtung, keine Systemstatistik)
Input	PDF-Anhang per E-Mail, teils gescanntes Papier
Standardschritte	1. Rechnung im Postfach erkennen → 2. Rechnungsdaten erfassen (Lieferant, Betrag, Fälligkeit, Bestellbezug) → 3. Abgleich mit Bestellung im ERP → 4. Bei Übereinstimmung: Freigabe-Workflow anstoßen → 5. Ablage
Entscheidungspunkt	Stimmt Rechnungsbetrag mit Bestellung überein?
Sonderfall 1	Rechnung ohne Bestellnummer (schätzungsweise mehrmals pro Woche) → aktuelle Lösung: Rückfrage per Telefon beim Lieferanten durch die Buchhaltung
Sonderfall 2	Rechnungsbetrag weicht von Bestellung ab (unregelmäßig, aber wiederkehrend) → aktuelle Lösung: manuelle Prüfung durch Teamleitung vor Freigabe
Output	Freigegebene, im ERP erfasste Rechnung mit Zahlungslauf-Kennzeichen
Abnehmer	Buchhaltung / Zahlungslauf
Ausführende Person(en)	Sachbearbeitung Rechnungseingang
Fachlich verantwortlich	Teamleitung Buchhaltung
Technische Zuständigkeit	IT / ERP-Administration

Wichtig an diesem Beispiel: Die beiden Sonderfälle sind nicht am Rand vermerkt, sondern gleichwertig neben dem Standardablauf dokumentiert – inklusive der Frage, wer sie heute löst. Genau diese Zeilen entscheiden später, ob eine Automatisierung den Regelfall abdeckt und den Rest sauber an die Buchhaltung eskaliert, oder ob sie bei der ersten Abweichung falsch reagiert.

Risiken & Grenzen

Prozessdokumentation ist kein Selbstzweck und kein Garant für eine reibungslose Automatisierung – sie senkt lediglich das Risiko, die häufigsten Fehlerquellen vorher zu übersehen. Ein paar Grenzen, die du kennen solltest:

• Beobachtung zeigt nicht jeden Sonderfall. Seltene Ausnahmen (einmal im Jahr) tauchen bei einer ein- oder zweitägigen Beobachtung womöglich gar nicht auf. Ergänze deshalb die Beobachtung immer um das Gespräch „was kommt selten vor, aber kommt vor” – und akzeptiere, dass auch dann eine Restunsicherheit bleibt, die erst im Betrieb sichtbar wird.
• Dokumentation veraltet. Prozesse ändern sich – neue Vorschriften, neue Systeme, neue Sonderfälle. Eine Dokumentation, die nach dem Projektstart nie wieder angefasst wird, verliert mit der Zeit an Wert. Plane eine Zuständigkeit für die Pflege ein, nicht nur für die Ersterstellung.
• BPMN-light ersetzt keine technische Spezifikation. Die Notation aus diesem Artikel ist für die fachliche Verständigung gedacht, nicht als vollständige technische Grundlage für komplexe Systemintegrationen. Bei Prozessen mit vielen Systemschnittstellen kann eine detailliertere Modellierung nach dem vollen BPMN-2.0-Standard sinnvoll sein.
• Dokumentation ersetzt keine Entscheidung über Automatisierbarkeit. Ein gut dokumentierter Prozess kann trotzdem ein schlechter Automatisierungskandidat sein – etwa wenn er zu selten läuft oder zu viele Ausnahmen hat, um sich zu lohnen. Diese Bewertung ist ein eigener Schritt, den die Dokumentation vorbereitet, aber nicht ersetzt.
• Zeitaufwand wird oft unterschätzt. Für einen mittelkomplexen Prozess mit mehreren Beteiligten und wiederkehrenden Sonderfällen braucht eine belastbare Dokumentation aus meiner Erfahrung eher Tage als Stunden – inklusive Gegenlesen. Wer das vorher nicht einplant, spart die Zeit später an einer teureren Stelle wieder ein: bei der Fehlersuche im laufenden Betrieb.

Checkliste: Prozess für die Automatisierung dokumentieren

1. Der Prozess wurde bei mindestens einer ausführenden Person live beobachtet, nicht nur abgefragt.
2. Auslöser, Schritte, Entscheidungspunkte und Ende sind als BPMN-light-Diagramm oder vergleichbar skizziert.
3. Für jeden Schritt sind Input, Quelle, Format, Output und Abnehmer erfasst.
4. Sonderfälle wurden aktiv erfragt („zeig mir die letzten abweichenden Fälle”) statt nur allgemein abgefragt.
5. Jeder gefundene Sonderfall ist mit Häufigkeit, aktueller Lösung und Auswirkung bei Fehlbehandlung dokumentiert.
6. Für jeden Sonderfall steht fest: automatisieren, mit Prüfschritt automatisieren, oder beim Menschen belassen.
7. Ausführende Person, fachlich verantwortliche Person und technische Zuständigkeit sind benannt und eingebunden.
8. Die Dokumentation wurde von der ausführenden Person gegengelesen und korrigiert.
9. Die Detailtiefe entspricht der Faustregel: nachvollziehbar für jemanden, der den Prozess nicht kennt – nicht mehr, nicht weniger.
10. Es gibt eine benannte Zuständigkeit für die Pflege der Dokumentation nach dem Go-Live.

Wenn du einen konkreten Prozess hast, den du dokumentieren und für eine Automatisierung vorbereiten willst: Wir schauen ihn uns gemeinsam an – im kostenlosen Erstgespräch oder direkt im Rahmen einer Beratung mit Prozess-Audit. Für Teams, die die Methode selbst im Haus etablieren wollen, bieten wir auch passende Schulungen an.