Uncategorized

Zersprengte Prozessketten

Manchmal frage ich mich, wie unsere deutschen Unternehmen es schaffen, so tolle Produkte zu entwickeln und auch noch zu weltweit wettbewerbsfähigen Konditionen zu fertigen. Zwischen Entwicklung und Fertigung tun sich datentechnisch und organisatorisch immer noch Gräben auf. Die Entwickler befürchten, dass ihre Kreativität durch Enterprise Ressource Planning (ERP) in Ketten gelegt wird; die Kollegen in Arbeitsvorbereitung (AV) und Fertigung können oft schon mit dem Begriff Product Lifecycle Management (PLM) wenig anfangen.

Die Gräben werden notdürftig mit schmalen Schnittstellen überplankt, die gerade mal den Austausch und Abgleich der Stammdaten ermöglichen, obwohl sie technisch meist viel mehr können. Schon die Synchronisation von Konstruktions- und Fertigungsstücklisten ist meist mit viel Handarbeit verbunden (siehe auch mein letzter Blogbeitrag). Die mangelnde Integration zwischen Entwicklungs- und Fertigungsprozessen bzw. zwischen den Systemen, die diese Prozesse unterstützen, ist einer Studie von Accenture zufolge eine der großen Herausforderungen, vor der die PLM-Verantwortlichen in Luftfahrt- und Verteidigungsindustrie stehen; in anderen Branchen dürfte das nicht anders aussehen.

PLMketten — Mit freundlicher Genehmigung David Castillo Dominici, www.FreeDigitalPhotos.net

Dass Unternehmen ihre Fertigungsunterlagen im selben IT-System ablegen, mit dem die Konstruktionsdaten verwaltet und versioniert werden, ist eher die Ausnahme als die Regel. Obwohl das gerade mit Blick auf ein durchgängiges Änderungsmanagement Sinn machen würde, weil die Mitarbeiter in der AV dann auf einen Blick erkennen könnten, dass das NC-Programm für die Bearbeitung eines Bauteils nicht mehr dem Stand des Modells oder der Zeichnung entspricht. Mir ist jedoch kein PLM-Hersteller bekannt, der Standard-Schnittstellen zu einem CAM-System anbieten würde, das nicht sein eigenes ist. Was nicht unbedingt Schuld der Anbieter, sondern oft der mangelnden Nachfrage geschuldet ist.

Was man den PLM-Herstellern mit eigener CAD/CAM-Lösungen aber sehr wohl vorwerfen kann, ist dass ihre CAM-Module nicht immer auf der Höhe der (Fertigungs-)Technik und außerdem noch kompliziert zu bedienen sind. Vom fehlenden Know-how für die Programmierung der Postprozessoren und die Maschinenanbindung ganz zu schweigen. Und das ist keine Frage des Geldes, sondern der (falschen) Prioritäten. Statt die Konsolidierung des CAM-Markts zu nutzen, um einen langweiligen, aber kompetenten CAM-Anbieter zu übernehmen, investieren sie halt lieber in „Zukunftsthemen“ wie das Internet der Dinge.

Das führt dann zu der absurden Situation, dass wir uns über die vierte industrielle Revolution mit intelligent vernetzten Fabriken unterhalten, obwohl die dritte (digitale) Revolution im Grabenkrieg zwischen Entwicklung und Fertigung steckengeblieben ist. Wie tief diese Gräben sind, habe ich neulich beim Besuch eines renommierten Herstellers von Stellantrieben feststellen dürfen. Die Firma setzt ein eigenständiges CAM-System ein, weil es die Drehfräsbearbeitung und den vorhandenen Maschinenpark besser unterstützt als das CAM-Modul des CAD-Lieferanten. Dank leistungsfähiger Schnittstellen zwischen CAD und CAM eigentlich kein Problem – sollte man meinen.

Die digitale Prozesskette ist jedoch bei diesem und bei vielen anderen Unternehmen längst nicht so geschlossen wie es auf den ersten Blick erscheinen mag. Zwar programmieren die Mitarbeiter in der AV ihre NC-Programme nicht mehr anhand der Papierzeichnung, sondern auf Basis der CAD-Daten. Aber oft müssen sie diese Daten erst umständlich aufbereiten, weil die Konstrukteure die Geometrie üblicherweise im Nennmaß erzeugen und nicht auf Mitte tolerieren. Sie müssen Flächen verschieben, Zylinder durch richtige Bohrungen ersetzen etc, bevor sie die Bearbeitung programmieren können. Und das ist relativ aufwendig, weil die (parametrischen) CAD-Modelle im CAM-System als dumme Geometrie ohne Historie ankommen.

Die Lösung des Dilemmas ist eigentlich recht einfach und wird in manchen Unternehmen auch praktiziert: Die fertigungsgerechte Aufbereitung der CAD-Modelle ist Aufgabe der Konstruktion bzw. des Konstruktionssystems, in dem sie dank Parametrik wesentlich einfach zu bewerkstelligen ist. Das erfordert jedoch eine Entscheidung des Managements, die ich bislang vor allem in Unternehmen gesehen habe, in denen die Verantwortung für Entwicklung und Fertigung in der Hand einer Person liegt. Vielleicht lässt sich die Unternehmensleitung ja mit folgendem Argument überzeugen: Die zum Teil massiven Eingriff der AV in die freigegebenen CAD-Modelle, die prozesstechnisch nicht oder zumindest nicht im PLM-System dokumentiert werden, sind mit Blick auf die Produkthaftung mehr als bedenklich. Noch ein Grund warum ich der Meinung bin, dass die Fertigungsunterlagen unbedingt ins PLM-System gehören.

In diesem Sinne wünsche ich Ihnen allen ein erfolgreiches Jahr 2015.

PLM-Nutzen muss messbar sein

Vor ein paar Monaten hat Oleg Shilovitsky den PLM-Herstellern und ihren Lösungen in einem Blog-Beitrag vorgeworfen, dass sie sich mit dem Nachweis des Return on Invest (ROI) traditionell schwer tun. Kein neuer Vorwurf und einer, der dem Problem nicht ganz gerecht wird. Es sind nämlich nicht nur die PLM-Hersteller, sondern auch die Anwender selbst, die sich damit schwer tun.

Viele Unternehmen scheuen den Aufwand für die Berechnung des ROI, gerade weil sie einen möglichst schnellen ROI erzielen möchten. Nur scheinbar ein Widerspruch: Um die Nutzeneffekte der Investition exakt messen zu können, müssten sie erst die bestehenden Prozesse und ihre Schwachstellen genau analysieren und Kennzahlen für die Messung von Verbesserungen definieren. Das kostet Zeit und Geld, insbesondere wenn externe Berater involviert sind, weshalb die Analyse des Ist-Zustands meist recht rudimentär ausfällt.

Mit freundlicher Genehmigung von marcolm, freedigitalphotos.net

Manchmal sind die Nutzeneffekte des PLM-Einsatzes so offensichtlich, dass die Unternehmen glauben, sich den Analyseaufwand schenken zu können. Der Geschäftsführer eines Anlagenbauers mit mehr als 150 PLM-Anwendern, der gerade ein aufwendiges Migrationsprojekt hinter sich gebracht hatte, sagte mir neulich auf die Frage nach dem ROI: „Die Investition war definitiv notwendig. Wenn jeder meiner Mitarbeiter dadurch auch nur zehn Minuten Zeit am Tag spart und wir gleichzeitig die Neuanlage von Artikeln reduzieren, brauchen wir über den ROI nicht mehr zu reden.“

In anderen Fällen ist die PLM-Investition unerlässlich, um den wachsenden Nachweispflichten nachkommen zu können. Gerade Automobilzulieferer müssen ihre Entwicklungsprozesse und die Ergebnisse minutiös dokumentieren– sonst laufen sie Gefahr, keine Aufträge mehr zu bekommen. PLM ist dabei von strategischer Bedeutung; wie schnell sich diese Investition bezahlt macht, spielt deshalb eine untergeordnete Rolle.

Erschwert wird der Nachweis des ROI auch noch durch ein anderes Phänomen: Der breiter werdende Funktionsumfang der PLM-Anwendungen und ihre zunehmende Verzahnung mit anderen Unternehmensanwendungen führt zu immer mehr Nutzeneffekten, die sich nur schwer quantifizieren und nicht mehr klar zuordnen lassen. Wie will man zum Beispiel die Produktivitätszuwächse messen, die sich daraus ergeben, dass jüngere Mitarbeiter dank PLM einfacher auf das Erfahrungswissen ihrer Kollegen zugreifen können? Bei Großunternehmen mit vielen Kostenstellen ergibt sich zudem das Problem, dass die Nutzeneffekte nicht unbedingt dort entstehen, wo die Kosten anfallen und auch genehmigt werden müssen.

Es geht bei der Analyse der Nutzeneffekte aber nicht nur um die Rechtfertigung einer einmaligen Investition, sondern auch und vor allem um die Frage, wie sich mit Hilfe von PLM die Effizienz der Produktentwicklung nachhaltig steigern lässt. Dazu müssen entsprechende Prozesskennzahlen definiert und kontinuierlich verfolgt werden. Eigentlich kein Hexenwerk, da die Basisdaten in der PLM-Lösung meist schon vorhanden sind und nur verdichtet werden müssen. Wann eine Änderung beantragt und wann sie abgeschlossen wurde, erfasst das System zum Beispiel automatisch. Es ist mithin ein Leichtes, die Durchlaufzeiten von Änderungsaufträgen zu berechnen.

Wie in meinem letzten Blog-Beitrag zu lesen, sind viele Führungskräfte mit dem Nutzen ihrer bisherigen PLM-Investitionen unzufrieden. Das gilt insbesondere für den Nutzen, den sie für ihre Führungsaufgaben aus den PLM-Daten ziehen. Der Accenture-Surveys erlaubt eine positive und eine negative Interpretation: Erfreulich ist, dass sich die Führungskräfte der strategischen Bedeutung der PLM-Lösungen und der in ihnen steckenden Informationen bewusst sind. Bedauerlich hingegen, dass viele PLM-Hersteller es offensichtlich noch nicht geschafft haben, ihnen geeignete Werkzeuge für die Nutzung dieser Informationen an die Hand zu geben. Ein flexibles Kennzahlenmanagement und gute Reporting-Funktionen sollten heute zum Standardumfang jeder PLM-Lösung gehören.

Datei- oder datenbankorientiert – ist das die Frage?

Auf dem diesjährigen ProSTEP iViP-Symposium hatte ich das Plaisir, einen ziemlich erbosten Dominique Florack zu interviewen. „Wenn die europäischen Unternehmen nicht endlich verstehen, dass die Zukunft der PLM-Technologie im datenbankorientierten Arbeiten liegt, setzen sie ihre internationale Wettbewerbsfähigkeit aufs Spiel“, meinte der Mann, der als Senior Vice President Research & Development bei Dassault Systèmes maßgeblich für die Entwicklung der 3DExperience-Plattform verantwortlich ist. ERP- oder CRM-Systeme arbeiteten schließlich auch datenbankgestützt.

Foto_database — Mit freundlicher Genehmigung Danilo Rizzuti, FreeDigitalPhotos.net

Obwohl ich Florack prinzipiell durchaus zustimmen würde, muss ich zu bedenken geben, dass die Frage des datei- oder datenbankorientierten Arbeitens in erster Linie eine Frage der Autorensysteme ist. Solange CAD-Systeme die Arbeitsergebnisse als Files ablegen, bleibt den PDM/PLM-Lösungen nichts viel anderes übrig, als sie dateibasiert zu verwalten. Aber genau da liegt der Hase im Pfeffer: Was Florack den bockigen Kunden (und uns Journalisten) mit der Cloud im Hinterkopf eigentlich sagen will ist, dass die Zukunft der CAD-Technologie im datenbankorientierten Arbeiten liegt. Um CAD in der Cloud betreiben zu können, brauche man eine andere Software-Architektur.

Auch dagegen wäre prinzipiell nichts einzuwenden, wenn es einen allgemein akzeptierten Standard dafür gäbe, wie der Content einer CAD-Konstruktion datenbankgestützt zu verwalten ist. Oder wenn die CAD-Hersteller ihre Verwaltungsstrukturen offen legen würden. Dann wäre der Kunde nicht gezwungen, ein bestimmtes Datenmanagementsystem (nämlich das seines CAD-Lieferanten) einzusetzen, um aus einzelnen Elementen wieder ein digitales Produktmodell aufzubauen, und er könnte sie auch datenbankgestützt austauschen. Denn es macht keinen Sinn, bei verteilten Entwicklungsprojekten erst datenbankorientiert zu konstruieren, um die Konstruktionen den Partnern in der Zulieferkette dann doch wieder dateibasiert zur Verfügung zu stellen. Dann wären wir wieder in den Anfangszeiten der 3D-Konstruktion, als die Modelle immer wieder platt geklopft wurden, um sie mit den Zulieferern zeichnungsbasiert austauschen zu können.

Ehrlich gesagt, bin ich skeptisch, dass wir einen solchen Standard und/oder das nötige Maß an Offenheit je sehen werden. Zwar haben inzwischen alle namhaften PLM-Hersteller den berühmten Codex of PLM Openness unterzeichnet, der in den letzten Jahren maßgeblich vom ProSTEP iViP-Verein vorangetrieben wurde, doch bezeichnenderweise wurde der CPO auf dem diesjährigen Symposium nicht mit einem Wort erwähnt. Oder wenn, dann so leise, dass ich es nicht vernommen habe. Man hätte gerne gewusst, welche Fortschritte Anwender und Anbieter bei der Umsetzung in den letzten 12 Monaten gemacht haben. Ist die PLM-Welt dadurch ein bisschen offener geworden?

Was das Thema Standardisierung anbelangt, erwähnte Florack STEP AP 242 als mögliche Referenz für die datenbankorientierte Engineering Collaboration; man müsse den Standard nur endlich richtig implementieren, statt ihn auf seine Funktionen für den (dateibasierten) Geometriedatenaustausch zu reduzieren. Das mag wohl sein, aber mir wäre nicht bekannt, dass Dassault ihren Kunden inzwischen die Möglichkeit bietet, CATIA V6-Daten STEP AP242-konform mit einem anderen PDM-System als ENOVIA V6 zu verwalten. Aber was nicht ist, kann ja noch werden, wenn die ISO-Normierung des neuen STEP-Standards erst einmal abgeschlossen ist.

Letztlich geht es aber nicht um die Frage, ob man PLM datei- oder datenbankorientiert betreibt, sondern darum, wie zugänglich die Informationen in der Datenbank sind – für den Erzeuger, dessen geistiges Eigentum sie sind, für seine Partner, die mit den Daten weiter arbeiten sollen, für künftige Anwender, die vielleicht auch noch in 50 Jahren noch darauf zugreifen müssen, und letztlich auch für andere PLM-Hersteller, die diese Daten eventuell in ihre IT-Lösungen migrieren sollen. Solange diese Offenheit nicht gegeben ist, werden die Unternehmen dem datenbankorientierten PLM-Ansatz misstrauen.