Prozessdokumentation erstellen: sechs Schritte zum Erfolg

Die meisten Prozessdokumentationen scheitern nicht beim Schreiben. Sie scheitern im zweiten Jahr.

Die Dateien liegen im Intranet, die Diagramme sind sauber, jemand hat sich sichtbar Mühe gegeben. Trotzdem fragt die neue Kollegin nach drei Tagen ihren Sitznachbarn, statt das Dokument zu öffnen – weil sie beim ersten Versuch gemerkt hat, dass zwei Schritte nicht mehr stimmen. Ab diesem Moment ist die Dokumentation erledigt. Nicht falsch genug, dass es jemand meldet. Nur falsch genug, dass ihr niemand mehr traut.

Das ist kein Sorgfaltsproblem. Es ist ein Konstruktionsproblem. Eine Prozessdokumentation beschreibt einen Zustand, aber der Prozess läuft weiter – und keines der Ereignisse, die ihn verändern, meldet sich beim Dokument an.

Wer eine Prozessdokumentation erstellen will, kommt mit sechs Schritten aus. Das ist die Reihenfolge, in der ich vorgehe. Fünf davon betreffen das Erstellen. Der sechste entscheidet, ob sich der Aufwand gelohnt hat.

Schritt 1: Klären, wofür die Dokumentation da ist

„Wir müssen unsere Prozesse mal dokumentieren“ ist kein Auftrag, sondern ein Vorsatz. Die erste Frage lautet: Wer wird dieses Dokument öffnen, und was will er in dem Moment wissen? Vier Antworten kommen in der Praxis vor, und sie führen zu vier verschiedenen Dokumenten.

Zweck	Leser	Was das Dokument leisten muss
Einarbeitung	neue Beschäftigte	handlungsfähig machen: Reihenfolge, Werkzeuge, Ansprechpartner
Nachweis	Prüfer, Auditor, Rechnungsprüfung	Nachvollziehbarkeit: Wer entscheidet was, auf welcher Grundlage
Systemeinführung	Softwareanbieter, Projektteam	Vollständigkeit an den Schnittstellen, inklusive Sonderfällen
Verbesserung	Fachbereich selbst	Messpunkte: Wo entstehen Wartezeiten, Rückfragen, Doppelarbeit

Wer alle vier gleichzeitig bedienen will, bekommt ein Dokument, das für jeden Zweck zu lang und für keinen präzise genug ist. Entscheiden Sie sich für einen Hauptzweck und schreiben Sie ihn auf die erste Seite. Das spart später jede Diskussion über die Detailtiefe.

Schritt 2: Die Flughöhe festlegen – und dabei bleiben

Drei Ebenen reichen in fast allen Fällen aus:

1. Prozesslandkarte. Welche Prozesse gibt es überhaupt, wer verantwortet sie, wie hängen sie zusammen. Eine Seite pro Organisationseinheit.
2. Ablauf. Der einzelne Prozess von der Auslösung bis zum Ergebnis, mit Zuständigkeiten und Entscheidungspunkten. Das ist die Ebene, die in neun von zehn Fällen gemeint ist.
3. Arbeitsanweisung. Die konkrete Tätigkeit, Klick für Klick oder Formularfeld für Formularfeld.

Der teuerste Fehler ist die dritte Ebene ohne Not. Arbeitsanweisungen veralten am schnellsten, weil jede Oberflächenänderung sie ungültig macht – und sie sind der Grund, warum viele Dokumentationen nach dem ersten Software-Update niemand mehr anfasst. Meine Faustregel: Gehen Sie eine Ebene tiefer, wenn ohne diese Tiefe jemand eine Entscheidung falsch trifft. Nicht, weil es sich vollständiger anfühlt.

Schritt 3: Aufnehmen, wo der Prozess wirklich stattfindet

Der übliche Weg ist ein Workshop mit acht Personen und einem Whiteboard. Das Ergebnis ist ein Prozess, auf den sich alle einigen konnten – und der so in keiner Woche abläuft. Denn im Workshop beschreiben Menschen den Prozess so, wie er gedacht ist. Die Abweichungen, aus denen der Alltag besteht, nennt niemand vor Publikum.

Ich nehme Prozesse deshalb im Einzelgespräch auf, 60 bis 90 Minuten, am Arbeitsplatz der Person, die den Prozess täglich ausführt. Drei Fragen tragen dabei den größten Teil:

• „Zeigen Sie es mir am letzten echten Vorgang.“ Nicht beschreiben lassen, sondern vorführen lassen. Der Unterschied zwischen beidem ist der eigentliche Ertrag der Aufnahme.
• „Was machen Sie, wenn das nicht klappt?“ Der Ausnahmefall ist häufiger als der Regelfall – und er ist der Teil, der in keiner Dokumentation steht.
• „Wo müssen Sie nachfragen?“ Jede Rückfrage markiert eine Schnittstelle, die nicht sauber definiert ist.

Erst danach wird modelliert. Der Entwurf geht an dieselbe Person zurück, bevor ihn irgendjemand sonst sieht. Wer den Prozess ausführt, muss sich im Dokument wiedererkennen – sonst wird es nie benutzt, egal wie korrekt es ist.

Schritt 4: Notation wählen – BPMN 2.0 nur, wenn jemand sie liest

BPMN 2.0 ist ein guter Standard, und ich modelliere überwiegend darin. Aber die Notation ist eine Entscheidung über Leser, nicht über Qualität.

BPMN lohnt sich, wenn der Prozess mehrere Beteiligte über Abteilungsgrenzen hinweg verbindet, wenn er später automatisiert oder in eine Fachanwendung überführt werden soll, oder wenn ein Prüfer Entscheidungslogik nachvollziehen können muss.

BPMN lohnt sich nicht bei einem linearen Ablauf mit einer Zuständigkeit. Dafür ist eine nummerierte Liste mit Verantwortlichem und Ergebnis je Schritt schneller erstellt, schneller gelesen und schneller aktualisiert. Ein Diagramm, das nur der Ersteller entziffern kann, ist eine Verschlechterung gegenüber einer Tabelle.

Wenn Sie BPMN einsetzen: Beschränken Sie sich auf ein knappes Dutzend Symbole – Aufgabe, Ereignis, Gateway, Pool, Lane, Sequenzfluss. Die volle Symbolmenge braucht in der Praxis fast niemand, und jedes zusätzliche Zeichen kostet Leser.

Schritt 5: Verbindlich machen

Ein Prozess, den niemand freigegeben hat, ist eine Meinung. Vier Angaben gehören auf jedes Dokument, und sie kosten zusammen zehn Minuten:

• Prozessverantwortlicher – mit Namen, nicht mit Abteilung. Eine Abteilung pflegt nichts.
• Freigabedatum und Fassung – sichtbar auf der ersten Seite, nicht in den Dateieigenschaften.
• Geltungsbereich – für welche Standorte, Mandanten oder Fallgruppen gilt das hier, und für welche ausdrücklich nicht.
• Ein Ablagepfad, nicht drei – die zweithäufigste Todesursache nach der Veralterung ist die Kopie auf einem Gruppenlaufwerk, die sich unbemerkt vom Original entfernt.

Schritt 6: Pflege an Anlässe hängen, nicht an Termine

Hier entscheidet sich alles. Der Standardvorschlag lautet „jährliche Prüfung“, und er funktioniert nicht: Ein Jahr nach der letzten Änderung weiß niemand mehr, was sich verändert hat, also wird das Dokument angesehen, für in Ordnung befunden und mit neuem Datum versehen. Der Termin wird eingehalten, die Dokumentation altert trotzdem.

Wirksam ist der umgekehrte Weg: Sie hängen die Prüfung an die Ereignisse, die den Prozess tatsächlich verändern. Die Liste ist kurz und für die meisten Organisationen dieselbe.

• Der Prozessverantwortliche oder ein Hauptausführender wechselt die Stelle
• Eine beteiligte Fachanwendung bekommt ein Release, das den Ablauf berührt
• Eine Zuständigkeit wandert in eine andere Einheit
• Eine rechtliche oder interne Vorgabe ändert Reihenfolge, Fristen oder Freigaben
• Eine Schnittstelle zu einem Dienstleister wird neu verhandelt

Praktisch heißt das: Diese fünf Anlässe stehen im Dokument, und der Prozessverantwortliche wird bei Eintritt aktiv angesprochen – durch die Personalabteilung beim Stellenwechsel, durch die IT beim Release. Das ist kein Werkzeug, das ist eine Absprache. Aber sie ist der Unterschied zwischen einer Dokumentation, die nach achtzehn Monaten noch stimmt, und einer, die niemand mehr öffnet.

Bei größeren Systemumstellungen gehört dieser Punkt ohnehin in den Projektplan – mehr dazu unter Changemanagement bei Systemumstellungen. In Behörden kommen Haushaltsjahr und Beteiligungsrechte als eigene Taktgeber hinzu; das habe ich auf der Seite Projekte in der öffentlichen Verwaltung auseinandergenommen.

Fünf Anzeichen, dass Ihre Dokumentation nicht mehr stimmt

Sie müssen nichts prüfen, um das festzustellen. Es genügt, auf diese fünf Dinge zu achten:

1. Neue Beschäftigte fragen Kolleginnen und Kollegen, obwohl es eine Dokumentation gibt.
2. Im Dokument stehen Namen von Personen, die nicht mehr da sind.
3. Es gibt eine „aktuelle Fassung“ und mindestens eine Kopie, von der niemand sicher sagen kann, welche die aktuelle ist.
4. Screenshots zeigen eine Oberfläche, die es so nicht mehr gibt.
5. Der Prozess enthält keinen einzigen Ausnahmefall – dann beschreibt er nicht den Prozess, sondern den Wunsch.

Zwei Treffer sind normal. Ab drei arbeitet Ihre Organisation neben der Dokumentation her, und die Frage ist nicht mehr, ob sie aktualisiert wird, sondern ob sie neu aufgenommen werden muss.

Prozessdokumentation erstellen oder erstellen lassen: drei Wege

Selbst machen. Für einen überschaubaren Prozess mit einer Zuständigkeit ist das der richtige Weg. Schritt 1, 2 und 5 aus diesem Text genügen; auf BPMN können Sie verzichten.

Einmal begleiten lassen, dann selbst weiterführen. Der häufigste Fall. Ich nehme zwei, drei Prozesse gemeinsam mit Ihnen auf, wir legen Flughöhe, Notation und Pflegeanlässe fest – den Rest machen Ihre Leute danach allein, mit einem Muster, das funktioniert.

Vergeben. Sinnvoll, wenn ein Audit, eine Systemeinführung oder ein Personalabgang einen festen Termin setzt und intern niemand die Zeit hat.

Nur der zweite und der dritte Weg führen zu mir, und ich sage Ihnen im Erstgespräch offen, wenn der erste reicht. Buchen Sie ein Erstgespräch – 30 Minuten genügen meistens, um das zu klären.