Die Tyrannei der Notation: Warum BPMN und UML den Fachbereich ausgrenzen

Wenn grafische Syntax zur Barriere wird

Modellierungsstandards wie BPMN (Business Process Model and Notation) und UML (Unified Modeling Language) wurden geschaffen, um Prozesse und Systeme visuell zu kommunizieren. Sie sind zweifellos einfacher zu erlernen als Programmiersprachen wie Java oder C++. Dennoch erfordern sie die Fähigkeit und die Bereitschaft zu einem sehr formalen, syntaktischen Denken.

Das Problem ist: Auch wenn die Syntax grafisch ist – durch Kästchen, Linien und Pfeile anstelle von Buchstaben –, bleibt die logische Stringenz und die korrekte Anwendung der Regeln hochformal.

1. Die Abkopplung des Fachbereichs

Diese Formalität führt in der Praxis zu einer kritischen Verschiebung der Verantwortlichkeiten:

• Zuständigkeitswechsel: Häufig sind es IT-Mitarbeiter oder spezialisierte Architekten, die diese Modellierung durchführen, da sie dieses formale Denken gewohnt sind.

• Rollenreduktion: Der Fachbereich wird von der aktiven Methodik abgekoppelt. Er fungiert lediglich als Gesprächspartner und Informationslieferant für die IT-Mitarbeiter.

• IT-lastige Lösungen: Durch den wachsenden Einfluss der IT-Mitarbeiter bei der Modellierung steigt das Risiko, dass die entworfenen Lösungen zu stark aus der Perspektive der IT (technische Machbarkeit, Systemlogik) entworfen werden und die tatsächlichen Bedürfnisse und Nuancen des Fachbereichs vernachlässigt werden. Die Nutzerzentrierung geht verloren.

2. Der Ablenkungsfaktor: Diskussionen über Symbole

Ein zweites, häufig beobachtetes Phänomen ist die Verzettelung in Detaildiskussionen.

In vielen Modellierungs-Workshops geraten die Teilnehmer in langwierige Debatten über die korrekte Verwendung der Symbole, Stricharten und Pfeilsorten. Ob ein Event ein Start-Event oder ein Zwischen-Event sein muss, ob eine Linie gestrichelt oder durchgezogen ist – diese formalen Fragen lenken massiv vom eigentlichen Zweck der Übung ab: den Prozess zu verstehen und zu optimieren.

Diese „Tyrannei der Notation“ verbraucht nicht nur wertvolle Zeit, sondern schließt auch jene Mitarbeiter aus, die über das größte Prozesswissen verfügen, aber nur geringe oder gar keine Kenntnisse in der spezifischen Modellierungsmethodik besitzen. Ihre Kreativität und ihr Mitdenken werden durch die Angst vor formalen Fehlern unterdrückt.

Die Lösung: Das Modellieren im „Lockeren Modus“

Wir brauchen einen pragmatischeren Ansatz, um die Kraft der Visualisierung zu nutzen, ohne uns im Formalismus zu verlieren.

Die Lösung liegt darin, die Modellierungswerkzeuge in einem „lockeren Modus“ zu verwenden – eine Art Agile Modeling für Prozesse:

1. Fokus auf das Verständnis: Wir legen weniger Gewicht auf die strikte Einhaltung der syntaktischen Stringenz und mehr auf das gemeinsame Verständnis, die Kreativität und das Mitdenken aller Beteiligten.

2. Modell als Kommunikationswerkzeug: Das Diagramm dient primär als Kommunikationsbasis und nicht als Quellcode für eine Engine. Die Regeln werden nur soweit angewendet, wie sie das Verständnis fördern.

3. Prototyping statt Perfektion: Die frühen Modelle werden als schnelle Prototypen betrachtet, die Fehler enthalten dürfen und zum Wurf anregen sollen. Die formale Korrektheit wird erst in der Finalisierungsphase und nur für jene kritischen Prozesse nachgeschärft, die automatisiert werden sollen.

Indem wir die Hürde des formalen Denkens senken, gewinnen wir das Expertenwissen des Fachbereichs zurück und stellen sicher, dass die optimierten Prozesse wirklich die Geschäftsrealität widerspiegeln, anstatt nur eine technische Idealvorstellung der IT zu sein. Der Weg zur erfolgreichen Digitalisierung führt über inklusive Modellierung, nicht über formale Exklusivität.