Ausgangssituation

Nach der Übernahme des Schweizer Flugzeugausrüsters und Wartungsunternehmens mit knapp 40 Standorten und über 6.000 Mitarbeitern durch einen amerikanischen Rüstungskonzern soll das bestehende in die Jahre gekommene und abgekündigte PLM-System durch das PLM-System der neuen Muttergesellschaft ersetzt werden. Für eine reibungslosere CAD-Daten Integration soll das bisherige CAD-System durch das CAD-System des neuen PLM-Anbieters ersetzt werden.

Da Flugzeuge einen Lebenszyklus von um die 20 Jahre haben und strenge regulatorische Vorgaben durch die Luftfahrtbehörden einzuhalten sind, gibt es umfangreiche Bestandsdaten, die lückenlos übernommen werden müssen.

Eine besondere Herausforderung ist die im PLM-Umfeld nicht alltägliche Kombination aus Architektur-CAD, Mechanik-CAD und Elektronik-CAD, die allesamt in die PLM-Umgebung und regulatorischen Vorgaben eingebunden werden müssen. Die PLM-Disziplinen CAD-Daten Management, BOM Management, Release sowie Change Management, ERP-Anbindung und Systems Engineering sind abzubilden. Das PLM-System soll sowohl die CAD-Daten des bisherigen mechanischen CAD-Systems (Catia) als auch die CAD-Daten des zukünftigen mechanischen CAD-Systems (NX) verwalten und visualisieren können. Dazu kommt die CAD-Daten-Verwaltung und die Visualisierung für das Architektur-CAD-System und das Elektronik-CAD-System.

Aufgrund der engen Budgetgrenze und dem eng gesteckten Zeitplan sollen möglichst viele Leistungen durch OffShore-Kapazitäten erbracht werden. Am Hauptstandortort des Kunden wird von jedem Vertragspartner eine permanente Rolle für die Projektkoordination im Steuerungsteam erwartet. Facharchitekten sollen bei Bedarf und für regelmäßig stattfindende Alignment Meetings ebenfalls persönlich am Hauptstandort zur Verfügung stehen. Die Projektsprache ist aufgrund der kundeneigenen Ressourcen Englisch.

Der Hersteller des zukünftigen PLM-Systems soll aus politischen Gründen nicht bei der Implementierungsleistung berücksichtigt werden. Das Unternehmen sieht sich mit einer Vielzahl potenzieller Leistungsanbieter konfrontiert. Dabei fällt auf, dass Anbieter einzelne Leistungsbereiche sehr gut und andere kaum bis gar nicht abdecken können. Ein Anbieter für alle Leistungsbestandteile ist nicht zu erkennen. Die Lösung der Architektur- und Elektrik-CAD-Daten Integration ist für das Projekt erfolgsentscheidend.

Fragestellung

• Wie können die am Markt verteilten Kompetenzen so kombiniert werden, dass in Summe eine passende Lösung entsteht?
• Wie können die einzelnen Leistungsanbieter durch zentrales Fachwissen über Luftfahrt Compliance unterstützt werden, dass die Lösung den Vorgaben der Luftfahrtbehörden entspricht?
• Wie können die Leistungen innerhalb der Budget- und Zeitgrenzen eingehalten werden?
• Wie können OffShore-Ressourcen unterschiedlicher Anbieter eingebunden und untereinander abgestimmt werden, ohne dass es zu Reibungsverlusten und Verzögerungen kommt?
• Wie können Leistungen so ausgeschrieben werden, dass ein vergleichbares Ergebnis und transparent nachvollziehbare Entscheidungen zustande kommen?

Lösung

Das Unternehmen entscheidet sich für ein externes Vendor Management mit dem Ziel, eine passende Auswahl geeigneter Dienstleister zu finden, die in Summe das Projekt zum Erfolg führen können. Um die Neutralität zu wahren, wird der Vendor Manager von Anfang an von der Implementierungsleistung ausgeschlossen. Die Aufgaben des Vendor Managements konzentrieren sich auf die Vorbereitung der Ausschreibung, das Management des Bieterprozesses, die Vorbereitung der Lieferantenauswahl, den Betrieb der kundeneigenen Systemumgebung, das Testing bis zum Going-Live und das Lieferantenmanagement in der Lösungs- und Implementierungsphase.

Nach der Auftragsvergabe wird das Projekt in zwei Phasen unterteilt. Die erste Phase beschäftigt sich mit der Anforderungsermittlung und Beschreibung der User Stories sowie der System-Architektur, die überwiegend beim Unternehmen vor Ort umgesetzt wird. Zusätzlich wird in dieser Phase die System-Infrastruktur und ein MVP aufgebaut. Die zweite Phase beschäftigt sich auf dieser Grundlage mit der Implementierung der Anforderungen im MVP, der iterativ bis zur Inbetriebnahme weiterentwickelt wird.

Neben dem Lösungs- und Implementierungsprogramm, in dem sich alle beauftragten Geschäftspartner wiederfinden, wird ein IT-Programm, ein HR-Programm und ein Einkaufs-Programm aufgesetzt. Im IT-Programm wird der Aufbau der System-Infrastruktur, das Testing, der Support und das Training für die Projekt-Anwendungen umgesetzt. Zu den Anwendungen zählt auch eine ALM-, Dokumentations- und Testing-Umgebung, in die alle Projektpartner hineinarbeiten. Auf ein automatisiertes Testing wird aus kurzfristig ausgerichteten Budgetgründen von Anfang an verzichtet. Im HR-Programm werden die Ressourcen-Kapazitäten des Unternehmens geplant, Mitarbeiter auf die Erwartungen und Ziele des Unternehmens vorbereitet und notwendige Prozess-Änderungen mit den Fachbereichen abgestimmt. Im Einkaufs-Programm werden die Leistungen, Lizenzen sowie dafür notwendige Hardware eingekauft und zusammen mit dem Facility Management notwendige Installationen und Raumbelegungen abgestimmt.

Das Betreiberkonzept sieht vor, dass die Produktiv-, Schulungs-, Testing- und Integrationsumgebungen durch das Unternehmen und die Entwicklungs-, Testing- und Demoumgebungen durch die jeweiligen Auftragnehmer bereitgestellt werden.

Umsetzung

Das Unternehmen hat eine bestehende ALM- und Dokumentationsumgebung für alle Projektbeteiligten zur Verfügung gestellt.

Die bestehenden High-Level-Anforderungen (Epics) aus der Portfolio-Ebene wurden durch den Vendor Manager in Zusammenarbeit mit relevanten Bereichs- und Abteilungsleitungen in Capabilities und Features heruntergebrochen und mit weiteren Anforderungen angereichert. Diese Capabilities und Features waren Grundlage zur Definition von Arbeitspaketen und deren Beschreibung, die sich in den Ausschreibungsdokumenten wiedergefunden haben. Zusätzlich wurde in der Ausschreibung eine Angebotsmatrix zur Verfügung gestellt, die einen vergleichbaren und effizient zu verarbeitenden Rücklauf ermöglichte.

Eine weitere Aufgabe war die Definition und der Aufbau der Systemumgebungen sowie der Aufbau eines MVP. Der erste MVP beschränkte sich dabei auf das nackte PLM-System ohne Anbindungen, eine Produktiv-, eine Testing- und eine Integrationsumgebung. Dieser erste MVP sollte dann in der ersten Projektphase durch Definition des Datenmodells, des Access Rights Management und weitere Grundlagen weiterentwickelt werden. Zusätzlich wurde eine Integrations- und Deployment-Infrastruktur aufgesetzt und getestet.

Innerhalb eines gemeinsamen Termins mit allen eingeladenen Anbietern wurde das Projekt, seine Ziele und auch besondere Herausforderungen vorgestellt und erste Fragen beantwortet. Im weiteren Verlauf stand ein Frage-Dokument zur Verfügung, das regelmäßig für alle Beteiligten aktualisiert wurde. Nach der Angebotsabgabe wurde aufgrund fachlicher Selektion eine Short-List gebildet. Die verbliebenen Anbieter stellten Ihre Angebote vor und beantworteten Rückfragen durch das Vendor Management und das Unternehmen.

Ab diesem Punkt wurde dem Unternehmen klar, dass das geplante Budget trotz Verhandlungsbemühungen nicht erreicht werden konnte. Nach einer kurzen Überlegungsphase des Unternehmens wurde die Entscheidung getroffen, das Vendor Management und alle damit zusammenhängende Leistungen über eigene Ressourcen abzudecken.

Projektmethode

Das Vendor Management und die erste Projektphase wurden nach dem Wasserfallmodell geplant und umgesetzt, weil dabei wohl durchdachte Grundlagen gelegt wurden, die nachträglich nur schwer oder mit extrem hohem Aufwand zu korrigieren gewesen wären. Die zweite Projektphase wurde auf Teamebene mit einer Mischung aus Scrum und Kanban (Scrumban) agil durchgeführt und über SAFe auf die Programm-, Solution- und Portfolio-Ebene hochskaliert.

Release Train Engineers (RTEs) des Vendor Managers sollten durch Remote-Zusammenarbeit die Koordinierung der Lösungsteams unterschiedlicher Lieferanten übernehmen, die hauptsächlich von OffShore in Indien zuarbeiteten. Ziel war dabei zu festgelegten Zeitpunkten funktionierende Releases zur Verfügung stellen zu können, die dann iterativ weiterentwickelt werden sollten. Ein Solution Train Engineer (STE) des Vendor Managers sollte die Koordinierung der Programme übernehmen, so dass zu festgelegten Meilensteinen funktionierende Zwischenstände erreicht werden sollten.

Der Vendor Manager unterstützte das Unternehmen auf Solution Ebene mit einem Solution Architect. Jeder Auftragnehmer sollte die benötigten System Architekten für die Programm-Ebene und Technischen Architekten in den eigenen Lösungsteams zur Verfügung stellen. Dabei sollte es eine enge tägliche Zusammenarbeit zwischen den Technischen Architekten und System Architekten geben.

Herausforderung

Im Laufe des Bieterprozesses hat sich herausgestellt, dass das Budget deutlich zu niedrig angesetzt war Aus diesem Grund wurden geplante Fremdleistungen durch unternehmenseigene Ressourcen erbracht. Dazu gehörte die Mehrzahl der IT-Leistungen wie. z.B. der Betrieb der notwendigen Systemumgebungen als auch die Integrationstests der zugelieferten Lösungsbestandteile, die ursprünglich im Bereich des Vendor Management eingeplant waren. Leider ist dem Budgetzwang auch das Lieferantenmanagement in der Implementierungsphase inklusive des Einsatzes von RTEs und STEs zum Opfer gefallen. Auch die Solution Architektur wurde mit dieser Entscheidung in die eigenen Hände genommen.

Eine zweite große Herausforderung waren ständig neu aufkommende Anforderungen, die im Rahmen der Festpreisvergabe weder ausgeschrieben noch angeboten wurden. Im dadurch entstandenen Spannungsfeld zwischen dem Unternehmen und seiner Auftragnehmer galt es durch gegenseitiges Verständnis die Wogen zu glätten und zu einer funktionierenden Lösung zu führen.

Die Auftragsvergabe mit Festpreisen und die agile Projektmethode in der zweiten Projektphase haben zusätzlich zu Spannungen zwischen dem Unternehmen und seiner Auftragnehmer geführt, weil ab einem gewissen Zeitpunkt allen klar war, dass die erwarteten Leistungen nicht mit den tatsächlichen Aufwendungen zu erreichen waren. Im Grunde war dies allen Beteiligten bereits nach der Bieterschlacht und der Auftragsvergabe bekannt. Die Lösung dieser Situation hat den Projektverlauf nachhaltig verzögert und letztendlich doch dazu geführt, dass das Budget aufgestockt werden musste.

Eine besondere Herausforderung war wie erwartet die Koordinierung unterschiedlicher Vertragspartner mit unterschiedlichen Kompetenzen und kulturelle Eigenheiten, die sich auf die Lieferqualität und Lieferzeiten ausgewirkt haben.

Projektinformationen

Projektdauer: 3 Monate für das Vendor Management

Projektteam: 1 Solution Architekt und 1 PLM Consultant

Projektbudget: 5 Mio. €

Fazit

Dieses Projekt ist ein klassisches Beispiel dafür, dass Unterbudgetierung letztendlich teurer als ein sauber budgetiertes Projekt wird. Viele der dadurch entstandenen Probleme, Spannungen und Verzögerungen hätten einfach vermieden werden können, wenn die Parteien in der Vertragsanbahnungsphase nicht in Traumwelten abgehoben wären. Diese Traumwelten platzen zwangsläufig spätestens mit der Implementierung. Genauer gesagt: die Differenz zwischen Traum und Wirklichkeit wird bei der Story Estimation nach dem Refinement in den Teams offensichtlich und in den Sprints platzen die Traumballons, so dass die Erwartungen in diesem Moment hart auf dem Boden der Realität aufschlagen. Für mich ist immer wieder erstaunlich, warum Unternehmen regelmäßig damit scheitern und trotzdem keine Konsequenzen ziehen.

Die Ansätze waren gut und professionell. Die Umsetzung war enttäuschend, teuer, langwierig und sehr nervenzehrend. Bereits die Entscheidung für eine Ausschreibung mit Festpreisen war die Grundlage für die Unvereinbarkeit von Flexibilität und Planungssicherheit – zumal der Weg zum Ziel durch die außergewöhnliche und branchenspezifische Aufgabenstellung nicht absehbar war.

Mein Arbeitgeber

PLM Beratungsunternehmen, das für das Vendor Management einen PLM Solution Architekt und einen PLM Consultant zur Verfügung gestellt hat.

Meine Rolle

Ich habe als PLM Consultant die Anforderungen ermittelt, daraus zusammen mit dem Solution Architekt passende Arbeitspakete abgeleitet, den Solution Architekt beim Verfassen der Ausschreibungsdokumentation unterstützt und daraus die Angebotsmatrix erstellt. Im Bieterprozess habe ich die Kommunikation mit den Anbietern übernommen, Fragen selbst oder in Zusammenarbeit mit dem Solution Architekt und Mitarbeitern des Unternehmens beantwortet.

Meine Rolle als RTE oder STE ist durch eine budgetgetriebene Planänderung des Auftraggebers nicht zur Umsetzung gekommen.