Agile PLM-Entwicklung und Offshoring schließen sich nicht aus

Die Unternehmen in der Fertigungsindustrie stehen vor der Herausforderung, flexibel auf die sich ändernden Markt- und Kundenanforderungen zu reagieren. Dem müssen auch ihre PLM-Lösungen Rechnung tragen und z.B. die Abhängigkeiten zwischen vernetzten Systemen mit wachsendem Software- und Elektronik-Anteil transparent machen, neue Vorgehensweisen wie Model-Based Systems Engineering (MBSE) oder die virtuelle Absicherung von Systemfunktionen durch Co-Simulationen unterstützen und/oder bei sicherheitskritischen Funktionen die Rückverfolgbarkeit der Entwicklungsschritte und -ergebnisse sicherstellen. Die gesamte PLM-Architektur muss auf Wandel ausgerichtet sein.

Aber auch die IT-Organisationen müssen sich umstellen, um neue Anforderungen an die PLM-Systeme schneller umsetzen zu können. Das Wasserfall- oder V-Modell wird der erforderlichen Dynamik nicht mehr gerecht. Zwischen Anforderungsdefinition und Umsetzung vergeht zu viel Zeit, in der die Entwickler kein Feedback erhalten. Sie laufen Gefahr, die Software am Bedarf der Anwender vorbei zu entwickeln. Die Spezifikationen werden mit Anforderungen überfrachtet und lassen sich nur schwer verändern. Ihre Umsetzung orientiert sich an den Verträgen und nicht am Nutzen. Diese und andere Faktoren führen zu sehr langen Projektlaufzeiten, durch die sich die Einführung von Innovationen in den produktiven PLM-Betrieb um Monate und manchmal Jahre verzögern kann.

Immer mehr Unternehmen haben die Schwachstellen ihrer bestehenden Software-Entwicklungsprozesse erkannt und mit der Einführung agiler Lösungsansätze begonnen oder planen dies. Bei der Implementierung agiler Methoden müssen sie sich nicht nur für ein geeignetes Vorgehensmodell entscheiden, sondern auch Entwicklungs-Partner finden, die den agilen Weg mitgehen können. Und sie müssen die Abrechnungsmodelle für die Abwicklung von großen IT-Projekten mit Partnern auf eine neue Grundlage stellen, weil es bei agilen Vorgehensweisen zu Projektbeginn keinen fest umrissenen Lieferumfang mehr gibt.

Ein erheblicher Teil der Software-Entwicklung wird heute ausgelagert (Near- bzw. Offshoring), um die PLM-Expertise in bestimmten Ländern zu nutzen, Kosten zu sparen und/oder über die Parallelisierung der Arbeit die Time to Market zu verkürzen. Idealerweise integrieren sich Partner nicht nur als Mitläufer in die agile Organisation, sondern sind auch in der Lage, eine agile Transformation aktiv mitzugestalten. Voraussetzung dafür ist, dass sie die agilen Methoden nicht nur in der Theorie, sondern auch in der Praxis beherrschen und Erfahrung mit der agilen Software-Entwicklung in global verteilen Projekten haben.

PROSTEP nutzt schon seit vielen Jahren agile Vorgehensweisen bei der Entwicklung der eigenen Software-Lösungen und bringt diese Erfahrung als Partner und Lieferant auch in Kundenprojekte ein. Derzeit sind wir bei zahlreichen Großkunden in Automobilindustrie, Schiffbau und anderen Branchen in agile Projekte eingebunden. In vielen Fällen übernehmen wir als Generalunternehmer die Gesamtverantwortung für diese Projekte und koordiniert die Unterlieferanten, sei es beim Kunden vor Ort oder bei einem Offshore-Partner.

„Unsere Teams kombinieren PLM-Expertise mit praktischer Erfahrung im Umgang mit den agilen Methoden. Sie kennen die Stärken und Schwächen von Scrum, SAFe und anderen Vorgehensmodellen aus der Praxis und können dadurch die agile Transformation beim Kunden aktiv mitgestalten und vorantreiben“, sagt PLM-Manager Frank Brandstetter. Er ist Autor des neuen PROSTEP-Whitepapers, in dem Sie mehr über die Herausforderungen der agilen PLM-Entwicklung erfahren.

Das Whitepaper über agile PLM-Entwicklung wird ergänzt durch ein zweites Whitepaper, in dem Reiner Zeifang, Chief Technology Officer Daimler Projects bei PROSTEP, über seine Erfahrungen mit dem Einsatz agiler Methoden bei Near- und Offshoring-Projekten berichtet. Haupttreiber für die Verlagerung von Entwicklungsaufgaben ist der wachsende Kostendruck, dem unsere Kunden und wir ausgesetzt sind.

PROSTEP arbeitet sowohl bei der Entwicklung der eigenen Software-Produkte als auch bei Kundenprojekten seit geraumer Zeit mit ausgewählten Near- und Offshore-Partnern zusammen. Außerdem praktizieren wir das Nearshoring auch intern. Seit einem Jahr unterhalten wir eine Niederlassung im polnischen Wroclaw (ehemals Breslau), die die Entwicklungsmannschaft der Berliner PROSTEP-Niederlassung bei Software-Entwicklungsprojekten für große Automobilkunden durch agile Scrum-Teams unterstützt.

Das agile Vorgehen ist mit Near- und Offshoring durchaus vereinbar, verstärkt aber einige der damit verbundenen Herausforderungen. Die Partner müssen ein gemeinsames Verständnis für das Kundenprojekt entwickeln und Know-how austauschen, das normalerweise in den Köpfen der Entwickler steckt. Sie müssen einheitliche Vorgehensweise etablieren, um sicherzustellen, dass die zu entwickelnde Software trotz verteilter Teams und großer Entfernung aus einem Guss ist und eine einheitliche User Experience ermöglicht. Und sie müssen Kommunikationshürden abbauen bzw. neue Formen der Kommunikation finden, die mit den agilen Vorgehensweisen kompatibel sind.

Der persönliche Kontakt/Austausch ist entscheidend für den Projekterfolg, wie Zeifang sagt. „Gerade zu Projektbeginn ist es wichtig, dass sich die Key-Player persönlich kennenlernen, um Know-how auszutauschen, aber auch um zu verstehen, wie die anderen ticken, was sie bewegt und wie sie arbeiten.“ Welche Vor- und Nachteile die Zeitunterschiede bei der agilen Software-Entwicklung haben, wie die verteilten agilen Teams aufgestellt sein müssen, ob das Near- und Offshoring mit allen agilen Vorgehensmodellen funktioniert und andere Fragen beantwortet er im neuen Whitepaper.