Prozessbeschreibung: Aufbau, Beispiel und Vorlage
Prozessbeschreibung erstellen: SIPOC, Rollen, Input und Output, Kennzahlen, Risiken, Freigabe und kopierbare Vorlage mit ausgefülltem Praxisbeispiel.
Auf dieser Seite +
- Was ist eine Prozessbeschreibung?
- Prozessbeschreibung, Verfahrensanweisung und Arbeitsanweisung
- Vorlage zum Kopieren
- Schritt für Schritt erstellen
- Ausgefülltes Beispiel: Kundenreklamation
- Rollen und Schnittstellen eindeutig machen
- Kennzahlen, Risiken und Kontrollen
- Wie gewinnt man Prozesswissen aus Gesprächen?
- Qualitätscheck vor Freigabe
- Fazit
Eine Prozessbeschreibung erklärt, wie ein definierter Input über mehrere Rollen und Schritte zu einem überprüfbaren Output wird. Sie benennt Start und Ende, Verantwortlichkeit, Übergaben, Entscheidungen, Risiken, Kontrollen und Kennzahlen. Eine gute Beschreibung ist End-to-End verständlich, ohne jeden Handgriff auszuformulieren.
Kurzantwort: Beginnen Sie mit SIPOC – Lieferanten, Inputs, Prozess, Outputs, Kunden. Zeichnen Sie danach fünf bis neun Hauptschritte, ordnen Sie jedem Schritt eine verantwortliche Rolle zu und ergänzen Sie Kriterien für Entscheidungen und Übergaben. Details verlinken Sie als Arbeitsanweisung.
Was ist eine Prozessbeschreibung?
Sie ist die kontrollierte Darstellung eines wiederholbaren betrieblichen Ablaufs. Ihr Zweck ist nicht, vorhandene Arbeit in Bürokratensprache zu übersetzen, sondern Erwartungen und Schnittstellen eindeutig zu machen.
| Element | Leitfrage |
|---|---|
| Zweck | Welchen Nutzen oder welches Ergebnis liefert der Prozess? |
| Start/Ende | Welches Ereignis startet, welches Ergebnis beendet ihn? |
| Input | Welche Informationen oder Materialien werden benötigt? |
| Output | Was wird in welcher Qualität geliefert? |
| Rollen | Wer führt aus, entscheidet, prüft und wird informiert? |
| Ablauf | Welche Hauptschritte und Entscheidungen gibt es? |
| Kontrolle | Wie werden Fehler verhindert oder erkannt? |
| Kennzahl | Woran erkennt man Wirksamkeit und Leistung? |
Die ISO beschreibt den Prozessansatz als zentrales Element von ISO 9001 und nennt Führung, risikobasiertes Denken, dokumentierte Information, Leistungsauswertung und Verbesserung als Kernthemen; siehe ISO 9001 explained. Das bedeutet nicht, dass jeder Prozess in derselben Textvorlage dokumentiert werden muss.
Prozessbeschreibung, Verfahrensanweisung und Arbeitsanweisung
| Ebene | Fokus | Beispiel |
|---|---|---|
| Prozesslandkarte | Zusammenspiel der Hauptprozesse | Vertrieb → Leistung → Abrechnung |
| Prozessbeschreibung | End-to-End-Ablauf und Schnittstellen | Kundenreklamation bearbeiten |
| Arbeitsanweisung | konkrete Tätigkeit | Rücksendung im ERP anlegen |
| Checkliste/Formular | Ausführung und Nachweis | Abschlussprüfung Reklamation |
Eine Arbeitsanweisung sollte nur dort entstehen, wo ein Schritt genauer geregelt werden muss. Doppelter Text in mehreren Dokumenten führt zu widersprüchlichen Versionen.
Vorlage zum Kopieren
Prozessname/ID: […]
Zweck: […]
Prozessverantwortung: […]
Start/Auslöser: […]
Ende/Output: […]
Geltungsbereich: […]
Lieferanten und Inputs: […]
Kunden und Anforderungen: […]
Beteiligte Rollen: […]
Hauptschritte: 1. […] 2. […] 3. […]
Entscheidungen/Ausnahmen: […]
Risiken und Kontrollen: […]
Kennzahlen: […]
Dokumente/Systeme/Nachweise: […]
Version/Freigabe/Review: […]
Schritt für Schritt erstellen
- Scope festlegen. Ein klarer Start und ein klarer Output verhindern Endlosprozesse.
- SIPOC erfassen. Lieferanten, Inputs, Hauptprozess, Outputs und Kunden auf einer Seite.
- Ist-Ablauf beobachten. Mit den ausführenden Rollen sprechen und reale Fälle verfolgen.
- Hauptschritte ordnen. Fünf bis neun Schritte reichen für die Prozessebene meist aus.
- Rollen zuweisen. Pro Ergebnis eine eindeutige Verantwortung festlegen.
- Entscheidungen definieren. Kriterien statt vager Formulierungen wie „bei Bedarf“.
- Risiken und Kontrollen ergänzen. Wo kann der Prozess scheitern, wie wird es erkannt?
- Kennzahlen wählen. Wenige Maße für Qualität, Zeit und Ergebnis.
- Praxistest durchführen. Einen realen Fall gegen die Beschreibung laufen lassen.
- Freigeben und verbessern. Eigentümer, Version und Review festlegen.
Ausgefülltes Beispiel: Kundenreklamation
| Feld | Beispiel |
|---|---|
| Zweck | berechtigte Reklamationen schnell lösen und Ursachen beseitigen |
| Start | Reklamation geht über Supportkanal ein |
| Ende | Kunde informiert, Maßnahme abgeschlossen, Ursache bewertet |
| Input | Kundendaten, Produkt, Kaufnachweis, Fehlerbeschreibung |
| Output | dokumentierte Entscheidung und Lösung |
| Verantwortung | Customer Operations Lead |
| Rollen | Support, Qualität, Logistik, Finance |
| Kennzahlen | Erstreaktionszeit, Durchlaufzeit, Wiederholfehlerquote |
| Hauptrisiko | falsche Zuordnung oder Verlust an Schnittstelle |
| Kontrolle | Ticket-ID, Pflichtfelder, Abschlussreview |
Hauptablauf: Eingang bestätigen → Vollständigkeit prüfen → Zuständigkeit und Priorität festlegen → technisch/kaufmännisch bewerten → Lösung freigeben → ausführen → Kunde informieren → Ursache und Wiederholungsmaßnahme dokumentieren.
Beachten Sie die Abgrenzung: „Support legt Rücksendung an“ ist Prozessschritt. Die genaue Klickfolge im System gehört in eine verlinkte Arbeitsanweisung.
Rollen und Schnittstellen eindeutig machen
RACI kann helfen:
- R – Responsible: führt die Arbeit aus.
- A – Accountable: trägt die Ergebnisverantwortung und entscheidet.
- C – Consulted: wird vor Entscheidung einbezogen.
- I – Informed: erhält Information über Ergebnis oder Status.
Pro Ergebnis sollte möglichst nur eine Rolle „A“ tragen. Mehrere Gesamtverantwortliche bedeuten in der Praxis oft keine klare Verantwortung. Beschreiben Sie Übergaben mit Eingangskriterium: „Qualität übernimmt, sobald Fotos, Seriennummer und Fehlerbeschreibung vollständig sind.“
Kennzahlen, Risiken und Kontrollen
| Perspektive | Kennzahl | Typischer Fehler |
|---|---|---|
| Zeit | Durchlaufzeit | nur Durchschnitt, Ausreißer unsichtbar |
| Qualität | First-pass yield / Nacharbeitsquote | Menge statt Ergebnis messen |
| Kunde | Termintreue oder Zufriedenheit | ohne Segmentierung interpretieren |
| Risiko | offene kritische Fälle | keine Eskalationsfrist |
| Prozess | Übergaben ohne Rückfrage | Rückfragen nicht kategorisieren |
Eine Kennzahl braucht Definition, Datenquelle, Rhythmus, Ziel und verantwortliche Rolle. Messen Sie nicht alles, sondern die Stellen, an denen eine Entscheidung oder Verbesserung möglich ist.
Wie gewinnt man Prozesswissen aus Gesprächen?
Workshops und Job-Shadowing zeigen oft informelle Schritte, die in alten Dokumenten fehlen. Zeichnen Sie solche Gespräche nur transparent und mit Zustimmung auf. Ein KI-Meeting-Protokoll kann Entscheidungen, offene Fragen und Aufgaben strukturieren; die Prozessverantwortung muss das Modell anschließend fachlich freigeben.
Kuno ist ein privatsphärenorientierter physischer KI-Sprachrekorder, made in Germany. Er erfasst Audio auf dem Gerät; Verarbeitung und Speicherung erfolgen gemäß bestehender Produktbeschreibung EU-gehostet. Hardware und KI-Funktionen werden mit monatlichem oder jährlichem Plan angeboten. Das Gerät kann Erfahrungswissen erfassen, ersetzt aber keine Prozessanalyse oder Freigabe.
Prozesswissen im Workshop erfassen: Kuno ansehen.
Qualitätscheck vor Freigabe
- Start und Ende eindeutig
- Input, Output und Kundenanforderung definiert
- eine klare Prozessverantwortung
- Rollen und Übergabekriterien sichtbar
- Entscheidungen mit Kriterien statt „bei Bedarf“
- Risiken und Kontrollen verknüpft
- wenige, definierte Kennzahlen
- Detailanweisungen verlinkt statt dupliziert
- Version und Review-Termin vorhanden
Fazit
Eine Prozessbeschreibung macht Arbeit über Rollen und Systeme hinweg steuerbar. Sie bleibt auf der Ebene von Ergebnis, Verantwortung und Übergabe; die konkrete Ausführung liegt in Arbeitsanweisungen. So bleibt die Dokumentation verständlich und wartbar.
Vom Prozessgespräch zum strukturierten Entwurf: Kuno mit monatlichem oder jährlichem KI-Plan entdecken.