Warum Prozessmodellierung iterativ erfolgen soll

Im Prozessmanagement gibt es so viele Begriffe. Die sollten eigentlich eindeutig sein. Nehmen wir als Beispiel den Begriff „Soll-Prozess“. Einfaches Wort, versteht doch jeder. Oder? Eben nicht! Denn kaum ein Begriff wird so widersprüchlich verwendet. In der Praxis gibt es zwei Bedeutungen, für die das Wort „Soll-Prozess“ verwendet wird. Und weil diese Bedeutungen im direkten Gegensatz zueinander stehen, ist Verwirrung garantiert. Hier lesen Sie, warum Prozessmodellierung besser iterativ erfolgen sollte.

Erste Variante: Soll-Prozess als verbindliche Vorgabe für die Gegenwart

Wenn Prozessverantwortliche für alle Beteiligten ein verbindliches Vorgehen festlegen, dann ist das ein Soll-Prozess. „So sollen sich alle verhalten.“ Das ist eine Vorgabe.

Der „Ist-Prozess“ weicht allerdings häufig davon ab. In der Praxis arbeiten nicht alle Beteiligten so, wie es vorgegeben ist. Das kann verschiedene Gründe haben, vom fehlenden Verstehen bis zu notwendigen Abweichungen, weil man einen besonderen Fall bearbeitet, der im Soll-Prozess nicht vorgegeben war.

Wenn wir den „Soll-Prozess“ als Vorgabe verstehen, dann wird die Beobachtung einer Abweichung zur zentralen Aufgabe von Führung im Prozess. Wir beobachten Abweichungen und entscheiden, wie wir sie bewerten:

• Wo wird abgewichen, weil der Prozess nicht alle Fälle abdeckt?
• Wo wird anders gehandelt, weil Bearbeiter den Soll-Prozess nicht kennen oder nicht können?
• Wo sollte der Soll-Prozess an eine bessere gelebte Praxis angepasst werden

Zweite Variante: Soll-Prozess als Vision für die Zukunft

Sehr häufig wird der „Soll-Prozess“ aber anders verstanden. Wenn der heute gelebte und verbindliche Prozess als „Ist-Prozess“ bezeichnet wird (das, was ich gerade oben, unter I., als „Soll-Prozess“ bezeichnet habe), dann ist das „Soll“ eine Vorstellung über eine Zukunft, nachdem geplante Veränderungsprojekte abgeschlossen sind. Dieses Verständnis wird häufig propagiert, so zum Beispiel auch im „Modell Aachen„.

Es  bringt aber aus meiner Sicht zwei Probleme mit sich:

Der „Ist-Prozess“ ist eine Illusion

Der „Ist-Prozess“ wird als gegeben angenommen. Dabei ist es häufig eine Illusion, zu glauben, dass heute bereits ein einheitlicher und beobachteter Prozess stattfindet. Meistens ist das, was man dann als „Ist-Prozess“ bezeichnet, eine Wunschvorstellung. Die Realität weicht zum Teil erheblich ab, aber das verliert man aus dem Auge, denn man hat ja einen „Ist-Prozess“.

Der „Soll-Prozess“ schiebt Konflikte auf die lange Bank

Der „Soll-Prozess“ im Sinne „Zukunft“ ist sehr häufig eine Aneinanderreihung von Wünsch-dir-Was. Und so wird der „Soll-Prozess“ auch meistens verstanden. Gerne auch mit dem Attribut „Idealvorstellung“ versehen. Da schwingt dann die Erwartung mit, dass man das „Ideal“ ja sowieso nie erreichen wird. So kommt es auch, dass ein für die Zukunft vereinbarter „Soll-Prozess“ schnell breite Zustimmung erfährt, weil jeder erwartet, dass man „Details“ ja im Laufe der Zeit noch nachbessern kann. Der „Soll-Prozess“ ist dann nicht mehr als ein fauler Kompromiss, der den wirklichen Konflikt zwischen den Interessen auf die lange Bank schiebt.

Differenzierte Unterscheidung in Prozess-Stadien

Weil die Begrifflichkeiten so missverständlich sind, empfehle ich, die Begriffe „Ist-Prozess“ und „Soll-Prozess“ zu vermeiden. In der prozessgesteuerten Digitalisierung arbeiten wir iterativ, also in Schleifen. Darum sollte auch Prozessmodellierung iterativ erfolgen.

Positiver Nebeneffekt: Heutzutage gibt es sowieso kaum noch Prozessoptimierungen, die ohne Software-Anpassungen auskommen. Darum ist es gut, die Begrifflichkeit im Prozessmanagement mit dem Release-Zyklus der Softwareentwicklung zu harmonisieren.

Lösung: Prozesse iterativ entwickeln

Wenn Prozessmodellierung iterativ erfolgen soll, sehe ich folgende neue Konstrukte. Beginnen wir mit den Endpunkten der Prozess-Entwicklung:

• Der aktuell gültige verbindliche Prozess ist der Startpunkt:
  Das ist das Konstrukt, das wir oben einmal als „Soll-Prozess“ und einmal als „Ist-Prozess“ bezeichnet haben. Hier legen wir fest, was unter den heute gültigen Bedingungen (Software, Aufbauorganisation, Kundenverträge, Datenqualität etc.) als Vorgabe für die Zusammenarbeit gelten soll.
  Wer erledigt wann welche Aufgabe, welche Anwendungen sollen die Beteiligten verwenden, welche Dokumente bearbeiten etc.
  Hier nehmen wir es unter Umständen in Kauf, dass es viele Abweichungen und Ausnahmen zum Prozess gibt, weil wir den Prozess nicht vollständig vereinheitlicht haben (und vielleicht auch gar nicht vereinheitlichen wollen). Am besten werden die bekannten Abweichungen in der Vorgabe gleich benannt. Das schränkt gewissermaßen den Geltungsbereich des vereinbarten Prozesses ein.
• Der Zielprozess ist der Endpunkt:
  Das entspricht am ehesten dem, was wir oben in der zweiten Bedeutung von „Soll-Prozess“ beschrieben haben. Allerdings gehen wir nicht davon aus, dass wir die Zukunft schon bis ins Detail beschreiben können. Wir legen hier vielmehr die Eckpunkte fest, auf die wir mit Prozessverbesserungen hinarbeiten wollen. Die genaue Ausgestaltung wird sich im Laufe der Zeit zeigen.
  Der wichtige Unterschied ist also, dass der Zielprozess kein verbindliches „Pflichtenheft“ für Entwicklungen ist, sondern eine Beschreibung des Zielzustands.

Und nun erst folgen die verschiedenen Stadien und Konstrukte auf dem Weg vom aktuellen zum Zielprozess:

• Beschreibung der jeweils nächsten Prozess-Zustände auf dem Weg zwischen dem geltenden Prozess und dem Zielprozess

Es gibt einen vereinbarten Prozess, nachdem wir aktuell arbeiten (sollen). Aber wir arbeiten immer schon an einer nächsten Version des Prozesses. Das bedeutet „iterativ“.

1. 1. Der nächste Version des Prozess steht schon fest. Die Software-Entwickler arbeiten daran, daher wird auch von Prozess-Seite nichts mehr dran geändert, denn die „Techies“ brauchen Ruhe, um die vereinbarten Anpassung an Software und Medien für diese Version rechtzeitig und geprüft fertigzustellen. Auf Prozess-Seite können wir schon mit dem Training der Beteiligten beginnen, denn wir kennen das Datum und wir kennen den verbindlichen Ablauf der nächsten Prozessversion. Diese Prozessversion geht einher mit einem Software-Release. Das eine geht nicht ohne das andere.
   2. Die übernächste Version des Prozesses ist noch offen, denn die Arbeit daran beginnt erst, wenn die vorherige Version fertig ist. Wir können (und sollen!) noch darüber streiten, wie der übernächste Prozess aussehen sollte. Dafür haben wir so lange Zeit, bis der nächste Prozess (siehe a)) fertig ist. Dann sollten wir alle Details des übernächsten Prozesses festgezurrt haben.
   3. Weitere zukünftigen Versionen des Prozesses sind noch in der Diskussion. Bei der Release-Planung von Software-Veränderungen wird es eine Roadmap geben, welche Bereiche wann an der Reihe sind.
      Diese Planung muss man natürlich vom Prozess her denken und auf den Prozess zurückschreiben. Unter Umständen gibt es in der Planung eine oder mehrere abfolgende Versionen noch offener Prozesse.

Iterationen auf dem Weg zum Zielprozess

Mit jedem Release des Prozesses (und der Software) rücken alle Prozesskonstrukte um eine Position auf. Was bisher Modell a. war, wird zum jetzt gültigen verbindlichen Modell, b. wird verabschiedet und als verbindliche Vorgabe an die Software-Entwickler für die nächste Iteration als Version a. übergeben. Die bisherige Version c. wird als Version b. zum Arbeitsfeld der detaillierten Diskussion.

Dieses Spiel der Iterationen führen wir so lange fort, bis wir entscheiden, dass weitere Verbesserungen an Software und Prozess nicht mehr wirtschaftlich sind. Wenn wir uns von neuen Versionen nicht mehr Nutzen erwarten als wir an Kosten hineinstecken, dann kommt das Projekt zu einem (vorläufigen) Halt. Solange, bis Veränderungen der Umwelt wieder Anpassungen im Prozess notwendig machen –  dann geht das Spiel wieder los.

Für jedes Prozesskonstrukt ein eigenes Modell

Prozessmodellierung mit BPMN 2.0 bietet das optimale Format, um alle diese Konstrukte zu beschreiben. Je nachdem, wie konkret eine Prozessvorgabe ist, kann man dabei genauer oder gröber modellieren.

Die Zielvorstellung wird nur in einem groben Prozessmodell skizziert, die nächste zu entwickelnde Prozessversion (a.) erfordert ein fachlich und syntaktisch durch und durch korrektes Modell. Hier geht es um Eindeutigkeit.

Nachdem Sie hier lesen konnten, warum Prozessmodellierung iterativ erfolgen sollte, erfahren Sie in meinem nächsten Beitrag, welche Aufgaben Prozessverantwortliche in der prozessgesteuerten Digitalisierung übernehmen sollten.