Prozessorientierung und Prozessoptimierung

Nichts ist unmöglich – Toyota

Wenn wir von Prozessoptimierung sprechen, fällt uns sofort Toyota ein. Gleichzeitig mit Toyota fallen uns viele agile Denkweisen und Methoden ein, die wir auf Toyota zurückführen können (z.B: Kanban).

Eine kurze Geschichte, die ich selbst erlebt habe

Eine umfangreiche Softwaremigration sollte durch eine externe Firma umgesetzt werden. Nach Tagen der Annäherung, Gesprächen, Wissensaustausch und so weiter sollte nun mal der „Sack zu gemacht werden“ und es ging um den Preis: Was kostet das Ganze? Das war so schlicht und ergreifend nicht zu beantworten, da wir uns im komplexen Raum (#cynefin) bewegen und iterativ handeln müssen. Da kam dann die Aussage: Ja warum denn nicht? Toyota arbeitet doch auch agil und verkauft Autos schließlich zum Festpreis.

Das Umfeld ist entscheidend

Was hat das obige Beispiel nun mit Prozessen zu tun? Es ist der Versuch, Vergleichbarkeit herzustellen. Die Herausforderung, die hier angesprochen wird, liegt in der Schwierigkeit, einen festen Preis für ein komplexes Projekt zu bestimmen, das agile Methoden erfordert. Dabei wird allerdings übersehen, dass es sich um grundlegend unterschiedliche Prozesse handelt. Die Fertigung von Autos bei Toyota ist zwar flexibel und effizient, basiert jedoch auf wiederholbaren, standardisierten Prozessen mit vorhersehbaren Ergebnissen. Die Kosten können durch Skaleneffekte und Optimierung der Produktionsprozesse relativ genau kalkuliert werden.

Softwaremigration, insbesondere bei umfangreichen Projekten, ist hingegen ein hochkomplexer Prozess, der maßgeschneiderte Lösungen und häufige Anpassungen erfordert. Agile Methoden kommen hier zum Einsatz, um Flexibilität im Umgang mit unvorhergesehenen Herausforderungen zu ermöglichen. Die Kostenkalkulation für solche Projekte ist daher wesentlich schwieriger, da Umfang und Anforderungen sich im Laufe des Projekts ändern können.

Der Versuch, Vergleichbarkeit zwischen der agilen Softwareentwicklung und Toyotas Produktionsmethoden herzustellen, hinkt also. Es wird eine Äquivalenz suggeriert, die in der Realität so nicht besteht. Agile Methoden in der Softwareentwicklung zielen darauf ab, Flexibilität und Anpassungsfähigkeit zu maximieren, was eine Festpreiskalkulation erschwert.

Nicht komplexes Umfeld

In der wiederkehrenden Arbeitsweise, in der sich Arbeitsschritte wiederholen und dort, wo die Prozesse als eine Art Kochbuch oder How To Guide funktionieren, um komplizierte Arbeitsweisen zu beschreiben mag das sinnvoll sein. Die Frage ist jedoch, wenn ich weiß, wie es zu machen ist, muss ich es dann auch noch in eine Prozessbeschreibung gießen? Oder verdränge ich dadurch nicht eher die Bereitschaft zur Veränderung, sollte es neue Erkenntnisse geben? Warum also Prozesse? Häufig sind die Prozessbeschreibungen ja nur der erste Schritt. Kennt man den Ablauf, kann man ihn im nächsten Schritt optimieren. Aber wenn wir uns nur auf standardisierte Arbeit konzentrieren, bleibt als Optimierung häufig nur die Geschwindigkeit – eine Reduzierung der Kosten.

Was dabei aus den Augen verloren geht ist die Frage, ob es dadurch auch besser gemacht wird. Wenn wir Dinge besser machen wollen, also Wert erhöhen wollen, müssen wir die Dinge anders machen und damit müssen wir den Prozess ändern. Jetzt kommen wir in die empirische Prozesssteuerung und damit betreten wir wieder das komplexe Umfeld.

Prozesse machen uns blind für Veränderung, sofern wir sie nicht hinterfragen

Komplexes Umfeld

Im komplexen Umfeld hinterfragen wir uns und unsere Arbeit zyklisch. Dort wo wiederkehrende Arbeiten anfallen, verlassen wir das komplexe Umfeld, da wir in die Vorhersagbarkeit kommen. Deshalb ist Automatisierung beim Build oder Release auch nicht komplex, sofern es einmal aufgesetzt ist.

Wenn wir agil arbeiten und uns im komplexen Raum befinden, sind wir bestrebt, kontinuierlich besser zu werden und dabei (notwendige) Wiederholung aus dem komplexen Raum zu eliminieren, denn Wiederholung ist ggf. kompliziert, aber nicht komplex. Der kontinuierliche Verbesserungsprozess (#kvp) ist ein guter Ansatz, da keine konkreten Arbeitsabläufe beschrieben sind, sondern zyklisch überprüft wird, ob und wie Verbesserung stattfinden kann. Davon betroffen sind dann auch Ablaufprozesse.

Im kontinuierlichen Verbesserungsprozess lassen sich auch feste Ablaufprozesse überprüfen

Auch Scrum ist kein Prozess, sondern ein Rahmenwerk. Dieses Rahmenwerk ist hilfreich bei der Förderung empirischer Prozesssteuerung (#inspectandadapt).

Es gibt in jeder Organisation und jedem Umfeld Prozesse

Fest steht aber, es werden uns immer Prozesse begegnen, auch im komplexen Umfeld und in jeder Organisationsform. Es gibt sogar die prozessorientierte Organisation, wo z.B. die Methodiken von Scrum oder Kanban Verwendung finden.

Agile Prinzipien können zwar in jedem Umfeld und auf jede Organisationsform angewendet werden, aber die Art ihrer Anwendung und die damit verbundenen Herausforderungen variieren erheblich – wie das obige Beispiel mit Toyota zeigt.

Für die Prozesse, die sich daraus ableiten bedeutet es, dass im komplexen Umfeld eher die empirische Prozesssteuerung, im komplizierten Umfeld eher die Ablaufsteuerung beschrieben wird. In der Ablaufsteuerung werden somit durch den Prozess Tätigkeitsmandate ausgestellt, die durchaus aus Sicht anderer Bereiche als paradox empfunden werden können.