Ungekategorisiert

Die Stückliste bleibt auf der Tagesordnung

Das ProSTEP iViP Symposium jagt von Rekord zu Rekord. Mit über 550 Teilnehmern und 33 Ausstellerfirmen war die diesjährige Veranstaltung im ICS in Stuttgart noch besser besucht als die des Vorjahres in Berlin, die erstmals die Schallmauer von 500 Ausstellern und Besuchern durchbrach. Obwohl oft als “Familientreffen” der technischen IT-Experten aus Automobil- und Flugzeugindustrie bezeichnet, waren mehr als die Hälfte der Teilnehmer zum ersten Mal dabei. Das liegt nicht nur an der allmählichen Verjüngung der IT-Mannschaften (Frauen sind immer noch deutlich unterrepräsentiert), sondern auch daran, dass es dem Verein durch gezielte Werbekampagnen insbesondere in Japan gelungen ist, den Anteil der ausländischen Besucher zu steigern. Vertreter aus 19 Ländern nahmen in diesem Jahr am Symposium teil.

Mit freundlicher Genehmigung von Ralf Kopp, ProSTEP iViP

Die Organisatoren versuchen außerdem, die Veranstaltung durch den Brückenschlag von der virtuellen Produktentwicklung zum Digital Manufacturing thematisch breiter aufzustellen und auch dadurch neue Interessenten anzulocken. Das spiegelt sich allerdings noch nicht in der Zusammensetzung der Besucherschaft wider, die nach wie vor sehr Engineering-orientiert ist. Beherrschendes Thema war in diesem Jahr das Smart (Systems) Engineering als Antwort auf die Herausforderung des Internets der Dinge (IoT), das heißt die Vernetzung von Fahrzeugen und anderen Produkten über das Internet und die daraus resultierenden neuen Serviceangebote und Geschäftsmodelle. Da war Hauptsponsor Bosch natürlich in seinem Element.

Bei so vielen Hype-Themen war ich angenehm überrascht, auch die gute alte Stückliste bzw. die Diskussion über die Hoheit der BOM (Bill of Material) auf der Tagesordnung zu finden. Bodenständige Kost, aber vom Feinsten, so wie überhaupt die Verköstigung in diesem Jahr ausgezeichnet war. Den Auftakt machten die Vertreter des brasilianischen Flugzeugherstellers Embraer, die ihre IT-Systemlandschaft unter anderem deshalb um das PLM-System Windchill ergänzt haben, um Konstruktionsstückliste, pardon eBOM, und Fertigungsstückliste unabhängig voneinander managen und ändern zu können.

Mit freundlicher Genehmigung von Beyond PLM — Mit freundlicher Genehmigung von Oleg Shilovitsky, Beyond PLM

PLM-Experte Oleg Shilovitsky, dessen Blog Beyond PLM ich an dieser Stelle zur Lektüre empfehle, verteidigte in seiner Keynote hingegen die Vision einer einheitlichen, über die Systemgrenzen von PLM und ERP hinweg synchronisierbaren BOM. Leider seien die Unternehmen nicht “ready for a single BOM”. Eine Position, die übrigens auch von PLM-Papst Prof. Martin Eigner geteilt wird, der in der Fragerunde den Konstrukteuren empfahl, in den Strukturen der mBOM denken zu lernen. Wen wundert es, dass die Stückliste beim anschließenden Get Together Gegenstand angeregter Diskussionen war.

Bei allem Respekt vor Martin Eigner und Oleg Shilovitsky bin ich der Ansicht, dass die Idee einer Art Einheitsstückliste zumindest nicht für alle Unternehmen eine tragfähige Lösung darstellt. Dies umso mehr als smarte Produkte und neue IoT-basierte Geschäftsmodelle dazu führen werden, dass diese BOM nicht mehr nur die Sichten von Mechanik-Konstrukteuren und Fertigungsplanern, sondern auch von Elektrik/Elektronik-Entwicklern, Software-Programmierern und Serviceleuten harmonisieren müsste. Die Abstimmung zwischen den beteiligten Disziplinen stelle ich mir beliebig komplex vor. Statt einer Einheitsstückliste brauchen die Unternehmen meines Erachtens ein einheitliches System, in dem sie verschiedene Sichten bzw. Stücklisten-Strukturen verwalten und bei Änderungen konsistent halten können.

Die Entscheidung, welches System das sein soll, muss jedes Unternehmen selber treffen – in Abhängigkeit von der Multi-BOM-Fähigkeit der eingesetzten PLM-, ERP- oder vielleicht sogar anderer IT-Systeme. Instruktiv war in dieser Hinsicht der Vortrag der Faymonville S.A. auf dem Symposium, die ihre Schwerlasttransporter zum Teil kundenspezifisch entwickelt, zum Teil aber auch aus einem Baukastensystem auftragsspezifisch konfiguriert. Um den Configure-to-Order-Prozess besser zu unterstützten, hat das Unternehmen die Fertigungsstückliste zu 150% in ihrem PLM-System abgebildet. Auch bei Embraer wird die mBOM zunächst im PLM-System angelegt und dann erst an das ERP-System repliziert.

Vielleicht ein Paradigmenwechsel? Es würde mich interessieren, was Sie über das Thema denken.

Auch PLM-Systeme kommen in die Jahre

Mit einem Textverarbeitungsprogramm, das nicht mehr auf dem aktuellen Stand ist, über die Notwendigkeit der Software-Aktualisierung zu schreiben, ist nur scheinbar ein Widerspruch. Während man bei Word & Co. als normaler Anwender durch einen Versionswechsel kaum noch Produktivitätszuwächse erzielt, dafür aber tagelang damit beschäftigt ist, vertraute Funktionen wiederzufinden, die ein agiler Software-Entwickler aus unerfindlichen Gründen dort versteckt hat, wo man sie nicht suchen würde, kann die Aktualisierung einer Unternehmensanwendung einen Produktivitätsschub auslösen. Insbesondere wenn es sich um eine historisch gewachsene IT-Lösung handelt.

Alt- oder Legacy-Systeme sind strukturell zukunftsunfähig, weil sie meist auf einer veralteten Technologie basieren, inkompatibel zu anderen Unternehmensanwendungen sind und sich nicht oder nur mit einem hohem Aufwand an die aktuellen Anforderungen anpassen lassen. Ihre Aufrechterhaltung bindet nicht nur Personal mit Know-how, das immer schwerer zu finden bzw. zu ersetzen ist, sondern auch finanzielle Ressourcen, die nicht mehr für Investitionen in die Modernisierung der IT-Landschaft zur Verfügung stehen. Darauf hat kürzlich die Management-Beratung Lüdendonk in einem Whitepaper über die Software-Modernisierung hingewiesen, das ich zur Lektüre empfehle.

Mit freundlicher Genehmigung von dan, www.FreeDigitalPhotos.net

Obwohl sich die IT-Verantwortlichen der Tatsache bewusst sind, dass die Modernisierung der Software-Landschaften eine Notwendigkeit ist, halten sie an ihren Legacy-Systemen oft genauso zäh fest wie ich an meinem alten Texteditor. Das liegt daran, dass diese Systeme sehr viel Unternehmens-Know-how beinhalten und oft so eng mit anderen IT-Lösungen verknüpft sind, dass sich die Auswirkungen einer Modernisierung nur schwer abschätzen lassen. Dies umso mehr als ihre Entstehungsgeschichte oft nicht sauber dokumentiert ist. Die Experten von Lüdendonk empfehlen dennoch eine planvolle Modernisierung der Software-Landschaft und stellen dafür verschiedene Strategien vor.

Zugegebenermaßen haben neue Software-Programme manchen Bug, aber sie sind in den letzten Jahren deutlich zuverlässiger geworden. Die Furcht vor Kinderkrankheiten sollte deshalb kein Grund sein, seine Software-Installation nicht zu aktualisieren. Gerade moderne PLM-Systeme bieten heute standardmäßig einen Funktionsumfang, der vor einigen Jahren nicht oder nur mit einem hohen Anpassungsaufwand und Zusatzprogrammierungen erreichbar war. Die bestehenden IT-Lösungen abzulösen, hat den Vorteil, dass man sie funktional wieder näher an den Standard heranführen kann. Das reduziert nicht nur den Aufwand für Wartung und Pflege der Installation, sondern erleichtert auch Software-Updates. Davon abgesehen erlauben die heute zur Verfügung Programmierwerkzeuge eine einfachere und schnellere Zusatzprogrammierung, falls doch einmal kundenspezifische Erweiterungen erforderlich sind.

Außerdem werden die Architekturen der PLM-Systeme nicht zuletzt auch unter dem Druck von Initiativen wie dem Codex of PLM Openness offener, was ihre Integration in bestehende IT-Landschaften vereinfacht. Alle diese Faktoren haben zur Folge, dass die Kosten für Anschaffung und Betrieb einer PLM-Lösung tendenziell sinken. Deshalb sollten gerade Unternehmen mit einer älteren und stark kundenspezifisch angepassten PLM-Lösung ernsthaft über eine Modernisierung ihrer Installation nachdenken. Die Lebensdauer der Alt-Systeme zu dehnen, hat Lüdendonk zufolge negative Auswirkungen auf die Gesamtkostenstruktur der IT: “Je mehr Zeit und Geldmittel […] die Unternehmen für die Wartung älterer Software aufwenden müssen, desto weniger bleibt für die Realisierung zukunftsweisender Projekte übrig”, so die Autoren des Whitepapers.

In den letzten Monaten habe ich eine Reihe von Unternehmen besucht, die sich aus dem einen oder anderen Grund für eine Modernisierung ihres PLM-Systems entschieden haben. Der damit verbundene Aufwand war zum Teil nicht unerheblich, weil sie im Zuge der Modernisierung auch ihre Entwicklungsprozesse umstrukturiert haben. In allen Fällen profitierten die Unternehmen jedoch von dem erweiterten Standard-Funktionsumfang ihres PLM-System, insbesondere in punkto Projektmanagement, der wesentlich einfacher zu implementieren war als die kundenspezifischen Anpassungen der Vergangenheit.

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.