Oleg Shilovitsky hat auf Beyond PLM vor einigen Tagen einen interessanten Blog-Beitrag über die PLM Business Model Transformation veröffentlicht, der einen Paradigmenwechsel in der PLM-Industrie prognostiziert: Weg vom Software-Verkauf zum Kauf von Cloud-basierten PLM-Diensten. Ich will Ihnen seine Schlussfolgerungen nicht vorenthalten:
PLM systems are going through the transformation from the status of business software for data management to a set of services to perform specific engineering and manufacturing activities. By measuring these activities, companies will make an assessment how new PLM services improve the business. The consumption of future PLM services will be growing as soon as companies will be discovering new services and transactions supported by PLM cloud services. The old process of selling software will transform into the process buying services by companies, similar to how companies are buying storage and internet services today.
Zweifellos würde dieser Paradigmenwechsel, so er denn stattfinden, den Umbau der bestehenden PLM-Systemlandschaften enorm erleichtern. Die Unternehmen könnten sie nach und nach um Cloud-basierte PLM-Services ergänzen und die alte Infrastruktur am Ende vielleicht komplett durch PLM aus der Cloud ersetzen. Eleganter kann man einen Elefanten nicht in Scheiben schneiden. Ich bezweifele jedoch, dass dieser schrittweise Umbau für größere Unternehmen kurz- bis mittelfristig ein realistisches Szenario ist, und das sind genau die Unternehmen, die vorrangig PLM einsetzen. Darauf hat Oleg selbst in einem früheren Blog-Beitrag hingewiesen.
Ich habe in den letzten Monaten mit einer Reihe von PLM-Verantwortlichen aus größeren Unternehmen gesprochen, die gerade dabei sind, ihre PLM-Systemlandschaften zu modernisieren. Fast alle folgen noch dem alten Paradigma, das heißt sie ersetzen nach einem klassischen Benchmark ihre bestehende PLM-Lösung durch eine neue. Meines Wissens denkt auch keiner darüber nach, bestimmte PLM-Funktionen künftig als Dienste aus der Cloud zu beziehen, und das auch noch von verschiedenen Anbietern. Das mag eine sehr deutsche Sicht auf die Dinge sein, aber sie trägt dem Umstand Rechnung, dass PLM-Lösungen heute unternehmenskritische Anwendungen sind, mit denen man nicht gerne experimentiert.
Der Umbau einer PLM-Systemlandschaft gleicht einer Operation am offenen Herzen, die sorgfältig geplant sein will, um keine Herzstillstand zu provozieren. Gerade größere Migrationsprojekte geraten oft in gefährliche Schieflagen, weil die Projetteams zu viele Herausforderungen auf einmal zu bewältigen versuchen, wie ich vor einigen Monaten in einem Blog-Beitrag dargelegt habe. Mittelständische Unternehmen tun sich da leichter, vor allem wenn sie auf die Unterstützung erfahrener PLM-Migrationsexperten zurückgreifen, wie das Beispiel von Flugzeugzulieferer SONACA zeigt. Im letzten PROSTEP-Newsletter fand ich dazu einen interessanten Anwenderbericht
Flugzeughersteller müssen beim Umbau ihrer IT-Systemlandschaft(en) ganz andere Dinge beachten, wie ich kürzlich bei Airbus erfuhr. Man kann sie eigentlich immer nur beim Start eines neuen Flugzeugprogramms grundlegen verändern, weil die Zertifizierung der Flugtauglichkeit auch die zur Erstellung und Verwaltung der Dokumente eingesetzten IT-Systeme berücksichtigt. Wollte man sie on the fly auswechseln, müsste man die Flugzeuge neu zertifizieren lassen, was nicht wirtschaftlich ist. Infolgedessen unterhält Airbus für jedes Programm (Sigle Aisle, A380, A350) eine etwas andere IT-Bebauung, die über den gesamten Lebenszyklus der Baureihe aufrechterhalten werden muss. Und das können von der Entwicklung des Flugzeugs bis zur Verschrottung der letzten ausgelieferten Maschine 70 Jahre und mehr sein.
Ich könnte mir vorstellen, dass die strengen Nachweispflichten auch in Branchen wie der Medizintechnik ein gewisses „Tempolimit“ darstellen, was die Implementierung einer IT mit zwei Geschwindigkeiten anbelangt. Die Inspektoren der amerikanischen FDA und anderer Aufsichtsbehörden prüfen nämlich nicht nur die Produkteigenschaften von Pharmaka und medizinischen Geräte, sondern untersuchen bei Inspektionen vor Ort auch, ob die Entwicklungs- und Fertigungsprozesse der Hersteller keine negativen Auswirkungen für die Produktsicherheit darstellen. Die Unternehmen müssen sich also sehr genau überlegen, welche Bausteine ihrer IT-Bebauung für die Prozesssicherheit relevant sind und nur kontrolliert verändert werden dürfen und an welchen Stellen sie mit agilen Methoden neue IT-Werkzeuge zur Unterstützung bestimmter Geschäftsprozesse implementieren können.
