Code of PLM Openness
Der Wert der Offenheit
Der Code of PLM Openness (CPO) von 2011 ist ein Leuchtturmprojekt mit internationaler Strahlkraft: Gemeinsam haben Anbieter von PLM-Software, Integratoren und Anwender ein Rahmenwerk geschaffen, das beschreibt, wie offen IT-Systeme und ihre Implementierung aus Sicht unterschiedlicher Interessensgruppen sein müssen, sollten oder könnten. Sieben Jahre nach Einführung der Initiative bilanziert ein Softwareanbieter, der von Anfang an den COP mitgestaltet hat, dass die Architekturmodelle der 2000er-Jahre immer häufiger an ihre Grenzen stoßen.
Bild: ©stokpic/ pixabay.comDass die Selbstverpflichtung auf einen einheitlichen und übergreifenden Standard tatsächlich bahnbrechend ist, zeigt ein Blick in die Historie von Software. Die Entwicklung und Schnelllebigkeit von Softwarelösungen führten dazu, dass Standardisierungen häufig schneller überholt waren als beschlossen. Strategien litten oft unter dem Problem, dass sich bis zu ihrer Umsetzung die Rahmenbedingungen bereits wieder komplett verändert hatten. Von Nachhaltigkeit konnte nicht die Rede sein. Besonders betroffen: das Gebiet der Unternehmenssoftware, allen voran Lösungen zum Produktlebenszyklusmanagement (PLM). Der Grund liegt in der Schlüsselrolle rund um die Produktentstehung, wo Kreativität auf Umsetzung trifft, Produktvielfalt auf hohe Änderungsdynamik und viele Fachdisziplinen, wie etwa Mechaniker und Softwareingenieure, mit ihren eigenen Kulturen und Spezifikationen aufeinanderprallen. Mit der zunehmenden Digitalisierung von Produkten und Prozessen potenzieren sich diese Eigenschaften noch weiter.
Protektionismus oder Offenheit
Aus der Sicht eines Softwareherstellers bedeutet das: Man kann in kurzer Zeit stark wachsen, muss sich aber gleichzeitig im Klaren sein, dass sich auch alles in sehr kurzer Zeit ändern kann. Diese Denkweise prägt die Strategien zur Positionierung am Markt. Hersteller haben hier drei Optionen: Entweder, sie gestalten einen Systemwechsel so aufwändig und teuer und schrecken damit ab (Abhängigkeit), sie versperren Wettbewerbern mit technischen Hürden den Zutritt (Abschottung) oder sie sorgen dafür, dass ein Wechsel leicht und attraktiv ist (Offenheit). Oftmals werden diese Strategien nicht bewusst gewählt, sondern ergeben sich vielmehr aus dem laufenden Geschäft und sorgen erst später für Erfolge oder Konflikte.
Bild: Parametric Technology GmbHPriorisieren und vereinfachen
Im Geschäftsleben eines Softwareherstellers übersteigen die Wünsche der Anwender die eigenen Umsetzungsmöglichkeiten, es kann immer wieder zu missverständlichen Erwartungen entlang der Entscheidungskette bei komplexen Themen kommen oder kurzfristige Eskalationen stören die Planung. In der betrieblichen Praxis entstehen ganz natürlich neue Bedarfsanforderungen nach Unterstützung von Formaten, Systemen, Versionen oder Schnittstellen. Die Lösungen sind oft schnell entwickelt. Die Kosten aber sind enorm, all das über Jahrzehnte bei allen Versionsänderungen durch die Qualitätssicherung zu tragen. Schließlich müssen alle Kombinationen jedes Mal aufs Neue überprüft und getestet werden. Die wichtigste Aufgabe von Produktmanagern ist daher die Priorisierung bei begrenzten Mitteln. Im Sinne des Herstellers, der nicht unendlich viele Konzepte verfolgen kann, sowie im Sinne der Anwender, die verständliche und nachhaltige Konzepte erwarten.
Vertrauensvolle Beziehungen
Um langfristig erfolgreich zu sein, stehen für Hersteller und ihre Kunden daher andere Aspekte im Vordergrund. So sind langfristige, gute Kundenbeziehungen von elementarer Bedeutung, um die tatsächlichen Bedürfnisse im Markt zu kennen und wirtschaftlich rentabel abdecken zu können. Denn der hohe Innovationsdruck im Softwaregeschäft ist teuer. Bei der Schnelllebigkeit von Lösungen muss es möglich sein, weitere Innovationen zuzulassen - mit einer zugänglichen Architektur und einfache Erweiterbarkeit, aber auch mit verfügbaren Kapazitäten. Sind alle Mitarbeiter damit beschäftigt, Konflikte und Probleme rund um die laufenden Lösungen zu lösen, ist kein Platz für Innovation. Und es braucht neue Ideen und Ansätze, wenn Hersteller ihre Anwender langfristig halten wollen. Insbesondere im Geschäft mit Unternehmenssoftware gehört die Integration in die Unternehmensprozesse und Umgebungen sowie ein partnerschaftliches Zusammenspiel zu den kritischsten Punkten. Verläuft diese erfolgreich, baut der Hersteller eine vertrauensvolle Kundenbeziehung auf. Das bedeutet: Wenn sich Softwarehersteller weiterentwickeln und wachsen wollen, müssen sie stabile, offene Architekturen anbieten, die sich gut in die Umgebungen und Abläufe ihrer Kunden integrieren. Doch leichter gesagt als getan, denn die Dynamik des Softwaregeschäftes steht einer langfristigen Planung häufig im Weg und verlangt Kompromisse.
Auf offene Systeme bauen
Das gängige Architekturmodell der 2000er Jahre hat zu leistungsfähigen Systemwelten geführt, deren weiterer Ausbau allerdings mit zunehmend komplexeren und dynamischeren Anforderungen durch neue Technologien und Bedürfnisse ins Stocken geraten ist. Ein aktuelles Architekturmodell setzt dagegen sehr viel stärker auf eine flexible Integration, die sowohl schnelle Innovationen unterstützt als auch die Lauffähigkeit mit Altsystemen. Ein solches Modell erfordert einen Architekturplan, der die vernetzten Unternehmensprozesse unterstützt und möglichst standardisiert ist, sich also an branchenweiten Best-Practices anlehnt. Benötigt wird außerdem eine robuste Vernetzungstechnologie, die Systemintegration, eine einfache Gestaltung von Benutzerschnittstellen und alle Aspekte einer digitalen Prozesskette bis hin zu einem Internet der Dinge unterstützt. Schließlich müssen sich die eingesetzten Werkzeuge in eine offene, stets weiter entwickelnde Systemumgebung einfügen.
Offenheit beschreiben
Der Code of PLM Openness ist eine wichtige Weichenstellung, um genau diese Anforderungen langfristig sicherzustellen und im Verbund von Softwareherstellern, Kunden und Systemintegratoren kontinuierlich weiterzuentwickeln. Gemeinsam gelang man schnell zu der Einsicht, dass es sich bei dem hohen Innovationstempo rund um PLM-Software weniger um eine technische Spezifikation handeln kann, als vielmehr um eine Business-orientierte Beschreibung von Offenheit. Das schlug sich in den Themenfeldern Interoperabilität, Infrastrukturen, Erweiterbarkeit, Schnittstellen, Standards, Architekturen und Partnerbeziehungen nieder, die im engen Austausch definiert wurden. Ein erstes Ergebnis war, dass die Wettbewerber untereinander zu einer besseren Sprache fanden und so im Sinne der Kunden die Qualität der Implementierungen verbessern konnten. Weitere Verbesserungen treten nun schrittweise auf Basis des CPOs ein. So startete 2017 ein Zertifizierungsprogramm für transparentere Strukturen und Erwartungen. Anfängliche Befürchtungen über Verwaltungsmehrkosten konnten dabei schnell überwunden werden. Ein nächster wichtiger Schritt: Der Code of PLM Openness wird noch 2018 in die DIN Spec 91372 überführt. Gleichzeitig wird er unter der Schirmherrschaft des Bundeswirtschaftsministeriums zunehmend auch über das PLM-Thema hinaus etabliert und internationalisiert, allen voran in Japan. Das verdeutlicht noch einmal, welche strategische Bedeutung der Standard für alle Beteiligten hat, von der Fertigungsindustrie bis hin zu Systemintegratoren und Softwareherstellern. Alle Teilnehmer müssen sich dabei bewusst sein, dass die andauernde Innovation insbesondere im Bereich der Unternehmenssoftware immer mit dem Ziel der Standardisierung und Systemkonsolidierung konkurrieren wird. Dieses natürliche Spannungsverhältnis zwischen Fähigkeit und Effizienz wird sich nie auflösen und jeder Marktteilnehmer muss für sich entscheiden, an welcher Stelle er sich hier einordnet. Dem Wert der Offenheit steht damit ein Preis gegenüber, der aus dem Einhalten bestimmter Konzepte besteht und der aktiven Teilnahme an der Gestaltung zukünftiger Konzepte. Denn die Standards von heute sind nicht unbedingt die von morgen.
Der Code of PLM Openness (CPO) von 2011 ist ein Leuchtturmprojekt mit internationaler Strahlkraft: Gemeinsam haben Anbieter von PLM-Software, Integratoren und Anwender ein Rahmenwerk geschaffen, das beschreibt, wie offen IT-Systeme und ihre Implementierung aus Sicht unterschiedlicher Interessensgruppen sein müssen, sollten oder könnten. Sieben Jahre nach Einführung der Initiative bilanziert ein Softwareanbieter, der von Anfang an den COP mitgestaltet hat, dass die Architekturmodelle der 2000er-Jahre immer häufiger an ihre Grenzen stoßen.
Bild: ©stokpic/ pixabay.comDass die Selbstverpflichtung auf einen einheitlichen und übergreifenden Standard tatsächlich bahnbrechend ist, zeigt ein Blick in die Historie von Software. Die Entwicklung und Schnelllebigkeit von Softwarelösungen führten dazu, dass Standardisierungen häufig schneller überholt waren als beschlossen. Strategien litten oft unter dem Problem, dass sich bis zu ihrer Umsetzung die Rahmenbedingungen bereits wieder komplett verändert hatten. Von Nachhaltigkeit konnte nicht die Rede sein. Besonders betroffen: das Gebiet der Unternehmenssoftware, allen voran Lösungen zum Produktlebenszyklusmanagement (PLM). Der Grund liegt in der Schlüsselrolle rund um die Produktentstehung, wo Kreativität auf Umsetzung trifft, Produktvielfalt auf hohe Änderungsdynamik und viele Fachdisziplinen, wie etwa Mechaniker und Softwareingenieure, mit ihren eigenen Kulturen und Spezifikationen aufeinanderprallen. Mit der zunehmenden Digitalisierung von Produkten und Prozessen potenzieren sich diese Eigenschaften noch weiter.
Protektionismus oder Offenheit
Aus der Sicht eines Softwareherstellers bedeutet das: Man kann in kurzer Zeit stark wachsen, muss sich aber gleichzeitig im Klaren sein, dass sich auch alles in sehr kurzer Zeit ändern kann. Diese Denkweise prägt die Strategien zur Positionierung am Markt. Hersteller haben hier drei Optionen: Entweder, sie gestalten einen Systemwechsel so aufwändig und teuer und schrecken damit ab (Abhängigkeit), sie versperren Wettbewerbern mit technischen Hürden den Zutritt (Abschottung) oder sie sorgen dafür, dass ein Wechsel leicht und attraktiv ist (Offenheit). Oftmals werden diese Strategien nicht bewusst gewählt, sondern ergeben sich vielmehr aus dem laufenden Geschäft und sorgen erst später für Erfolge oder Konflikte.
Parametric Technology GmbH
Dieser Artikel erschien in Produktentwicklung Wissen Kompakt 2018 - 09.10.18.Für weitere Artikel besuchen Sie www.it-production.com
