Pioneering a cloud-based R&D Environment – Teil 2: Vom klassischem Operating Model zur kontinuierlichen R&D Evolution

Die gute Nachricht: Mit der Einführung modular erweiterbaren und cloud-basierten Product-Lifecycle-Management (PLM) Systemen kommen wir dieser idealen Welt einen sehr großen Schritt näher.

Die Architekturformen erlauben die kontinuierliche Adaption der digitalen Arbeitsumgebung und ermöglichen die Bereitstellung von neuen Features im Minutentakt.

Durch diesen Technologiesprung können wasserfallartige Transformationsprojekte und Arbeitsweisen endgültig ad acta gelegt werden. Die neue Devise lautet nicht mehr Instandhalten, sondern kontinuierlichen Wert für die R&D stiften. Bevor wir aufzeigen, wie diese Transformation gelingt, wollen wir uns zuerst mit den typischen Fehlern beschäftigen.

Drei typische Fehler:

• Definition eines fixen Projektumfangs durch die falsche Verwendung von agilen Elementen wie User Stories
• Definition eines fixen Projektbudgets anstelle eines kontinuierlichen Valve Stream Financing
• Fehlendes Verständnis und Commitment im Senior Management über die neuen Arbeitsweisen und Verantwortlichkeiten

Transformation des Operating Models – Organisation

„Value doesn’t follow silos“ Für eine erfolgreiche Transformation müssen bestehende Strukturen aufgebrochen und neue Arbeitsweisen etabliert werden. Die in vielen Unternehmen heutzutage bestehenden Bereiche aus R&D IT, R&D Prozess Management, R&D IT Betriebsteam sowie den R&D Mitarbeitern bieten das Potential in interdisziplinären Teams effizienter und wertfokussierter zusammenzuarbeiten.

Kombiniert man die Fähigkeiten und Mitarbeiter optimal mit dem finalen Zielbild von DevOps Teams, lässt sich ein agil skaliertes Operating Model ableiten, dass es ermöglicht die Transformation erfolgreich umzusetzen. In der Praxis hat sich gezeigt, dass ein wohlbedachter Ramp-up nach Schaffung der Grundvoraussetzungen die effizienteste Art und Weise ist, das Operating Model zu realisieren.

Team & Release Train Layer:

Tools und Funktionen müssen den Anwendern einen echten Mehrwert bieten und müssen deswegen auch von diesen mitgestaltet werden. Deshalb bilden funktionsübergreifende Teams das Fundament der Organisation. Sie brechen Silos auf und stellen das Commitment sicher. In den Teams ermöglichen Scrum Master, Product Owner, Solution Architekt, Business Experten, Entwickler und Tester die effiziente Zusammenarbeit.

Der Release Train Layer unterstützt die Teams in der teamübergreifenden Zusammenarbeit und sorgt für alle relevanten Voraussetzungen. Der Release Train ist für die Planung des Produkt Inkrements sowie der Steuerung der Synchronisation und kontinuierlichen Integration der Entwicklung zuständig. Hinzu kommt die Verwaltung der „Continuous Delivery Toolchain“, die als Rückgrat des agilen Liefermodels angesehen werden kann und bei Bedarf neue Features live schaltet.

„Automatisch getestete Lieferungen im dreiwöchigen Rhythmus sind inzwischen Standard.“

Eine zentrale Aufgabe neben der Entwicklung neuer Funktionalitäten besteht darin, die neu entwickelten Features zu etablieren. Methoden wie „Train the Trainer“ dienen des gezielten Trainings von Key Usern, die Ihr Wissen in die gesamte Organisation tragen. Gleichzeitig wird eine Community aufgebaut, welche das Wissen langfristig in das Unternehmen integriert und Feedback in die Weiterentwicklung einbringt.

Beispiel:

Mit Hilfe der „Train the Trainer“ Methode konnten bereits in zahlreichen Projekten Anwender rund um die Welt geschult werden. Im jüngsten Projekt ca. 1500 Anwendern in 6 Ländern.

Nicht zu vernachlässigen bei der Transformation des Operating Models ist das Change-Management, das einher gehen muss mit entsprechendem Management Commitment. Dies bringt uns zum Portfolio Layer.

Portfolio Layer

Der Portfolio Layer muss „Strategie & Finanzierung“, „Lean Governance“ und „Program Operations“ verantworten und dies in Form der „Program Owner“ Rolle vorleben, um das gesamte Team zu befähigen.

„Werden die Rollen im Portfolio Layer nicht wahrgenommen, zeigen Vergleiche zwischen Teams und Programmen eine Variabilität von bis zu 65% der Leistung.“

Transformation des Operating Model – Arbeitsweise

Ist die Strategie definiert und die Architekturentscheidung gefallen, hat die Realisierung des minimal überlebensfähigen Produkts höchste Priorität. Ein zentraler Erfolgsfaktor dafür ist die stringente Fokussierung auf die profitabelsten Value Streams entlang der integrativen Prozesse. Die Verwendung eines Value Stream House, welches auf aktuelle Arbeitsweisen verschiedenster Projekte zurückgreift, beschleunigt den Prozess dabei erheblich.

Die Value Streams (Epics) und untergeordnete Funktionen (Feature) können dann basierend auf dem tatsächlichen Mehrwert durch den jeweiligen Layer priorisiert, detailliert und umgesetzt werden.

„Durch unsere Transformationsprojekte ist ein industrieübergreifender Vergleich der zentralen KPI’s der Value Streams möglich“

Die Strukturierung der Tätigkeiten in Form von Epics und Features sowie die Priorisierung in programmweiten Workshops „PI Plannings“ ermöglicht die Realisierung des MVP in kürzester Zeit. In den „PI Plannings“ arbeiten die Teams an zwei Tagen funktionsübergreifend zusammen. Sie entwickeln ein gemeinsames Commitment über den Umfang der nächsten Entwicklungssprints und ermöglichen so die kontinuierliche Evolution des Business Case.

In unserem nächsten Blog werden wir auf die zentralen Value Streams eingehen und uns so auf den fachlichen Teil der R&D Wertschöpfungskette fokussieren.

Vielen Dank an die Co-Autoren Leon Bongers und Robin Thomas.

Zu den anderen Artikeln der Blogreihe

1. Pioneering a cloud-based R&D Environment – Teil 1: Der Business Case für die cloud-basierte Zukunft der R&D