Was bringt SOA wirklich für PLM?

Seit es Produktdaten-Management-Systeme gibt, und das sind inzwischen auch schon ein paar Jährchen, schlagen sich Systemhersteller und Anwender mit Integrationsproblemen herum. Am Anfang ging es vor allem um die Anbindung von CAD-Systemen und anderen Daten erzeugenden Anwendungen, mittlerweile rückt immer mehr die Kommunikation zwischen verschiedenen PDM-Systemen oder zwischen PDM/PLM-, ERP- und anderen Enterprise-Anwendungen in den Blickpunkt.

Problematisch ist aus Sicht der Hersteller zum einen die schiere Zahl der erforderlichen Integrationen, die ja auch gepflegt und bei Updates aktualisiert werden müssen, zum anderen die Blockadepolitik mancher Mitbewerber. Sie stellen ihnen nicht alle Informationen zur Verfügung, die sie für eine gute Integration benötigen, oder sie tun es nur auf dem Umweg über ihre eigenen PDM-Systeme. Wohin diese Abschottung führen kann, macht Daimlers Abkehr auf Raten von Dassault Systèmes deutlich.

Angesichts dieser zum Teil eher politisch motivierten Integrationshürden stelle ich mir die Frage, welchen Beitrag die viel beschworene Service Orientierte Architektur (SOA) zur Verbesserung der Integrationsfähigkeit der PLM-Lösungen leisten kann? Die Vision klingt absolut verlockend: Ein einheitliches Datenmodell und eine gemeinsame Datenbank für alle Funktionsmodule einer PLM-Umgebung, die eigentlich keine Daten mehr auszutauschen brauchen, sondern über einheitliche Services auf die Informationen und Funktionen der anderen Module zugreifen. Einfacher zu implementieren, zu aktualisieren und zu erweitern.
Zweifellos erleichtert eine solche Einheitsarchitektur den großen PLM-Herstellern, die in den letzten Jahren eine Vielzahl von Anwendungen zusammengekauft haben, die Integrationen ihres Produkt-Bauchladens. Aber davon hat der Anwender, von der einfacheren Systemadministration vielleicht mal abgesehen, noch keinen großen Zusatznutzen. Den hat er erst, wenn SOA wirklich zu einer Art Standard für die Kommunikation zwischen unterschiedlichen Systemwelten wird. Das kann aber nur funktionieren, wenn die einmal definierten Services wirklich ohne Anpassungsaufwand Informationen in beliebigen Anwendungen aufrufen oder verarbeiten können. Werden wir da je hinkommen? Die Lippenbekenntnisse vieler Hersteller, die in der Vergangenheit Offenheit predigen und Verschlossenheit praktizieren, machen mich da eher skeptisch. Was also bringt SOA wirklich für PLM? Diese Frage möchte ich hier mal in den Raum werfen.

PDM/PLM Lösungen: Eine für alle?

Das Posting von Oleg Shilovitsky  PDM. Pre-configured? Painless? hat mich  angeregt, diesen Beitrag zu schreiben. Meinungen, ob es Out-of-the-Box oder auch Turnkey Lösungen geben kann und soll, gibt es mittlerweile zahlreiche. Nur noch nicht von mir (-;

Eigentlich ist die Sache ganz einfach: Ein Begriff wie Out-of-the-Box steht für Standardisierung, und sowohl der Hersteller als der Anwender wird – wenn er bei Verstand ist – nach der Devise verfahren: „So viel Customizing wie nötig, so wenig wie möglich“.

Das Thema ist also in den seltensten Fällen eines für die Farben Schwarz oder Weiß. Jedenfalls kenne ich keine Software selbst für die Textverarbeitung oder was auch immer, bei dem man nicht das Eine oder Andere an seine eigenen Belange anpassen will und kann. Die Frage ist nicht „Ob?“ sondern „In welchem Umfang?“ und vor allem „Wie?“. In jedem Fall haben die Hersteller den Schlüssel in der Hand, ihren Kunden das Leben so einfach wie möglich zu machen, aber auch keine falsche Erwartungshaltung zu wecken.

Wie viel Customizing?

PDM- und PLM-Lösungen sind keine Finanzbuchhaltungs- oder Warenwirtschaftsysteme, deren Verfahren in weiten Teilen durch externe Regularien oder anerkannte Algorithmen bestimmt werden. PDM/PLM soll den Innovationsprozess unterstützen, der von Haus aus eine kreative Angelegenheit ist. Vor allem hier (wo sonst?) werden Unternehmen ihre individuellen und besonderen Fähigkeiten im Wettbewerb beibehalten und ausspielen wollen.

Ein CAD-Datenmanagement wird hoffentlich wenig Anpassung erfordern. Je umfassender jedoch der Innovationsprozess unterstützt werden soll, desto weitreichender werden die gewünschten Anpassungen an individuelle Anforderungen durch den Innovationsprozess des Kunden sein. Vordefinierte „Best Practices“ können einem Unternehmen helfen, aber wenn jedes Unternehmen sich mit Haut und Haaren solchen „Best Practices“ unterordnen würde: Wo bliebe da der Wettbewerbsvorteil?

Wie einfach ist das Customizing?

Wenn man Customizing also nicht wegdefinieren kann, dann soll es bitteschön so einfach und so wartungs- und Release-sicher wie möglich sein. Der Worst Case ist, dass man alles programmieren muss, nur Programmierer die Anpassungen verstehen und pflegen können und dass die Anpassungen beim nächsten Update teuer durchforstet und erneut angepasst werden müssen. Der Best Case sind vordefinierte Stellhebel im System, die es sogar erfahrenen Fachanwendern erlauben, ein System nach ihren Belangen anzupassen. Ein gutes Bespiel sind sogenannte Business Rules, die in weiten Teilen das Systemverhalten beeinflussen, in einer Bibliothek übersichtlich vorgehalten und in einer Form geschrieben werden können, die auch Nicht-Programmierer schnell verstehen und nutzen können.

Falsche Erwartungshaltung?

Welcher Hersteller legt schon gleich den Finger in die Wunde und offenbart seinem potenziellen Kunden über Gebühr, dass individuelle Anforderungen eben auch Geld und Mühe kosten? Wird allerdings ein Projekt an dieser Stelle nicht richtig aufgesetzt, sind Reibung, Zeitverzug und Frustration auf allen Seiten vorprogrammiert. Zaubern kann niemand, und es ist Aufgabe der Profis beim Hersteller oder Berater, den Kunden hier an die Hand zu nehmen. Im Zweifel muss fester gedrückt werden!

Was ist ihre Meinuing: Wann machen Out-of-the-Box Lösungen für den Innovationsprozess Sinn?

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.)