Bewegung für mehr PLM-Offenheit

„Und sie bewegt sich doch“, möchte man mit dem italienischen Mathematiker Galileo Galilei ausrufen, als er seiner Lehre von der Erdbewegung um die Sonne vor der Inquisition abschwören musste. Dummerweise ist berühmte Ausspruch eine Erfindung. Die PLM-Welt ist nach Jahren des Stillstands, in denen die Allianzen zwischen Systemherstellern und OEMs fest zementiert schienen, in Bewegung geraten. Erst hat sich Chrysler, dann Daimler für den Wechsel von Catia auf NX entschieden, und auch andere OEMs denken laut über die Neuordnung ihrer PLM-Landschaften nach.

Die neue Beweglichkeit der OEMs hat viele Ursachen, aber eine Gemeinsamkeit lässt sich zweifellos ausmachen: Alle treibt die Sorge um, die Verfügungsgewalt über ihre Produktdaten zu verlieren. Den Stein ins Rolle brachte nach Meinung vieler Insider PLM-Hersteller Dassault Systèmes mit der Vorstellung von Catia V6, in der die CAD-Daten praktisch nur noch auf dem Umweg über das integrierte PDM-System ENOVIA zugänglich sind. Dabei machen die Franzosen eigentlich nichts, was andere große PLM-Hersteller nicht auch gerne machen würden. Das Problem ist nur, dass ihre Kunden das nicht mehr mit sich machen lassen.

Der Ruf nach mehr Offenheit der PLM-Systeme ist unüberhörbar geworden. Automobilhersteller und Zulieferer wollen ihre heterogenen Systemlandschaften einfacher und flexibler integrieren, um die wachsende Komplexität der Produktentwicklung besser beherrschbar zu machen. Führende OEMs haben deshalb im April dieses Jahres eine Initiative zur Schaffung eines Codex of PLM Openness ins Leben gerufen. Ihr Ziel ist es, bestimmte Mindestanforderungen an die Offenheit von PLM-Werkzeugen und -Lösungen zu formulieren und die Anbieter dazu zu bewegen, sie einzuhalten.

Aufgehängt ist die Initiative in einem Arbeitskreis des ProSTEP iViP-Vereins, dem hochkarätige Vertreter von BMW, Daimler, Volkswagen/Audi und Ford angehören. Koordiniert werden ihre Aktivitäten von Gerhard Seidenfaden, einem „alten Hasen“ aus dem Stall von Daimler, der als heute als Berater über die notwendige Unabhängigkeit verfügt. Der Arbeitskreis wird zunächst ein Memorandum of Understanding mit den Kernforderungen der OEMs erarbeiten, die dann in einem erweiterten Kreis mit Vertretern von Zulieferern und Systemlieferanten diskutiert werden sollen, um bis zum Jahresende ein verbindliches Dokument zu verabschieden. Ein sportliches Ziel.

Es geht bei der Initiative nicht darum, Systemlieferanten wegen mangelnder Offenheit an den Pranger zu stellen. Man wolle gemeinsam mit ihnen einheitliche Eckpunkte für den Zugang zu Systemen und Daten definieren, die als Grundlage für spätere vertragliche Vereinbarungen dienen können, betont Dr. Steven Vettermann, Geschäftsführer des ProSTEP iViP-Vereins. Zwar reden alle von Offenheit, aber was heißt das eigentlich? Weder die OEMs, die mehr Offenheit einfordern, noch die Vendoren, deren Systeme angeblich alle offen sind, verstehen darunter das Gleiche. Was glauben Sie – Ist eine proprietäre API, für die Third-Party-Anbieter oder Kunden auch noch Lizenzgebühren zahlen müssen, nun eigentlich offen oder nicht?

Der Arbeitskreis will keine Schnittstellen oder Formate vorgeben, sondern auf einer relativ abstrakten Ebene festlegen, welche Informationen für eine nahtlose Integration der Systeme und Prozesse benötigt werden. Die Systemhersteller sollen sich freiwillig dazu verpflichten, diesen gemeinsamen Nenner in ihren Systemen umzusetzen. Wie die Einhaltung des Kodex kontrolliert und Verstöße geahndet werden sollen, ist noch nicht ganz klar – der Arbeitskreis setzt hier auf das Feedback der Anwendergemeinde. „Es ist nicht Ziel des Vereins, den TÜV für Systemoffenheit zu spielen“, so Vettermann.

Und wie reagieren die Systemanbieter auf die Initiative für mehr Offenheit? Laut Vettermann erstaunlich offen. Begrüßt wird sie natürlich besonders von den neutralen PLM-Herstellern, die selbst kein CAD-System anbieten und bisher enorme Klimmzüge machen müssen, um an die Informationen zu gelangen, die sie für eine gute Integration der jeweiligen CAD-Systeme benötigen.

Bleibt abzuwarten, ob die OEMs es schaffen, ihre Partikularinteressen hintan zu stellen und sich wirklich auf einen einheitlichen Anforderungskatalog zu verständigen. Sonst haben wir am Ende zig herstellerspezifische PLM Codices, was dem Ziel, einen gemeinsamen Nenner für die Offenheit zu finden, nicht förderlich wäre. Doch was meinen Sie – lässt sich ein solcher Codex of PLM Openness überhaupt durchsetzen?

PLM-Standard – Von Formaten zu Frameworks

Ich möchte über das heutige PLM und Standards reden. In meinen Augen ist die Sache mit den Standards zu kompliziert und verwirrend. Die Anzahl der Artikel über CAD-Dateien, Standards und best practices ist unendlich. In vielen Situationen machen die Leute ein Gleichheitszeichen zwischen Offenheit und Standards. Die CAD-/PLM-Branche verzeichnet eine lange Geschichte von Kriegen um Standards.

Der Status Quo

Nach den Materialien, die von LongView Advisors auf dem CIC (Collaboration and Interoperability Congress) präsentiert wurden, reflektiert das folgende Bild die Verteilung der wichtigsten CAD-Plattformen auf dem Markt.

Den Informationen aus derselben Quelle zufolge hat die Industrie im Jahre 2010 mit etwa 52 CAD-Standards gearbeitet.  Der absolute Spitzenreiter ist STEP (32% Anwendung für CAD-Datenaustausch). Andere für denselben Zweck verwendete Formate sind CATIA V5 (21%), SolidWorks (15%) und NX (6%). Kürzlich habe ich eine sehr gute Veröffentlichung über CAD-Dateiformate gefunden, die von isicad.ru erstellt wurde. Verwenden Sie den folgenden Link, um sie in Englisch zu lesen (Das Original wurde in Russland veröffentlicht. Danke an Google Translate  für die automatische Übersetzungsfunktion). Wenn ich über PLM-orientierte Standards nachdenke, ist die Situation komplizierter.  Aus meiner Sicht sind STEP und PLCS die bemerkenswerten Standards. Verkäufer sprechen über die „best practices der Industrie“, die einen gebräuchlichen Weg für die Implementierung eines PLM-Systems darstellen.

Formate – ein alter Weg?

Die meisten Leute werden an „Formate“ denken, wenn Sie mit ihnen über CAD-/PLM-Standards reden. Normalerweise ist das ein Dateiformat, das von CAD-Systemen für das Speichern und Abrufen von Daten verwendet wird. CAD-Datenaustauschformate zielen in erster Linie auf die Fähigkeit eines Systems ab, Informationen mit anderen CAD- oder nicht-CAD-Systemen austauschen zu können. Die Notwendigkeit, Daten auszutauschen, war nicht auf CAD-Systeme begrenzt. Kürzlich haben PDM- und PLM-Systeme mehrere Mechanismen entwickelt, um Daten zu verschiedenen Zwecken auszutauschen.

Frameworks – ein anderer Ansatz?

Als ich mehr über PLM-Standards nachdachte, kam mir die Idee der Weiterentwicklung von Standards als Framework. Das sehe ich als das Gegenteil von Dateiformaten an. Sie fragen mich, was der Unterschied ist? Die meisten der Formate wurden von Softwareverkäufern oder angeschlossenen Parteien erfunden. Formate stellen die Notwendigkeit des Speicherns und Austauschs von Daten dar. Ich sehe das jedoch nicht als das vorrangige Ziel des PLM-Standardisierungsprozesses an. PLM ist ein Ergebnis der Unternehmensimplementierung und ich betrachte es als etwas ganz anders als ein einzelnes Tool. Beim PLM-Standard geht es allein um die Kommunikation zwischen verschiedenen Leuten in der Organisation. Der Kommunikationsrahmen (Status/Schranken, Entscheidungspunkte etc.) sind viel wichtiger als eine Fähigkeit, eine CAD-Datei von einem Format in das andere zu konvertieren. Der Fokus des PLM-Frameworks ist es, eine Übergabe zwischen den verschiedenen Abteilungen und Leuten in der Organisation zu gewährleisten.

Standardisierung und Uniformität

Ich fand, dass die meisten Leute diese zwei Begriffe  – Standardisierung und Uniformität – durcheinander bringen. Der größte Fehler ist es, Standards als etwas Dauerhaftes anzusehen. Was ich an Standards interessant fand ist, dass erfolgreiche Standards nur jene sind, die sich zusammen mit ihrer Anwendung entwickeln. Wenn sie in der Organisation entsprechend dargestellt werden, können Standards die Leute dazu ermutigen, flexible und einfach zu übernehmende Standardisierungsschemen zu entwickeln.

Was ist meine Schlussfolgerung? PLM muss sich von den Kriegen um Dateiformate weg an eine Stelle bewegen, wo der Kommunikations- und Prozessrahmen verwendet werden kann, um Datenübergabe und Entscheidungsfindung zu kontrollieren. Das wird zu einem neuen Weg bei der Entwicklung von Standards werden. Verwendet von mehreren Unternehmensframeworks kann sich das zu einem Mechanismus entwickeln, um die PLM-Unternehmensroadmap zu realisieren. Ich sehe jedoch keine Prozessschablone, die zu den Bedürfnissen aller Unternehmen passt. Über flexible Kommunikations- und Prozessmanagementtools zu verfügen ist absolut wichtig, um das PLM-Framework zu einem Erfolg zu machen. Nur meine Gedanken…

Beste Grüße, Oleg

(Hinweis: Dies ist eine Übersetzung  des Beitrags „PLM Standard: From Formats to Frameworks“ aus Oleg Shilovitskys Blog Beyond PLM. Übersetzung und Abdruck mit freundlicher Genehmigung des Autors. Ohne Gewähr für die Richtigkeit der Übersetzung.)

 

Lean Compliance

Regelkonformität in der Produktentwicklung

Vor eine paar Monaten habe ich zu dem Thema Compliance einen Beitrag im Produktdatenjournal veröffentlicht. Das Thema ist „heiß“. So sieht beispielsweise die Ernst & Young Studie „Strategic Business Risk: 2008 – The Top 10 Risks for Global Business“ das Thema Compliance die Liste der zehn wichtigsten Unternehmensrisiken anführen. Versäumen Unternehmen, bestimmte Regeln einzuhalten, kann dies den Ausschluss von bestimmten Märkten und Ausschreibungen bedeuten („No data, no market“) oder durch die Produkthaftung substantielle juristische und finanzielle Folgen nach sich ziehen.

Dass dies mittlerweile sehr konkrete Risiken sind, bemerken wir bei vielen Unternehmen, in denen wir zu tun haben – eindrucksvoll zu sehen, welchen Stellenwert das Thema bekommen hat!

Zwar ist beispielsweise die ISO 9000 ein alter Hut, aber die aktuellen Dokumentations- und Qualitätsmanagementvorschriften  stellen heute deutlich konkretere Anforderungen an die Entwicklungsprozesse. Die Maschinenrichtlinie, FDA Vorschriften, die ISO/TS 16949 usw. lassen dabei zusammengenommen keine Branche verschont.

Fluch oder Segen?

Wie gehen Unternehmen damit um? Die Gefahr ist groß, sich vom Regen unter die Traufe zu stellen, stülpt man abstrakte Compliance-Anforderungen schematisch den eigenen Prozessen über. Wie kennen Beispiele, wo der Entwicklungsprozess sich durch eine Unzahl an Formularen dramatisch verlangsamt hat. Dabei behaupte ich: Viele Compliance-Vorschriften  sind im Kern für die Produktentwicklung ein Segen, weil sie auf eine „Good Manufacturing Practice“ zielen: transparente Prozesse und jederzeit einfach nachvollziehbare Ergebnisse. Ist das „ob“ keine Frage mehr, sollte das „wie“ umso sorgfältiger hinterfragt werden. Segensreich wird das Ganze nur dann, wenn

  • die Vorschriften „richtig“, d.h. passend zu den eigenen Prozessen und so schlank wie möglich interpretiert werden. In vielen Fällen lässt sich das „wie“ aus den Regelwerken oft nicht klar ableiten. Hier sind Unternehmen leider auf sehr dünn gesätes Expertenwissen angewiesen.
  • keine separaten Mechanismen verwendet werden, sondern Quality Gates, Deliverables, das Änderungs- und Konfigurationsmanagement usw. zum Diener zweier Herrn gemacht werden: des eigentlichen PEP und der Compliance-Anforderungen. Selbstredend bieten sich hier PLM Plattformen an …

Mein Fazit: Für Compliance-Berater, die Unternehmen aufzeigen,  wie sie so zwei Fliegen mit einer Klappe schlagen können, brechen goldene Zeiten an.