Prozesse werden meist nur über Dienstanweisungen etc. definiert.
Man kann aber auch zusätzlich Prozeßdiagramme erstellen. Lohnt sich das? Definitiv ist es mühevoll und kostet viel Zeit. Und die Prozesse ändern sich – da muß man dann die Prozeßdiagramme auch ständig nacharbeiten. Manchmal sind solche Diagramme die Voraussetzung für Födermittel – da muß man gar nicht über die Sinnhaftigkeit diskutieren. Tatsächlich helfen solche Diagramme aber auch den diversen beteiligten Teams zu erkennen, das Gesamtbild zu erfassen. Das führt manchmal schon für sich zu Optimierungen („Was, ihr habt diesen Report nie ausgewertet, den wir monatlich erstellen?“, „Heißt das, daß die Auszahlung am Ende von 5 Personen geprüft und freigegeben wird?“) Prozeßberatern helfen sie auch, um noch weitergehende Optimierungen und Technikeinsatz zu planen.
Meist werden Prozeßdiagramme mit der graphischen Beschreibungssprache BPMN erstellt. Sie ist hoch präzis. Ab einem gewissen Detaillierungsniveau kann man die Diagramme dann sogar als Workflow ablaufen lassen. (Zumindest setzen viele Workflow-Systeme auf BPMN-Notationen ihrer Workflow-Prozesse.)
Die Krux ist: Oft verbringt man mit den Fachabteilungsmitarbeitern fast so viel Zeit mit der Erklärung von BPMN, wie mit der Aufklärung der Prozeß-Details. BPMN ist einfach nicht intuitiv lesbar. Daher sollte man durchaus auch die Ereignisgesteuerten Prozeßketten (EPK) in Erwägung ziehen. Erfahrungsgemäß versteht die jeder sofort. Und die feinen Details kann man in Texten dazuschreiben.
Wenn man dann tatsächlich einmal ein Workflow-System einsetzt, kann man die EPK-Diagramme immer noch in BPMN umschreiben. Für richtige Workflows muß man ohnehin noch mehrmals an die Fachabteilung herantreten, weil es dann noch viele viele Details zu klären gibt.