Prozessdokumentation Leitfaden 2026: Workflows + Screenshots
Prozessdokumentation ist die schriftliche Aufzeichnung darüber, wie eine Aufgabe tatsächlich erledigt wird — die Schritte, die Verantwortlichen, die Screenshots und die Signale, dass etwas schiefgegangen ist. Gut gemacht, verkürzt sie die Einarbeitungszeit, schützt Wissen, wenn Mitarbeiter gehen, und liefert Audit- und Compliance-Teams einen klaren Nachweis. Dieser Leitfaden geht die Methodik von Anfang bis Ende durch, mit einem 5-Schritte-Framework, das du auf jeden Workflow anwenden kannst.
Wenn du eher nach einem Tool als nach einer Methode suchst, haben wir das in unserer Übersicht der besten Tools für Prozessdokumentation abgedeckt. Wenn du speziell ein SOP-Layout brauchst, schau dir unsere Vorlagen für Standard Operating Procedures an. Dieser Artikel ist die Methodik-Ebene über beidem — wie du über Prozessdokumentation nachdenkst, sie erfasst und pflegst, unabhängig davon, welches Tool oder welche Vorlage du wählst.
Was ist Prozessdokumentation?
Prozessdokumentation ist eine schriftliche, visuelle oder Video-Aufzeichnung, die erklärt, wie eine wiederkehrende geschäftliche Aktivität durchgeführt wird — wer sie macht, in welcher Reihenfolge, mit welchen Inputs und nach welchem Standard. Sie umfasst die Artefakte (SOPs, Runbooks, Prozesslandkarten, Arbeitsanweisungen) sowie die Praxis, diese Artefakte aktuell zu halten. Ziel ist Reproduzierbarkeit: Jede qualifizierte Person sollte der Doku folgen und dasselbe Ergebnis erzielen können.
Häufig werden die Begriffe Prozessdokumentation, SOP und Runbook vermischt. Das ist nicht dasselbe.
- Prozessdokumentation ist der Oberbegriff. Sie umfasst jedes Artefakt, das erklärt, wie Arbeit erledigt wird.
- Eine Standard Operating Procedure (SOP) ist eine Art Prozessdoku — eine Schritt-für-Schritt-Anleitung für eine einzelne, wiederholbare Aufgabe. Jede SOP ist Prozessdokumentation, aber nicht jede Prozessdokumentation ist eine SOP.
- Ein Runbook ist eine SOP für Systemarbeit, oft genutzt bei Vorfällen oder geplanten Operationen (ein Deploy, ein Datenbank-Failover, ein hängender Job).
Stell dir Prozessdokumentation als Portfolio vor. SOPs, Runbooks, Entscheidungsbäume und Prozesslandkarten sind die Elemente darin.
Warum Prozessdokumentation wichtig ist
Teams, die auf Dokumentation verzichten, zahlen meist später dafür — mit Einarbeitungszeit, verfehlten Audits oder Wissen, das die Tür nach draußen findet, wenn jemand kündigt. Das bringt dir gute Dokumentation tatsächlich.
Schnellere Einarbeitung. Neue Mitarbeiter können die Doku lesen, die eingebettete Aufnahme ansehen und die Arbeit selbst ausprobieren. Du musst dich nicht mehr auf einen einzelnen erfahrenen Kollegen verlassen, der jedes Quartal dieselbe Erklärung wiederholt.
Wissenserhalt. Wenn die Person, die zehn Jahre lang die Lohnabrechnung gemacht hat, einen neuen Job antritt, geht ihr Workflow nicht mit ihr. Die Doku hält das Muskelgedächtnis fest, das ihr Nachfolger sonst von Grund auf neu aufbauen müsste.
Audit und Compliance. SOC 2, ISO 27001, HIPAA und die meisten anderen Frameworks verlangen Nachweise, dass kritische Prozesse schriftlich festgehalten, betreut und überprüft werden. Eine saubere Dokumentationsbibliothek verkürzt Audits und reduziert Beanstandungen.
Konsistenz im Maßstab. Fünf Customer-Success-Mitarbeiter, die dieselbe Aufgabe auf fünf verschiedene Arten erledigen, produzieren fünf verschiedene Ergebnisse. Dokumentation richtet die Arbeit aus, ohne mikrozumanagen.
Bessere Delegation. Ein Manager, der seinen Prozess dokumentiert hat, kann ihn an einen Kollegen übergeben, ohne zwei Stunden in Meetings zu verbringen. Die Doku trägt den Kontext.
Kontinuierliche Verbesserung. Du kannst nicht verbessern, was du nicht siehst. Einen Prozess aufzuschreiben zwingt dich, ihn anzuschauen — und das allein bringt redundante Schritte, kaputte Übergaben und veraltete Tools an die Oberfläche.
Arten von Prozessdokumentation
Es gibt nicht das eine richtige Format. Das Format folgt der Zielgruppe und dem Detailgrad, den die Arbeit verlangt.
| Typ | Geeignet für | Typische Länge |
|---|---|---|
| Prozesslandkarte | Übersicht, wer was teamübergreifend tut | 1 Seite |
| SOP | Einzelne wiederholbare Aufgabe mit festem Ergebnis | 1–3 Seiten |
| Runbook | Systembetrieb, Vorfälle, Deploys | 2–5 Seiten |
| Arbeitsanweisung | Ein Schritt innerhalb einer größeren SOP | Halbe Seite |
| Entscheidungsbaum | Verzweigte Workflows mit bedingter Logik | 1 Seite |
| Rollenbasierter Workflow | Funktionsübergreifender Prozess pro Rolle | 2–4 Seiten |
| Knowledge-Base-Artikel | Self-Service-Antwort auf eine einzelne Frage | 1–2 Seiten |
Ein gereiftes Team braucht meist mehr als eines davon. Ein Finanzabschluss zum Beispiel kann oben eine Prozesslandkarte sein, mehrere SOPs darunter und ein Runbook für den Job des Abschlusssystems.
Der 5-Schritte-Workflow für Prozessdokumentation
Jedes Framework, das du gesehen hast — Atlassian, Asana, Process Street — läuft im Wesentlichen auf denselben Bogen hinaus. Hier ist eine straffe Version, die funktioniert, egal ob du ein Zwei-Personen-Team oder ein reguliertes Unternehmen bist.
Schritt 1: Den Prozess identifizieren
Nicht jede Aufgabe verdient eine Doku. Eine Doku zu schreiben, die niemand liest, ist schlimmer als keine zu schreiben — sie altert schlecht und untergräbt das Vertrauen in die gesamte Dokumentationsbibliothek. Nutze drei Filter, um zu entscheiden, welche Prozesse zuerst drankommen.
- Häufigkeit. Eine wöchentlich erledigte Aufgabe hat höhere Priorität als eine, die alle drei Jahre vorkommt. Häufige Aufgaben summieren die Einsparungen.
- Komplexität. Ein 30-Schritte-Workflow mit Verzweigungen und Übergaben braucht eher Dokumentation als eine 2-Klick-Aufgabe, die jeder erraten kann.
- Geschäftliche Auswirkung. Alles, was Umsatz, Compliance, Sicherheit oder Kundenvertrauen beeinflusst, gehört nach oben, auch wenn es selten ist.
Eine einfache Reihung: Liste jeden wiederkehrenden Prozess in deinem Team auf, bewerte jeden auf den drei Filtern von 1 bis 5 und beginne mit dem oberen Ende der Liste. Widerstehe dem Drang, alles auf einmal zu dokumentieren. Zehn gut gepflegte Dokus schlagen hundert veraltete.
Schritt 2: Den Ist-Zustand erfassen
Bevor du etwas schreibst, schau zu, wie die Arbeit passiert. Die Lücke zwischen der Beschreibung eines Prozesses in einem Meeting und seiner tatsächlichen Ausführung am Bildschirm ist fast immer größer, als die Leute denken.
Drei Erfassungstechniken funktionieren gut zusammen.
- Den Subject Matter Expert (SME) interviewen. Reserviere 30 Minuten. Bitte ihn, den Prozess laut, in der richtigen Reihenfolge, ohne die kleinen Klicks zu überspringen, durchzugehen. Nimm das Gespräch auf.
- In Echtzeit beobachten. Setz dich zu ihm — oder teile einen Call —, während er die Aufgabe tatsächlich erledigt. Notiere jedes Detail, das er als selbstverständlich behandelt.
- Den Workflow per Bildschirmaufnahme festhalten. Mach eine End-to-End-Aufnahme, in der der SME den Prozess in normaler Geschwindigkeit ausführt. Die Aufnahme wird zu deiner Quelle der Wahrheit für Schritte, Timing und Bildschirmzustand.
Für Schritt 3 funktioniert jedes Aufnahmetool. Eingebaute OS-Recorder (QuickTime auf Mac, Xbox Game Bar auf Windows) sind für einmalige Aufnahmen okay. Wenn du regelmäßig Prozesse dokumentierst, spart ein dediziertes Tool wie ScreenSnap Pro Zeit, weil du in derselben App ein Video aufnehmen, ergänzende Screenshots erstellen und annotieren kannst — auf Mac und Windows. Darauf kommen wir in Schritt 4 zurück.
Schritt 3: Die Dokumentation strukturieren
Sobald du Aufnahme und Notizen hast, entscheide dich für das Format. Passe das Artefakt an die Arbeit an — zwinge keine 30-Schritte-SOP auf eine Aufgabe, die einen einseitigen Entscheidungsbaum will.
Eine zuverlässige Struktur für die meisten Prozessdokumente:
- Titel und Zweck. Ein Satz: was dieser Prozess macht und warum es ihn gibt.
- Verantwortlicher und Reviewer. Eine namentlich genannte Person, kein Team. Reviewer sind die SMEs, die Änderungen abnehmen.
- Geltungsbereich. Was im Scope ist, was nicht und was den Prozess auslöst.
- Inputs und Voraussetzungen. Tools, Zugriffe, Daten, Genehmigungen.
- Schritte. Nummeriert, in Reihenfolge, in aktiver Sprache. Eine Aktion pro Schritt.
- Outputs. Was der Prozess produziert und wo die Artefakte liegen.
- Ausnahmen. Was zu tun ist, wenn der Happy Path bricht.
- Versionsverlauf. Datum, Autor, Zusammenfassung der Änderung.
Wähle die Tiefe bewusst. Ein Prozess für Senior Engineers kann knapp sein — sie brauchen nur die ungewöhnlichen Stellen. Ein Prozess für einen brandneuen Mitarbeiter braucht mehr Screenshots, mehr Kontext und mehr „Wenn du X siehst, mach Y".
Schritt 4: Visuelles ergänzen
Reine Text-Prozessdokus scheitern in der Praxis fast immer. Leute überfliegen. Sie übersehen Schritte. Sie klicken den falschen Button. Visuelles behebt das — aber nur, wenn du es an den richtigen Stellen platzierst und sauber hältst.
Drei Regeln für Visuelles in Prozessdokumenten:
- Jeder UI-Schritt bekommt einen Screenshot. Wenn ein Schritt sagt „Öffne das Einstellungs-Panel", zeig, wie das Einstellungs-Panel aussieht.
- Annotiere die Aktion. Eine rote Box um den Button, eine Nummernmarkierung für die Reihenfolge, eine kurze Bildunterschrift fürs Warum.
- Reduziere Rauschen. Schneide unzugehörige Tabs, Browser-Chrome und persönliche Infos weg. Verwische alles Sensible.
Hier passt ScreenSnap Pro natürlich rein. Es erfasst Region, Fenster, Vollbild, scrollende-Fenster-äquivalente Setups (per Aufnahme), Bildschirmvideo, Webcam, Mikrofon und Systemton — alles in einer App auf Mac und Windows für 29 $ einmalig, kein Abo. Das Annotations-Toolkit deckt 15 Werkzeuge ab (Pfeile, nummerierte Counter-Markierungen, Verwischen, Pixeln, Marker, Formen, Text), und die 150+ Hintergrundverläufe verwandeln Roh-Screenshots mit einem Klick in dokureife Visuals. Wenn du nur einen vorhandenen Screenshot markieren willst, bewältigt unser kostenloses Bild-Annotations-Tool Pfeile und Hinweise im Browser. Für polierte Hero-Style-Screenshots in einer Doku rahmt der Screenshot-Hintergrund-Generator jedes Bild in einem sauberen Verlaufsrahmen ein.
Für die reine Technik — wann zuschneiden, wo Hinweise platzieren, welche Dateigröße anvisieren — deckt unser Leitfaden zu Screenshots in technischer Dokumentation die Standards in der Tiefe ab.
Schritt 5: Reviewen, versionieren, veröffentlichen
Eine Doku, die ohne Review live geht, ist ein Entwurf, der vorgibt, kanonisch zu sein. Bau eine straffe Schleife: Peer-Review, Versionskontrolle, Verantwortlicher zugewiesen, dann veröffentlichen.
Peer-Review. Lass einen Kollegen den Prozess durchführen, indem er nur der Doku folgt — keine Hilfe vom SME. Jede Stelle, an der er hängenbleibt, ist eine Stelle zum Klarstellen. Das ist der Schritt mit dem höchsten Wert im gesamten Workflow.
Versionskontrolle. Jede Doku hat eine Versionsnummer, ein Last-Updated-Datum und einen einzeiligen Changelog am Ende. Wenn du in einem Wiki arbeitest, nutze die eingebaute Historie. Wenn du in Git arbeitest, branch und PR jede Änderung.
Verantwortlicher / DRI. Ein Directly Responsible Individual (DRI) besitzt die Doku. Sein Name steht oben. Er genehmigt Änderungen und wird angepingt, wenn der Review-Zyklus fällig ist. Kein Verantwortlicher = niemand hält sie aktuell.
Am richtigen Ort veröffentlichen. Kunden-Dokus gehören ins Help Center. Interne SOPs gehören ins Wiki. Runbooks leben neben den Systemen, die sie beschreiben. Verteile sie nicht — Auffindbarkeit zählt mehr als Ästhetik.
Genug von langweiligen Screenshots? Probier ScreenSnap Pro.
Wunderschöne Hintergründe, professionelle Annotationen, GIF-Aufnahme und sofortiges Cloud-Sharing — alles in einer App. Einmalig 29 $, für immer deins.
Sieh, was es kannBest Practices: Dokumentation, die Leute tatsächlich nutzen
Die meisten Dokumentationsbibliotheken scheitern nicht, weil der Inhalt schlecht ist, sondern weil niemand vertraut, dass der Inhalt aktuell ist. Diese Gewohnheiten halten Dokus am Leben.
- Aktive Sprache, zweite Person. „Klicke auf Speichern", nicht „Der Speichern-Button sollte geklickt werden".
- Ein Schritt pro Nummer. Wenn ein Schritt zwei Verben hat, splitte ihn.
- Screenshots für jeden UI-Schritt. Worte allein verlieren gegen ein klares Bild.
- Hinweise auf jedem Screenshot. Rote Box um den Klick, Nummer für die Reihenfolge, kurze Bildunterschrift fürs Warum.
- Versionskontrolle mit sichtbarem Changelog. Leser wollen sehen, wann sich zuletzt etwas geändert hat und warum.
- Ein geplanter Review-Zyklus. Vierteljährlich für stabile Prozesse, monatlich für sich schnell ändernde. Kalendereinladungen, keine Hoffnungen.
- Ein klar benannter Verantwortlicher. Person, kein Team. Der Verantwortliche bekommt die Review-Erinnerungen.
- Ein „Problem melden"-Link. Mach es Lesern leicht, einen veralteten Schritt zu kennzeichnen. Die meisten veralteten Dokus werden von Lesern entdeckt, nicht von Auditoren.
- Vorlagen für übliche Formen. Jedes Mal dasselbe SOP-Layout. Leser lernen einmal, wo sie nachschauen müssen, und vertrauen dann darauf.
Vergleiche diese zwei Beispiele. Das erste ist, wie die meisten Dokus aussehen. Das zweite, wie sie aussehen sollten.
Häufige Fehler
Dieselben fünf Probleme tauchen in jeder Dokumentationsbibliothek auf, die wir geprüft haben.
Zu lang. Eine 40-seitige SOP für eine 10-Minuten-Aufgabe sagt dir, dass der Autor Gründlichkeit performt hat, nicht den Leser gelöst hat. Kürze sie.
Keine Screenshots. Eine reine Textdoku für einen UI-Workflow zwingt jeden Leser, Worte in Klicks zu übersetzen. Sie werden scheitern.
Kein Verantwortlicher. „Das Ops-Team besitzt das" heißt, niemand besitzt es. Wähl einen Namen.
Kein Review-Zyklus. Dokus verfallen in dem Moment, in dem ein Tool sich ändert. Ohne Zyklus erfährst du es vom Leser, der versucht hat, der Doku zu folgen, und hängenblieb.
Nach dem Launch nie aktualisiert. Das häufigste Muster. Die Doku wird für ein Audit geschrieben, landet in einem Wiki und bewegt sich nie wieder. Sechs Monate später passt sie nicht mehr zur Realität.
An der falschen Stelle vergraben. Ein perfektes Runbook, das niemand findet, ist dasselbe wie kein Runbook. Wenn deine Suche schlecht ist, fix die Suche, bevor du mehr Dokus schreibst.
Von der falschen Person geschrieben. Prozessdokus, die komplett von Managern geschrieben werden, die den Prozess nicht selbst ausführen, übersehen die kleinen Schritte, auf die es ankommt. Der SME muss in der Schleife sein.
Format und Tiefe richtig wählen
Nutze diese Matrix, um ein Format zu wählen. Die zwei Achsen sind Prozesskomplexität und wie häufig der Prozess läuft.
| Niedrige Komplexität | Hohe Komplexität | |
|---|---|---|
| Hohe Häufigkeit | Kurze SOP oder Arbeitsanweisung | Detaillierte SOP mit Screenshots und Video-Walkthrough |
| Niedrige Häufigkeit | Knowledge-Base-Artikel | Runbook mit Entscheidungsbaum und benannten Verantwortlichen |
Ein paar Faustregeln, die über der Matrix liegen.
- Eine Zielgruppe, die die Aufgabe täglich macht, kommt mit einer knapperen Doku zurecht. Sie braucht nicht jeden Screenshot.
- Eine Zielgruppe, die die Aufgabe einmal im Jahr macht, braucht die tiefste Doku. Behandle sie, als hätte sie den Prozess noch nie gesehen.
- Eine Zielgruppe unter regulatorischem Druck braucht die meiste Versionskontrolle und die meisten Review-Nachweise, unabhängig von der Häufigkeit.
- Funktionsübergreifende Prozesse brauchen oben eine Prozesslandkarte, auch wenn jeder Teilschritt seine eigene SOP darunter hat.
Im Zweifel: Schreib die kleinste nützliche Doku, ship sie und lass den ersten Leser dir sagen, was fehlt.
Häufig gestellte Fragen
Was ist der Unterschied zwischen Prozessdokumentation und einer SOP?
Prozessdokumentation ist der Oberbegriff für jedes Artefakt, das erklärt, wie Arbeit erledigt wird — Prozesslandkarten, SOPs, Runbooks, Entscheidungsbäume, Arbeitsanweisungen, Knowledge-Base-Artikel. Eine SOP ist ein bestimmter Typ Prozessdokumentation: eine Schritt-für-Schritt-Anleitung für eine einzelne, wiederholbare Aufgabe. Jede SOP ist Prozessdokumentation, aber nicht jede Prozessdokumentation ist eine SOP. Wähl das Format, das zur Arbeit passt, nicht umgekehrt.
Wie lang sollte Prozessdokumentation sein?
Lang genug, um reproduzierbar zu sein, kurz genug, dass Leute sie tatsächlich lesen. Für eine Aufgabe mit hoher Häufigkeit und Senior-Zielgruppe heißt das oft ein bis drei Seiten. Für eine seltene Aufgabe mit einem brandneuen Mitarbeiter kann sie zehn Seiten mit Screenshots umfassen. Die falsche Frage ist „wie lang sollte sie sein". Die richtige Frage ist: „Kann ein qualifizierter Leser dem folgen und die Aufgabe ohne Hilfe abschließen?" Wenn ja, ist sie genau richtig lang.
Wer sollte Prozessdokumentation schreiben?
Der Subject Matter Expert (SME) und ein Schreibender, gemeinsam. Der SME kennt die Arbeit. Der Schreibende weiß, wie man sie lesbar, strukturiert und überfliegbar macht. Wenn du nur eine Person hast, sollte das der SME sein — aber er sollte trotzdem einen Kollegen bitten, der Doku kalt zu folgen, bevor er veröffentlicht. Die Aufmerksamkeit eines Reviewers fängt die Schritte ein, die der SME als selbstverständlich behandelt.
Wie oft sollte Prozessdokumentation aktualisiert werden?
Lege einen Review-Zyklus danach fest, wie schnell sich das zugrunde liegende Tool oder der Workflow ändert. Stabile, regulierte Prozesse können vierteljährlich reviewt werden. Schnelllebige Produkt- oder Engineering-Prozesse brauchen einen monatlichen Zyklus. Zusätzlich zum Zeitplan sollte jeder Leser einen veralteten Schritt mit einem Klick markieren können — die meisten Updates kommen von Lesern, nicht von Auditoren. Der Verantwortliche muss die Schleife für jede Markierung schließen.
Welches Format ist am besten für Prozessdokumentation?
Es gibt nicht das eine beste Format. Passe das Artefakt an die Zielgruppe und die Arbeit an. Ein hochstufiger teamübergreifender Workflow ist eine Prozesslandkarte. Ein wiederholbarer Einzelaufgaben-Workflow ist eine SOP. Ein Systembetrieb ist ein Runbook. Eine verzweigende Entscheidung ist ein Entscheidungsbaum. Die meisten reifen Teams nutzen einen Mix — eine Prozesslandkarte oben, SOPs darunter, Runbooks für Systeme und Knowledge-Base-Artikel für Self-Service.
Wie halte ich Dokumentation aktuell?
Drei Gewohnheiten. Erstens: Gib jeder Doku einen benannten Verantwortlichen — eine Person, kein Team. Zweitens: Plane einen Review-Zyklus im Kalender (vierteljährlich ist die Untergrenze). Drittens: Mach es trivial für Leser, einen veralteten Schritt zu markieren. Die Kombination aus Verantwortlichem, Zyklus und Feedback-Schleife fängt etwa 90 Prozent des Verfalls ab, bevor er zum Problem wird.
Welche Tools brauche ich, um anzufangen?
Zum Start brauchst du nur eine Schreiboberfläche (ein Wiki, ein Google Doc oder eine Markdown-Datei) und ein Screenshot-Tool. Wenn deine Bibliothek wächst, willst du ein Wiki mit Versionshistorie, ein Screenshot- und Aufnahmetool, das Annotation an einem Ort handhabt, und ein Review-Erinnerungssystem. Unsere Übersicht der Prozessdokumentations-Tools vergleicht die dedizierten Apps, falls du von den Basics upgraden willst.
Zum Abschluss
Prozessdokumentation ist kein einmaliges Projekt. Es ist eine fortlaufende Praxis — erfassen, strukturieren, visualisieren, reviewen, wiederholen. Die Teams, die das gut machen, behandeln Dokumentation als Teil der Arbeit, nicht als Steuer obendrauf. Sie starten klein, picken die wirkungsstärksten Prozesse zuerst, geben jeder Doku einen benannten Verantwortlichen und verlassen sich auf Screenshots und Aufnahmen, um die schwere Arbeit zu erledigen, die Worte nicht können.
Wenn du einen schnelleren Weg willst, die Visuals zu erfassen, zu annotieren und auszuliefern, die solche Dokus zünden, ist ScreenSnap Pro ein einmaliger Kauf für 29 $, der Bildschirmaufnahme, Screenshots und 15 Annotationswerkzeuge auf Mac und Windows abdeckt. Kein Abo, kein Wasserzeichen, Lizenz für zwei Computer. Es passt natürlich zu jedem Wiki oder Knowledge Base, die du bereits nutzt.
Brauchst du eine Startvorlage? Unser SOP-Vorlagen-Leitfaden hat sieben kostenlose Layouts, die du heute kopieren kannst.
Morgan
Indie DeveloperIndie developer, founder of ScreenSnap Pro. A decade of shipping consumer Mac apps and developer tools. Read full bio
@m_0_r_g_a_n_

