Suche
  • Bernd Krehoff

Agilität und Prozessmanagement - eine unbequeme Verwandtschaft


Prozessmanagement und Agilität sind keine einfache Beziehung. Erst kürzlich erlebte ich in einer Schulung über Business Process Management (BPM) wie Agilität zwar erwähnt wurde, jedoch in einem Extrakapitel mit wenig Bezug zum restlichen Lernstoff. Und so ist es häufig: Agile Ansätze werden bisweilen immer noch als alternative Methoden dargestellt, die außerhalb der geregelten Welten von Mangementsystemen und ISO-Normen zur Anwendung kommen, wenn halt mal etwas anderes ausprobiert werden soll.


Das agile Manifest von 2001 hat seinen Beitrag zu dieser merkwürdigen Beziehung geliefert. Im ersten Glaubenssatz des Manifests heißt es:


„Individuals and interactions over processes and tools.“


Warum führt das agile Manifest gleich an erster Stelle die Relativierung von Prozessen durch? Und warum stellt es Prozesse (und Werkzeuge) in einen Kontrapunkt zu Individuen und Interaktionen?


Schauen wir uns die Ansprüche von Prozessmanagement etwas genauer an, entdecken wir mehr als eine Gemeinsamkeit zwischen Agilität und Prozessmanagement:


1) Das Denken vom Kunden zum Kunden


Nicht die Abteilungen mit ihren funktionalen Schwerpunkten wie Marketing, Entwicklung oder Vertrieb stehen in der prozessorientierten Organisation im Mittelpunkt, sondern die Kunden und ihre Bedürfnisse. Geschäftsprozesse bilden ab, wie die einzelnen Funktionen im Unternehmen über ihre Abteilungsgrenzen hinweg zusammen arbeiten sollen, um den Kunden zufrieden zu stellen.


Dieser End-to-End-Ansatz findet sich auch im agilen Gedankengut. Als im Jahr 1986 in einem Beitrag von Hirotaka Takeuchi und Ikujiro Nonaka zum ersten Mal das Wort „Scrum“ im Zusammenhang mit Produktentwicklung fiel, stand eben dieser End-to-End-Ansatz im Mittelpunkt: „Scrum“ (englisch für „Gedränge“) wurde als Alternative zum phasenweisen Vorgehen gesehen, in dem Design, Entwicklung und alle weiteren Aktivitäten nacheinander und sauber getrennt stattfinden (gleichsam eines Staffellaufs).




Das Scrum-Team ist somit ein bewusst gewähltes Gedränge, in dem alle relevanten Funktionen zeitgleich zusammenarbeiten, um in kurzen Abständen Mehrwert an die Kunden liefern zu können.


2) Die Relativierung der funktionalen Organisation


Organisationen sind häufig stark funktional ausgerichtet. Soll heißen: Die Entscheidungsmacht ist in den Teams und Abteilungen konzentriert. Geht es dann um die Zusammenarbeit zwischen den Abteilungen - zum Beispiel zwischen Produktmanagement und Entwicklung -, müssen beide Abteilungen darüber verhandeln, welche Ressourcen sie in welchem Ausmaß zur Verfügung stellen.


Organisationen, die prozessorientiert arbeiten wollen, müssen den Prozessverantwortlichen genügend Autorität verschaffen, um Aktivitäten und Ziele abteilungsübergreifend ausrichten zu können. So wird zum Beispiel der Innovationsprozess eines Unternehmens nur dann erfolgreich sein, wenn Marketing, Entwicklung und Industrialisierung am gleichen Strang ziehen.


Agile Teams sind ebenfalls eine Herausforderung für die funktionale Organisation: Ob Product Owner, Entwickler oder Validierungsingenieur - wer in einem Scrum-Team mitmacht, gehört im Normalfall fest und dauerhaft dazu. Dadurch wird das agile Team zur eigentlichen Heimat dieser Mitarbeiter, während ihre fachliche Teamzugehörigkeit (z.B. zum Produktmanagement oder zur Entwicklungsabteilung) in der Hintergrund rückt.


3) Die Orientierung an Eingangs- und Ausgangsgrößen


Weil Geschäftsprozesse mit dem Kunden anfangen und auch aufhören, ist die Orientierung an den Eingangs- und Ausgangsgrößen (Inputs und Outputs) so wichtig. So muss zum Beispiel ein Innovationsprozess seine Leistungsfähigkeit beweisen, in dem er am Anfang die Bedürfnisse der Kunden richtig versteht und am Ende die Produkte oder Dienstleistungen liefert, die die Kundenbedürfnisse befriedigen.


Agilität denkt wiederum in Mini-Schleifen oder Iterationen, die mit dem Verstehen der Nutzer (z.B. in Form von User Stories) anfängt und mit der Abnahme fertiger Produktinkremente durch diese Nutzer (z.B. in einem Review Meeting) aufhört.


4) Die kontinuierliche Beobachtung und Verbesserung


Unvergesslich bleibt die Szene aus dem Film „The Founder“, in der Michael Keaton in der Rolle des Geschäftsmanns Ray Kroc 1954 zum ersten Mal die Küche im kalifornischen Schnellimbiss der Gebrüder Mac und Dick McDonald betritt - und nicht schlecht staunt. Jede einzelne Station in dieser Küche, jede Bewegung der Mitarbeiter sind bis zum letzten Detail perfektioniert, um die Arbeitsabläufe in der Küche möglichst effizient zu gestalten.


Prozessmenschen lieben es eben, Abläufe zu messen, Schwachstellen zu identifizieren und Dinge zu verbessern.


In agilen Ansätzen wie Scrum haben wir mit der Retrospektive wiederum ein fest eingebautes Ritual, um mit jedem Iterationszyklus immer wieder zu reflektieren, was gut gelaufen ist und was verbessert werden kann. Durch diesen wiederholenden Ansatz ist Scrum im kontinuierlichen Beobachten und Verbessern deutlich stärker unterwegs als zum Beispiel das klassische Projektmanagement, wo “Lessons Learned“ oder „Post Mortems“ mit Abschluss des Projektes nachgereicht werden (wenn die Kollegen meist schon im nächsten Projekt verplant sind).


5) Die Beschreibung von Aktivitäten und ihrer Verknüpfung


Hier liegt möglicherweise die wahre Differenz zwischen Agilität und Prozessmanagement begraben. Denke ich an Prozesse, dann denke ich immer noch an den Anspruch, die Verknüpfung von Tätigkeiten möglichst exakt und stabil zu erfassen und zu beschreiben. So wie bei der Herstellung eines Big Macs bei McDonald‘s nichts dem Zufall überlassen wird, so kann ein gut beschriebener Prozess dazu führen, dass die gewünschten Ergebnisse regelmäßig und zuverlässig in der gewünschten Qualität geliefert werden.


Agile Ansätze wie Scrum oder auch Kanban lassen sich dagegen als Prozessmodelle 2. Ordnung begreifen. Zwar gibt es auch bei Scrum Vorschriften - es gibt Meetings, Rollen und Artefakte, die zu berücksichtigen sind. Insgesamt stellen Scrum oder Kanban einen sehr offenen, weitgehend nichtdeterminierten Rahmen zur Verfügung, in dem Teams in iterativen Schleifen ihr Vorgehen immer wieder aufs Neue planen, beobachten und anpassen (siehe mein Beitrag zu Prozessmanagement und Scrum).


Agile Ansätze sind also Prozessmodelle 2. Ordnung, weil sie selber kaum Vorgaben machen, sondern das Rahmenwerk liefern, innerhalb dessen das Vorgehen überhaupt erst festgelegt wird.


Fazit


Prozessmanagement und Agilität verfolgen in weiten Teilen ähnliche Ziele, wenn es um Kundenorientierung, übergreifende Zusammenarbeit und kontinuierliche Verbesserung geht. Die Ähnlichkeiten sind so frappierend, dass sich auch ohne DNA-Test von Verwandtschaft sprechen lässt.


Allerdings ist diese Verwandtschaft keine einfache: Während Prozessmanagement dazu benutzt werden kann, um Abläufe sicher und wiederholbar zu steuern, wollen agile Methoden einen Rahmen bieten, in dem die richtigen Entscheidungen überhaupt erst getroffen werden. Deshalb legt das agile Manifest auch so viel wert auf Individuen und Interaktionen.


-> Hat Ihnen dieser Beitrag gefallen?

-> Haben Sie weitere Gedanken dazu?


Dann können Sie gerne ein Kommentar hinterlassen oder meinen Blog über das Formular unten abonnieren. Sie werden dann über neue Beiträge per E-Mail informiert.


-> So oder so - schön, dass Sie hier sind!


Foto von June von Pexels

22 Ansichten

©2020 Prozesshacker.de. Erstellt mit Wix.com