Der Business Process Owner (BPO) ist prinzipiell natürlich keine Erfindung von mir. Auf Wikipedia kann man nachlesen, wie ein Prozesseigner oder Prozesseigentümer eigentlich traditionell definiert wird. Das entspricht eigentlich eher der Welt, aus der wir kamen. Und mit der die Organisation in der deutlich komplexeren, intergretierten Arbeitsweise zunehmend ein Problem hatte. Die Fülle und Diversität der vorhandenen Prozesslandschaft hatte dazu geführt, dass die seit langem existierenden Prozessmanager im Prinzip die Segel gestrichen und sich anderen Aufgaben zugewandt hatten. Also brauchten wir offensichtlich ein neues Prinzip, dass der digitalen Entwicklung und der Dynamik der sich verändernden Prozesse auch Rechnung trug.

Meine Grundidee ging von der Fragestellung aus, was es eigentlich an Lösungen zu entwickeln gab, und wie man diese in einem agilen Prinzip wie Scrum oder Kanban iterativ entwickeln können würde. Eckis Antwort darauf kam prompt, denn er hatte aus seiner Erfahrung heraus die ganz klare Sicht, dass es übergreifend in den inhaltlich unterschiedlichen operativen Bereichen (jedenfalls was die Produktsicht angeht) doch die gleichen „Schmerzthemen“ gab. Diese Themen sollten die Überschriften für unsere BPOs und die Anforderungen hier konsolidiert zusammen getragen werden. Analog zu der Verantwortung, die zum Beispiel vom Product Owner in der agilen Software-Entwicklung zu einem spezifischen „Produkt“ getragen wird, sollten unsere Process Owner diese Topthemen als ihr distinktives Fokusthema annehmen. Wir haben allerdings sehr bewusst darauf verzichtet, die Stellenbeschreibung zu diversifizieren, d.h. es gibt nur die eine Definition der Rolle BPO im Unternehmen.

Die Topthemen zu identifizieren war erstaunlich leicht. In einer Reihe von Interviews mit sehr unterschiedlichen Funktionsträgern der Organisation, kam es einheitlich zu eindeutigen Prioritäten in der Bewertung dessen, was der Operative das Leben schwer machte. Dabei wurde auch sofort klar, dass diese Themen nur im Zusammenhang bearbeitet werden können, d.h. das Team der BPOs würde eine eigene, integrierte Arbeitsweise entwickeln müssen. Unser Berater hat dabei sehr frühzeitig darauf hingewiesen, dass zwar für uns mit hoher Wahrscheinlichkeit keine „reine“ Methode wie z.B. Scrum in Frage käme, aber trotzdem bestimmte Elemente und Routinen gerade für den Einstieg große Bedeutung hätten. Nach dem Auftakt-Workshop wurde diese Annahme bestätigt, so gingen wir mit einer Arbeitsroutine in zweiwöchigen Sprints und mit der Zuordnung eines Scrum Masters (der nicht aus dem Team kam) an den Start. Beides erwies sich in den ersten Monaten als gute Entscheidung.

Aktuell arbeiten die BPOs – immer mehr integriert und mittlerweile mit einem gemeinsamen Backlog ausgestattet – in einem nach 14tägigen Sprint-Routinen aufgestellten agilen „Leichtbauprinzip“. Die harte Abgrenzung ihrer Themenbereiche haben sie weitgehend aufgelöst und unterstützen sich je nach Größe der thematischen Anforderungen gegenseitig oder nehmen sich sogar Themen ab. In der Diskussion zu den Arbeitsweisen ist zum Beispiel eine stärkere Ausrichtung nach Kanban im Gespräch. Das BPO-Prinzip lebt also….und entwickelt sich weiter.