Prozessdokumentation Vorlage: So dokumentieren Sie einen Prozess, damit er befolgt wird (2026)

Prozessdokumentation ist die schriftliche Beschreibung, wie eine Arbeit durch Ihre Organisation läuft: vom Ereignis, das sie auslöst, bis zum Ergebnis, das sie beendet. Sie hält fest, welche Phasen es in welcher Reihenfolge gibt, welche Rolle jede Phase verantwortet, was von einer Rolle an die nächste übergeht, was jede Phase hinterlässt und was passiert, wenn der normale Weg blockiert ist. Eine Prozessdokumentation-Vorlage ist das feste Gerüst, in das diese Angaben eingetragen werden. So liest sich der zehnte Prozess wie der erste, und wer einen gelesen hat, findet sich in allen zurecht.

Die meisten Prozesse sind irgendwo bereits dokumentiert — in einem Diagramm aus einem Workshop vor zwei Jahren, auf einer Wiki-Seite, die niemand öffnet, oder im Kopf der einen Person, die ihn von Anfang an macht. Selten fehlt das Dokument. Das Problem ist, dass es nicht befolgt wird, und die drei Gründe dafür sind in jeder Organisation dieselben. Dieser Leitfaden behandelt zuerst das Handwerk: was ein Prozessdokument ist und was nicht, das Standardformat, eine Vorlage zum Kopieren und ein ausgearbeitetes Beispiel. Danach folgen die drei Gründe und was jeweils hilft, dann wo das Dokument und sein Walkthrough in den Tools leben, die Ihr Team schon nutzt, und was die Kollegin bekommt, die es in einer anderen Sprache liest. Denn ein Prozessdokument wird an dem Morgen beurteilt, an dem ein neuer Account Manager, eine neue Pflegekraft oder ein neuer Sachbearbeiter eines Distributors etwas an die nächste Person übergeben muss und nicht weiß, wer das ist.

Was ein Prozessdokument ist — und was nicht

Drei Dokumente beschreiben, wie Arbeit auf Prozessebene erledigt wird. Sie werden oft miteinander verwechselt und auch mit den Verfahrensanweisungen darunter:

Die Karte ist das Bild, das Prozessdokument ist der Text, der das Bild nutzbar macht, und die SOPs sind das Detail unter jedem Kasten. Diese Abgrenzung bestimmt die Länge: Ein Prozessdokument, das erklärt, wie jeder Schritt geklickt wird, ist ein Handbuch, das niemand liest. Eine Prozesskarte ohne Text ist ein Bild, das jeder anders deutet. Die SOP, ihre Vorlage und ihr Überprüfungszyklus stehen in der SOP-Vorlage und in SOP schreiben. Dieser Leitfaden handelt von der Ebene darüber — der, die sagt, wo SOPs nötig sind und wer was an wen übergibt.

Ein Prozessdokument beschreibt außerdem nicht, wie die Arbeit üblicherweise gemacht wird. Es ist der vereinbarte Weg, mit Owner, Version und Prüftermin. Deshalb ist eine Phase, die niemand befolgt, eine Phase, die man ändern muss, oder ein Gespräch, das man führen muss — kein Satz, den man stehen lässt.

Was hineingehört: das Standardformat

Ein brauchbares Prozessdokument besteht aus einem Kopfbereich und acht Abschnitten. Die meisten Vorlagen im Netz enthalten Zweck, Schritte und ein Diagramm und hören dann auf — deshalb werden die meisten Prozessdokumente einmal gelesen und dann nie wieder:

Der Kopfbereich — die Identität des Dokuments, fünf Angaben in einer Zeile: eine ID, die man zitieren kann („PR-HR-02“), eine Version („v1.3“), der Owner — eine namentlich benannte Person, die für den gesamten Prozess verantwortlich ist, keine Abteilung —, das Gültigkeitsdatum und der nächste Prüftermin. Ein Prozess ohne Prüftermin wird geprüft, wenn etwas schiefgeht.

1. Zweck und Ergebnis. Ein oder zwei Sätze: was dieser Prozess liefert, an wen, und woran man erkennt, dass es gut ist — mit einer Zahl, wenn Sie eine haben. „Ein Neuzugang hat am ersten Tag Zugänge, Ausstattung, einen Plan und einen benannten Buddy, und bis Tag 30 ein 30-Tage-Review.“
2. Auslöser und Endzustand. Das Ereignis, das den Prozess startet, und das Ergebnis, das ihn beendet. „Beginnt, wenn der unterschriebene Vertrag im HR-Ordner liegt; endet, wenn das 30-Tage-Review dokumentiert ist.“ Alles zwischen diesen beiden Sätzen ist der Prozess; alles außerhalb ist ein anderes Dokument. Hat der Prozess kein klares Ende, sind es zwei Prozesse.
3. Geltungsbereich. Wann dieser Prozess gilt und wann nicht, unter Nennung der Nachbarprozesse per ID. „Beschäftigte mit einem Vertrag bei uns, in jedem Land. Nicht: freie Mitarbeitende (PR-HR-04); nicht: interne Wechsel (PR-HR-06).“
4. Rollen. Jede Rolle, die in den Phasen vorkommt, mit dem, was sie verantwortet — Rollen, nicht Namen, damit das Dokument eine Neueinstellung übersteht. Eine davon ist der Prozess-Owner, verantwortlich für den gesamten Ablauf, einschließlich der Übergaben, für die standardmäßig niemand zuständig ist.
5. Phasen und Übergaben. Das Herzstück des Dokuments: die Phasen in Reihenfolge, jeweils mit der Rolle, die sie ausführt, dem, was ankommt (Eingang), dem, was die Phase verlässt und wo es festgehalten wird (Ergebnis), an wen es geht und der Frist. Die Übergabe wird ausdrücklich aufgeschrieben — „an: IT, bis Tag −5“ —, weil Prozesse an der Übergabe scheitern: Beide Seiten denken, die andere habe es.
6. Ausnahmen und Eskalation. Die Abzweigungen vom Idealablauf: was passiert, wenn die Genehmigung zu spät kommt, die Bonitätsprüfung scheitert oder der Owner abwesend ist. Jede Ausnahme nennt eine Rolle oder eine Person, die entscheidet, nie „fragen Sie jemanden“. Die letzte Zeile deckt ab, was Sie übersehen haben: „Alles, was hier nicht geregelt ist: Der Prozess-Owner entscheidet, und der Fall wird beim nächsten Review eingebracht.“
7. Kennzahlen. Zwei oder drei Zahlen, die der Owner beobachtet — Durchlaufzeit vom Auslöser bis zum Endzustand, Fälle pro Monat, Anteil der Fälle mit Ausnahme. Kein Dashboard, sondern die Zahlen, die dem Owner zeigen, dass der Prozess abdriftet, bevor sich jemand beschwert.
8. Mitgeltende Unterlagen und Änderungshistorie. Die SOPs unter jeder Phase, die Richtlinie, die der Prozess umsetzt, der Link zur Karte; danach eine Zeile pro Version — Datum, was sich geändert hat, wer es freigegeben hat. Die Historie verhindert, dass derselbe Fehler unter einer neuen Versionsnummer wieder eingeführt wird.

Was draußen bleibt: die Begründung jeder Regel (Aufgabe der Richtlinie), das Klick-für-Klick-Detail einer Phase (Aufgabe der SOP) und alles, worauf eine Person nicht handeln könnte. „Wir legen Wert auf ein reibungsloses Onboarding“ ist eine Gesinnung, keine Phase.

So dokumentieren Sie einen Prozess, damit er befolgt wird

Drei Gründe erklären fast jedes Prozessdokument, das nicht befolgt wird, und für jeden gibt es eine Lösung, die zum Schreiben gehört und nicht zu einer späteren Durchsetzung.

Grund eins: Es beschreibt den Prozess, wie er entworfen wurde, nicht wie er läuft. Das Dokument entstand in einem Workshop, geschrieben von denen, die die Arbeit steuern. Die, die sie ausführen, haben eine andere Version — mit der Tabelle nebenher und dem Kollegen, den man in Phase 3 anruft. Die Lösung: Bilden Sie ihn anhand von Belegen ab, bevor Sie schreiben. Verfolgen Sie drei echte Fälle vom Auslöser bis zum Endzustand und schreiben Sie auf, was tatsächlich passiert ist: die E-Mails, die Nachrichten, die Formulare, die Wartezeiten. Lebt der Prozess in einem Gruppenchat — Bestellungen von Distributoren, die über WhatsApp eintreffen, Schichttausch, der in einer Telegram-Gruppe vereinbart wird —, dann ist der Chat der Beleg, und der Walkthrough beginnt mit seinem Verlauf. Was Export chat Ihnen liefert und wo es endet, steht in WhatsApp-Chat exportieren. Wo sich die drei Fälle unterscheiden, liegt der Grund, warum das Dokument existiert; entscheiden Sie für jeden Unterschied, ob es eine Phase ist, die Sie im Text korrigieren, oder ein Gespräch, das Sie mit dem Team führen.

Grund zwei: Niemand findet die aktuelle Version. Das Dokument liegt in einem Ordner mit vierzig anderen, eine Kopie auf dem Desktop von jemandem, eine dritte Version im Wiki, und wer es an einem Dienstagmorgen braucht, fragt stattdessen eine Kollegin. Die Lösung: Veröffentlichen Sie dort, wo das Team ohnehin liest, mit sichtbarem Kopfbereich. Ein Ort, die aktuelle Version zuerst, der Name des Owners und der Prüftermin ganz oben — so beantwortet der Kopfbereich die Frage „Stimmt das noch?“, nicht das Herumfragen. Und die Phasen sind als Übergaben zwischen Rollen geschrieben, sodass jede Person ihre eigene Phase und die beiden Nachbarphasen in unter einer Minute findet.

Grund drei: Es hat sich geändert, und die, deren Phase sich geändert hat, wurden nie informiert. Ein Review hat die Bonitätsprüfung vor das Kommissionieren gelegt oder einen Schritt für Neuzugänge ergänzt, die umziehen, und das Dokument wurde aktualisiert — aber das Lager und die einstellenden Führungskräfte machten weiter wie zuvor. Die Lösung: Gehen Sie den Prozess mit den Menschen durch, die ihn betreiben, und geben Sie jede Änderung mit den geänderten Zeilen bekannt. Der Walkthrough ist ein Meeting: der Owner und eine Person pro Rolle, die aktuelle Version auf allen Bildschirmen, jede Phase laut vorgelesen von der Person, die sie ausführt, jede Übergabe von beiden Seiten bestätigt. Was der Walkthrough ändert, wird zu einer neuen Version mit einer Zeile in der Historie, und die drei geänderten Zeilen gehen am selben Tag an die Menschen, deren Phasen sie betreffen, an dem Ort, an dem sie ohnehin lesen. Eine Entscheidung, die eine Regel statt einer Phase ändert, gehört zusätzlich ins Entscheidungsprotokoll, mit der Prozess-ID im Eintrag.

Die Reihenfolge also: Wählen Sie einen Prozess mit klarem Anfang und Ende; verfolgen Sie drei echte Fälle; entwerfen Sie zuerst die Phasen in der Vorlage, mit ausdrücklichen Übergaben; ergänzen Sie die Ausnahmen aus dem, was die Fälle gezeigt haben; gehen Sie es mit einer Person pro Rolle durch; veröffentlichen Sie dort, wo das Team liest, mit Owner und Prüftermin im Kopfbereich; tragen Sie den Prüftermin in den Kalender ein. Das Dokument, das daraus entsteht, wird befolgt, weil es stimmt, auffindbar ist und bekannt gemacht wurde — die drei Eigenschaften, die die Vorlage allein nicht liefern kann.

Eine Prozessdokumentation-Vorlage

[Prozess-ID] — [Prozessname]
Version: [n.n] · Owner: [Name, Rolle] · Gültig ab: [Datum] · Nächste Prüfung: [Datum]

1. Zweck und Ergebnis
[Ein oder zwei Sätze — was dieser Prozess liefert, an wen, und woran man erkennt, dass es gut ist, mit einer Zahl, wenn Sie eine haben.]

2. Auslöser und Endzustand
Beginnt, wenn: [das Ereignis] · Endet, wenn: [das Ergebnis, das nun vorliegt]

3. Geltungsbereich
Umfasst: [Fälle, Standorte, Kunden, Länder] · Umfasst nicht: [was ein anderer Prozess abdeckt, mit dessen ID]

4. Rollen
Prozess-Owner: [die eine Person, die für den gesamten Ablauf verantwortlich ist]
[Rolle] — [was sie in diesem Prozess verantwortet]
[Rolle] — [was sie in diesem Prozess verantwortet]

5. Phasen und Übergaben
5.1 [Phase] — [Rolle] — Eingang: [was ankommt] — Ergebnis: [was die Phase verlässt, wo es festgehalten wird] — an: [nächste Rolle] — bis: [Frist]
5.2 [Phase] — [Rolle] — Eingang: … — Ergebnis: … — an: … — bis: …
5.3 [Phase] — [Rolle] — Eingang: … — Ergebnis: … — an: … — bis: …

6. Ausnahmen und Eskalation
Wenn [Bedingung]: [was passiert, wer entscheidet]
Wenn [Bedingung]: [was passiert, wer entscheidet]
Alles, was hier nicht geregelt ist: [Rolle] entscheidet; der Fall wird beim nächsten Review eingebracht.

7. Kennzahlen
[Zwei oder drei Zahlen, die der Owner beobachtet — Durchlaufzeit, Fälle pro Monat, Anteil der Fälle mit Ausnahme — und wo sie abgelesen werden.]

8. Mitgeltende Unterlagen und Änderungshistorie
SOPs: [IDs, eine pro Phase, wo nötig] · Setzt um: [Richtlinie] · Karte: [Link zum Diagramm]
v[n.n] — [Datum] — [was sich geändert hat] — freigegeben von [Name]
v[n.n] — [Datum] — [was sich geändert hat] — freigegeben von [Name]

Die Vorlage ist reiner Text mit fetten Beschriftungen, sodass sie sich ohne Neuformatierung in eine Word-Datei, ein Google Doc, eine Wiki-Seite, ein Slack-Canvas oder eine Chat-Notiz einfügen lässt. Die beiden Abschnitte, die am häufigsten leer bleiben, sind die Übergaben — „an wen, bis wann“ — und der Prüftermin. Genau diese beiden entscheiden, ob der Prozess in einem Jahr noch so läuft, wie das Dokument es sagt.

Ein ausgearbeitetes Beispiel: Onboarding eines Neuzugangs, vom unterschriebenen Vertrag bis Tag 30

Ein Unternehmen mit sechzig Personen und Neueinstellungen in drei Ländern; der Prozess durchläuft vier Rollen und endet, wenn das 30-Tage-Review dokumentiert ist.

PR-HR-02 — Onboarding eines Neuzugangs
Version: 1.3 · Owner: Head of Operations, Inés M. · Gültig ab: 1. Okt. 2026 · Nächste Prüfung: 1. Apr. 2027

1. Zweck und Ergebnis — Ein Neuzugang hat am ersten Tag funktionierende Zugänge, Ausstattung, einen Plan für den ersten Monat und einen benannten Buddy, und bis Tag 30 ein dokumentiertes 30-Tage-Review, in welchem Land auch immer er beginnt.
2. Auslöser und Endzustand — Beginnt, wenn: der unterschriebene Vertrag im HR-Ordner liegt. Endet, wenn: das 30-Tage-Review in der Akte des Neuzugangs dokumentiert ist.
3. Geltungsbereich — Beschäftigte mit einem Vertrag bei uns, in jedem Land, im Büro oder remote. Nicht: freie Mitarbeitende (PR-HR-04); interne Wechsel (PR-HR-06).
4. Rollen — Prozess-Owner: Head of Operations. HR: die Akte, Unterlagen, Gehaltsabrechnung, das Willkommenspaket. IT: Zugänge, Ausstattung, Berechtigungen. Führungskraft: der Plan, der Buddy, die Check-ins. Finanzen: Einrichtung der Gehaltsabrechnung.

5. Phasen und Übergaben
5.1 Akte anlegen — HR — Eingang: der unterschriebene Vertrag — Ergebnis: der Onboarding-Datensatz mit Starttermin, Land, Führungskraft, Sprache; das Willkommenspaket, versendet in der Sprache des Neuzugangs — an: IT und die Führungskraft — bis: zwei Arbeitstage nach Unterschrift
5.2 Zugänge und Ausstattung — IT — Eingang: der Datensatz — Ergebnis: Konten angelegt, Laptop an die Adresse des Neuzugangs versandt, Berechtigungen gemäß Rollenprofil; Bestätigung im Datensatz — an: HR — bis: fünf Arbeitstage vor dem Starttermin
5.3 Unterlagen und Gehaltsabrechnung — HR, danach Finanzen — Eingang: der Datensatz, die Unterlagen des Neuzugangs (Arbeitserlaubnis oder Anmeldung, wo das Land sie verlangt) — Ergebnis: der Neuzugang in der Gehaltsabrechnung, Unterlagen in der Akte — an: die Führungskraft — bis: der Starttermin
5.4 Der erste Monat, geplant — Führungskraft — Eingang: der Datensatz — Ergebnis: ein 30-Tage-Plan in der Akte, ein benannter Buddy, die erste Woche im Kalender des Neuzugangs, der Willkommens-Call mit dem Team gebucht — an: den Neuzugang, am ersten Tag — bis: der Tag vor dem Start
5.5 Tag eins — Führungskraft und Buddy — Eingang: der Plan — Ergebnis: der Willkommens-Call durchgeführt, der Plan besprochen, die offenen Fragen des Neuzugangs im Channel des Teams festgehalten — an: den Neuzugang — bis: Ende des ersten Tages
5.6 Check-ins — Führungskraft — Eingang: der Plan, die festgehaltenen Fragen — Ergebnis: ein Check-in an Tag 7 und an Tag 30, das 30-Tage-Review in der Akte dokumentiert — an: HR, um den Datensatz abzuschließen — bis: Tag 30

6. Ausnahmen — Arbeitserlaubnis oder Anmeldung bis zum Starttermin nicht durch: Der Neuzugang beginnt mit den Aufgaben, die die Führungskraft als ohne sie zulässig markiert; HR verantwortet die Nachverfolgung, und das Datum kommt in den Datensatz. Laptop bis Tag −2 nicht geliefert: IT versendet ein Leihgerät aus dem Büro-Bestand; der Head of Operations wird am selben Tag informiert. Neuzugang in einem Land, in dem wir noch nie eingestellt haben: Phase 5.3 pausiert; der Head of Operations entscheidet innerhalb von drei Arbeitstagen über das Employer-of-Record-Modell (PR-HR-05).
7. Kennzahlen — Arbeitstage von der Unterschrift bis zu fertigen Zugängen (Ziel ≤ 7); Anteil der Neuzugänge mit einem dokumentierten 30-Tage-Review bis Tag 30 (Ziel 100 %); in Woche eins festgehaltene Fragen, gelesen im Quartals-Review, um zu sehen, welche Phase sie immer wieder hervorbringt.
8. Mitgeltende Unterlagen — SOP-IT-03 „Neue Konten und Zugänge“; SOP-HR-08 „Einrichtung der Gehaltsabrechnung je Land“; Onboarding-Richtlinie §2; Karte: das Swimlane-Diagramm im HR-Ordner.
v1.3 — 1. Okt. 2026 — Willkommenspaket wird jetzt in der Sprache des Neuzugangs versendet; Check-in an Tag 7 ergänzt — freigegeben von Inés M.
v1.2 — 3. Juni 2026 — Laptop-Versand auf fünf Tage vor Start vorverlegt, nach zwei verspäteten Lieferungen — freigegeben von Inés M.

Beachten Sie, was das Beispiel leistet. Jede Phase nennt die Rolle, was ankommt, was die Phase verlässt und wo es festgehalten wird, wer es als Nächstes bekommt und bis wann. Eine Übergabe, die nicht stattgefunden hat, zeigt sich so als Lücke im Datensatz und nicht als Überraschung an Tag eins. Jede Ausnahme nennt, wer entscheidet. Die Kennzahlen sind drei Zahlen, kein Dashboard. Und die Historie erklärt, warum die Phasen so sind, wie sie sind: Phase 5.2 hat ihre Frist, weil zwei Laptops zu spät kamen, und der Check-in an Tag 7 existiert, weil das Review an Tag 30 immer wieder Fragen fand, die in der ersten Woche hätten geklärt werden sollen.

Ein kürzeres zweites Beispiel, die Form eines Vertriebsprozesses für einen Exporteur mit Distributoren:

PR-SA-01 — Bestellung bis Lieferung · Owner: Export Manager · Beginnt, wenn: die Bestellung eines Distributors eingeht · Endet, wenn: die Lieferung bestätigt und die Rechnung versandt ist
1. Bestellprüfung — Account Owner — Eingang: die Bestellung — Ergebnis: Bestellung im System bestätigt, oder eine Rückfrage an den Distributor — an: Finanzen — bis: ein Arbeitstag
2. Bonitätsprüfung — Finanzen — Eingang: die bestätigte Bestellung — Ergebnis: freigegeben, oder mit Begründung gesperrt — an: Lager — bis: ein Arbeitstag
3. Kommissionieren und Verpacken — Lager — Eingang: die freigegebene Bestellung — Ergebnis: verpackt, mit Packliste — an: Logistik — bis: drei Arbeitstage
4. Dokumente und Versand — Logistik — Eingang: die verpackte Bestellung — Ergebnis: die Sendung gebucht, die Dokumente für das Bestimmungsland beigefügt, Tracking im System — an: Finanzen und den Account Owner — bis: ein Arbeitstag
5. Rechnung und Bestätigung — Finanzen, danach der Account Owner — Eingang: die Sendung — Ergebnis: Rechnung versandt; Lieferung mit dem Distributor bestätigt und dokumentiert — Wenn die Bonität gesperrt ist: Der Account Owner ruft den Distributor innerhalb eines Arbeitstags an; der Export Manager entscheidet über Freigabe oder Vorkasse.

Zwölf Zeilen, und ein neuer Sachbearbeiter beim Distributor und ein neuer Mitarbeiter im Lager wissen beide, auf wen sie warten.

Wo das Prozessdokument und sein Walkthrough in den Tools leben, die Sie bereits nutzen

Das Dokument selbst lebt dort, wo die Dokumente des Teams leben — eine Word-Datei in einer gemeinsamen Bibliothek, ein Google Doc, eine Seite in einem Wiki, ein Canvas in einem Channel. Der Walkthrough ist ein Meeting, und jede Plattform hat einen Ort für das, was der Walkthrough hinterlässt; jede hört an einer anderen Stelle auf. Nur dokumentiertes Verhalten, von den eigenen Seiten der Anbieter, mit dem Monat, in dem die jeweilige Seite geprüft wurde:

Zwei Dinge sind überall gleich. Das Prozessdokument ist eine Datei in der einen Sprache, in der es geschrieben wurde, und die Kollegin, die eine andere Sprache liest, liest diese oder eine Kopie, die jemand angefertigt hat; und was der Walkthrough geändert hat, gelangt nur ins Dokument, wenn eine Person es danach eintippt, in derselben Sprache. Die Übersetzung, die diese Suiten dokumentieren, gehört zum Call, nicht zum Dokument: Microsoft dokumentiert live übersetzte Untertitel in Teams-Meetings, wenn der Organisator eine Teams-Premium- oder Microsoft-365-Copilot-Lizenz hat, und Google dokumentiert übersetzte Untertitel in Meet in geeigneten Workspace-Tarifen (beides geprüft im August 2026). Was jede Lösung abdeckt und wo sie aufhört, steht in Live-Übersetzung in Microsoft Teams und Live-Übersetzung in Google Meet. Der Prozess, den die neue Sachbearbeiterin am Dienstag öffnet, und der Walkthrough, der ihn geändert hat, sind andere Objekte als diese Untertitel, und sie werden in der Sprache gelesen, in der sie getippt wurden.

Wie Prozess, Walkthrough und Verlauf für jedes Mitglied lesbar bleiben

InterMIND ist ein Raum für die Kommunikation, in dem die Arbeit eines Teams in einem Channel lebt. Das fertige Prozessdokument hat deshalb ein naheliegendes Zuhause: den Channel des Teams, das den Prozess betreibt — ein Channel für die Menschen aus HR, IT, Finanzen und den einstellenden Führungskräften, die jeweils eine Phase verantworten. Wird es als Notiz gepostet — eine Rich-Text-Nachricht mit Überschriften und nummerierten Listen, später über ihr eigenes Menü bearbeitbar —, liest es jedes Mitglied in der eigenen Sprache, das Original einen Umschalter entfernt, und es wird angeheftet, damit die aktuelle Version das Erste ist, was ein neuer Kollege findet. Ist der Bearbeitungsverlauf eingeschaltet, erscheint die frühere Formulierung einer geänderten Phase über dem aktuellen Text als Diff auf Wortebene mit Zeitstempel. Wird es als Datei hochgeladen — ein PDF oder ein Word-Dokument —, trägt es in jedem Tarif eine KI-Zusammenfassung in der Sprache des Lesers, wobei jeder Punkt auf den Absatz verweist, aus dem er stammt; die einseitige Lesefassung existiert also, bevor jemand sie geschrieben hat. In kostenpflichtigen Tarifen öffnet sich die Datei selbst übersetzt in die Sprache des Lesers (30 Sprachen für Dokumente). Bleibt die Masterkopie in einem Dokument-Tool, landen ihre Aktualisierungen per E-Mail im Channel: Der Host des Channels vergibt ihm eine eigene Adresse, und eine dorthin gesendete Nachricht erscheint als reguläre Nachricht mit benanntem Absender und erhaltenen Anhängen.

Der Walkthrough beginnt in diesem Channel. Während des Calls kommt die aktuelle Version mit Share to conference neben die Videokacheln auf aller Bildschirme — eine Notiz oder ein im Chat verlinktes Google-Docs- oder OneDrive-Dokument —, und jeder Teilnehmer scrollt unabhängig und liest sie in der eigenen Sprache; eine geteilte Notiz bearbeitet die teilende Person live, während der Raum zusieht, wie die geänderte Übergabe Gestalt annimmt. Wenn der Call endet, wird das Recap aus dem Meeting selbst geschrieben — eine Zusammenfassung, die als vereinbart, offen oder strittig markierten Punkte, die Action items mit Verantwortlichen, jede Zeile mit ihrem Zeitstempel —, und die während der Sitzung geteilten Dokumente tragen ihre Zusammenfassungen neben dem Gesagten bei. Es kommt per E-Mail, als Nachricht im Channel und als Link im Kalendereintrag, und jedes angemeldete Mitglied liest es in der eigenen Sprache: Das Protokoll wird pro Leser übersetzt, nicht einmal in der Sprache geschrieben, die der Raum zufällig benutzt hat. Jedes Mitglied kann es bearbeiten, jede Änderung behält Autor und Versionsverlauf, und der Channel bewahrt das Recap jeder vergangenen Sitzung auf — der Walkthrough, aus dem v1.3 entstand, ist also einen Klick von der Notiz entfernt, die v1.3 ist. Der eigene Assistent eines Mitglieds — Claude, ChatGPT, Copilot oder Gemini, verbunden über den MCP-Connector — durchsucht Recaps, Transkripte, Chats und den Text geteilter Dateien in einer einzigen Frage, „Warum wird der Laptop fünf Tage vor dem Starttermin versandt?“, und liest das Dokument selbst; das läuft für Organisationen mit eingeschalteten KI-Funktionen. Neben der Tabelle oben ist der Unterschied eine schlichte Tatsachenfeststellung: Die Untertitel, die diese Suiten dokumentieren, übersetzen den Call, während er läuft; hier sind der Prozess, sein Walkthrough und seine Historie ein einziger Datenbestand, den jedes Mitglied in der eigenen Sprache liest.

Die Menschen, die an einem Prozess beteiligt sind, sind nicht immer Beschäftigte. Ein Bestellsachbearbeiter eines Distributors, ein Gehaltsabrechnungsdienstleister in einem anderen Land, ein freier Mitarbeiter, der eine Phase verantwortet: Ein externes Mitglied des Channels tritt per E-Mail mit einem kostenlosen Konto bei und liest den Prozess und seine Historie wie alle anderen. Eine Person ohne Konto ist Gast eines einzelnen Meetings — sie nimmt per Link, vom Telefon, kostenlos am Walkthrough teil, hört ihn live in der eigenen Sprache und erhält danach kein Protokoll. Der Host stellt den Raum bereit und zahlt in einem kostenpflichtigen Tarif nur für die Mitglieder, die in den vorherigen 28 Tagen aktiv waren — ein Meeting beigetreten, im Chat geschrieben oder den Assistenten gefragt; Mitglieder, die still werden, behalten ihren Zugang kostenlos.

• Ein vollständiges Recap öffnen — ein echtes Protokoll, erzeugt vom selben Code, der Ihres schreibt.
• Die Live-Demo ausprobieren — ohne Anmeldung; sprechen Sie und hören Sie den Raum je Zuhörer übersetzt.

Prozessdokumentation als Handwerk überlebt jedes Tool: Jemand muss weiterhin drei echte Fälle verfolgen, die Phasen als Übergaben schreiben, die eine zweite Person prüfen kann, und das Ganze mit einer Person pro Rolle durchgehen. Was nicht überleben muss, ist die zweite Aufgabe — von jeder Version von Hand eine übersetzte Kopie pflegen und das, was der Walkthrough geändert hat, in einer Sprache neu eintippen, für Menschen, die andere lesen.

FAQ

Was ist Prozessdokumentation?

Prozessdokumentation ist die schriftliche Beschreibung, wie eine Arbeit durch eine Organisation läuft, vom Ereignis, das sie auslöst, bis zum Ergebnis, das sie beendet: die Phasen in Reihenfolge, die Rolle, die jede verantwortet, was von einer Rolle an die nächste übergeht, was jede Phase hinterlässt, die Ausnahmen abseits des normalen Wegs und wer über sie entscheidet, und die wenigen Zahlen, die der Owner beobachtet. Sie steht zwischen der Prozesskarte — dem Diagramm — und den SOPs, die beschreiben, wie jede Phase Schritt für Schritt ausgeführt wird.

Was gehört in eine Prozessdokumentation?

Ein Kopfbereich mit ID, Version, Owner, Gültigkeitsdatum und nächstem Prüftermin; Zweck und Ergebnis; der Auslöser und der Endzustand; der Geltungsbereich, einschließlich dessen, was der Prozess nicht abdeckt; die Rollen, mit einem namentlich benannten Prozess-Owner; die Phasen in Reihenfolge, jeweils mit Rolle, Eingang, Ergebnis und dem Ort, an dem es festgehalten wird, der nächsten Rolle und der Frist; Ausnahmen und Eskalation mit je einer entscheidenden Instanz; zwei oder drei Kennzahlen; und die zugehörigen SOPs, die Richtlinie, die er umsetzt, und eine Änderungshistorie.

Wie dokumentiert man einen Prozess Schritt für Schritt?

Wählen Sie einen Prozess mit klarem Auslöser und Endzustand. Verfolgen Sie drei echte Fälle von Anfang bis Ende und schreiben Sie auf, was tatsächlich passiert ist, einschließlich der Abzweigungen. Entwerfen Sie zuerst die Phasen in der Vorlage, jede als Übergabe — Rolle, Eingang, Ergebnis, nächste Rolle, Frist. Ergänzen Sie die Ausnahmen, die die Fälle gezeigt haben, jeweils mit der Angabe, wer entscheidet. Füllen Sie Zweck, Geltungsbereich, Rollen und Kopfbereich aus. Gehen Sie das Dokument mit einer Person pro Rolle durch, jede liest ihre eigene Phase laut vor und bestätigt die Übergaben. Veröffentlichen Sie es dort, wo das Team ohnehin liest, mit sichtbarem Owner und Prüftermin, und tragen Sie den Prüftermin in den Kalender ein.

Was ist der Unterschied zwischen Prozessdokumentation und einer SOP?

Die Prozessdokumentation beschreibt, wie Arbeit über Rollen und Teams hinweg fließt — Phasen, Übergaben, was jede Phase hinterlässt —, auf der Ebene einer Seite pro Prozess. Eine SOP beschreibt, wie eine dieser Phasen von einer Rolle Schritt für Schritt ausgeführt wird, bis hinunter zum Ergebnis jedes Schritts. Das Prozessdokument sagt, wo SOPs nötig sind und wer was an wen übergibt; eine SOP sagt einer Person, was sie am Dienstagmorgen tun soll. Eine SOP für einen ganzen teamübergreifenden Prozess zu schreiben, ergibt ein Handbuch, das niemand öffnet; ein Prozessdokument im Detailgrad einer SOP zu schreiben, ergibt dasselbe.

Welche Beispiele für Prozessdokumentation gibt es?

Jeder wiederkehrende Ablauf, der Rollen überschreitet und einen klaren Anfang und ein klares Ende hat: das Onboarding eines Neuzugangs vom unterschriebenen Vertrag bis Tag 30; eine Bestellung von einem Distributor bis zur bestätigten Lieferung und zur Rechnung; eine Kundenbeschwerde vom Eingang bis zum Abschluss; ein Patient von der Überweisung bis zum ersten Termin; ein neues Produkt vom freigegebenen Briefing bis zur Aufnahme in den Katalog; der Monatsabschluss von den Zeiterfassungen bis zu den versandten Rechnungen. Das ausgearbeitete Beispiel in diesem Leitfaden ist das Onboarding — sechs Phasen über vier Rollen, drei Ausnahmen, eine Historie aus drei Versionen —, mit einem kürzeren Beispiel von der Bestellung bis zur Lieferung danach.

Gibt es eine Vorlage für Prozessdokumentation in Word oder Google Docs?

Die Vorlage in diesem Leitfaden ist reiner Text mit fetten Beschriftungen, sodass sie sich ohne Neuformatierung in ein Word-Dokument, ein Google Doc, eine Wiki-Seite, ein Slack-Canvas oder eine Chat-Notiz einfügen lässt. Das Format ist wichtiger als die Datei: Was auch immer das Dokument aufnimmt, braucht den Kopfbereich mit Owner und Prüftermin, den Auslöser und den Endzustand, als Übergaben zwischen Rollen geschriebene Phasen mit Frist, eine benannte entscheidende Instanz für jede Ausnahme und eine Änderungshistorie — und es muss dort leben, wo die Menschen, die den Prozess betreiben, ohnehin lesen.

Wer sollte Prozessdokumentation schreiben?

Der Prozess-Owner — eine namentlich benannte Person, die für den gesamten Ablauf verantwortlich ist, meist die Führungskraft des Bereichs, durch den der Prozess hauptsächlich läuft — gemeinsam mit einer Person aus jeder Rolle, die eine Phase übernimmt. Der Owner hält den Stift und den Prüftermin; die, die die Phasen ausführen, sind Mitautoren, denn ein Dokument, das über sie statt mit ihnen geschrieben wird, beschreibt den Prozess, wie er entworfen wurde, während der echte in ihren Köpfen lebt. Ein Neuling ist der Tester: Findet er seine Phase und die beiden Nachbarphasen in unter einer Minute, funktioniert das Dokument.

Wie oft sollte Prozessdokumentation aktualisiert werden?

Zum Prüftermin in ihrem Kopfbereich — alle sechs oder zwölf Monate sind üblich, kürzer bei regulierten Prozessen — und früher, wenn eines von vier Dingen passiert: Eine Übergabe ist gescheitert und niemand war zuständig, ein Tool oder Formular, von dem eine Phase abhängt, hat sich geändert, die Regel, die der Prozess umsetzt, hat sich geändert, oder die Kennzahlen haben sich verschoben. Jede Aktualisierung ist eine neue Version mit einer Zeile in der Historie, die sagt, was sich geändert hat und wer es freigegeben hat; die alte Version bleibt erhalten, und die Menschen, deren Phasen sich geändert haben, werden am selben Tag mit den geänderten Zeilen informiert.

Quellen: Microsoft — Take meeting notes in Microsoft Teams; Microsoft — Use live captions in Microsoft Teams meetings; Zoom — Using Meeting Summary with AI Companion; Google — Calendar & Meet settings for "Take notes for me"; Google Meet — "Take notes for me" in Google Meet; Google Meet — Use translated captions; Slack — Meeting agenda template (canvas). Die Seiten von Microsoft, Google und Slack zu Meeting-Notizen und Vorlagen wurden im Oktober 2026 geprüft; die Zoom-Seite zur Meeting-Zusammenfassung und die Teams- und Meet-Seiten zu Untertiteln im August 2026. Anbieter ändern Tarife, Funktionen und Sprachlisten im Lauf der Zeit; prüfen Sie deren Seiten auf den aktuellen Stand.