- IT&Production - https://www.it-production.com -

Kostentreiber Customizing

Der Weg zu passgenauer Product Lifecycle Management-Unterstützung (Teil 1)

Kostentreiber Customizing

Ließen sich die Abläufe in der Produktentwicklung vor einigen Jahren meist hinlänglich in einem Produktdatenmanagement-System abbilden, profitieren Fertigungsszenarien zunehmend von umfassender Product Lifecycle Management-Software. Doch die Systemeinführungen dieser Lösungen können teuer werden, da Funktionsanpassungen die Kosten häufig in die Höhe treiben. Positiven Einfluss auf die Kostenseite der Projekte versprechen Lösungen wie die Aras Innovator-Plattform, die auf Basis einer modellbasierten Software-Architektur Anpassungen deutlich erleichtern können.

Bild: Aras

Statistiken der letzten Jahre belegen den permanenten Wandel des Produktentwicklungsprozesses (PEP). Die Einflüsse ergeben sich aus veränderten Marktbedingungen, aus neuen Anforderungen an das Produkt und aus Kundensicht. Der Anstieg der Produktkomplexität resultiert zum einen aus einer weitaus stärkeren ‚multi market‘-fähigen Produkt-, Derivaten- und Variantenvielfalt und zum anderen aus der ständigen Zunahme elektronischer Komponenten und der zugehörigen ‚embedded software‘, also Mechatronik. Der wertmäßige Anteil an Elektronik und Software ist in den letzten Jahren ständig gestiegen und liegt zum Beispiel im Fahrzeugbau bei circa 40 Prozent. Software wird in Zukunft eine Vielzahl von weiteren Produktfunktionen ermöglichen und damit einerseits die Komplexität von Produkten erhöhen, andererseits aber auch durch Verschiebung der steigenden Varianz von Hardware auf Software die Komplexität der Produkte reduzieren. Dies setzt eine noch stärkere Einbeziehung der Softwareentwicklung in den PEP voraus.

Komplexere Arbeitsorganisationen zu erwarten

Außerdem führt die zunehmende Globalisierung der der Wertschöpfungskette sowohl innerhalb der OEMs als auch zwischen OEMs und ihren Zulieferern zu komplexeren, vernetzten Arbeitsorganisationen und Prozessen. Die Anforderung bereichsübergreifender Kommunikation zwischen allen Beteiligten über verschiedene Kulturräume und Zeitzonen gewinnen immer mehr an Bedeutung. Daraus leiten sich neue Handlungsbedarfe an Vorgehensmodellen für den interdisziplinären PEP ab. Diese basieren darauf, die Engineering-Tätigkeiten über den Produktlebenszyklus von der frühen Phase der Anforderungsaufnahme bis hin zum Recycling, über alle Disziplinen wie Mechanik, Elektrik und Elektronik, Software und Dienstleistungen sowie über die Bereichsgrenzen eines Unternehmens hinaus organisatorisch und systemtechnisch zu unterstützen.

Dabei spielen die Definition und Verfolgung verschiedener Produktkonfigurationen entlang des Lebenszyklus eine wesentliche Rolle, zum Beispiel bei den Aufgaben Freigabe-/ Änderungs- und Konfigurationsmanagement. Auf der IT-Ebene werden aktuelle Autoren-Systeme etwa für CAD, Computer Aided Manufacturing und Engineering sowie die entsprechenden Simulations- und Visualisierungstechniken eingesetzt. Product Data Management- (PDM) und Product Lifecycle Management-Lösungen (PLM [1]) können den funktionalen und administrativen Backbone für die Informationsmenge bilden, die von der ersten Idee bis zur Konstruktionsstückliste anfällt. Sie sollten in der Lage sein, die gestiegenen Anforderungen aus dem Produktentwicklungsprozess funktional und prozesstechnisch umzusetzen. Die dann folgenden produktions- und logistikbezogenen Informationen lassen sich in Produktionsplanungs- und Steuerungssystemen (PPS) verwalten.

IT-Plattform für die Produktentwicklung

PDM- und darauf aufbauende PLM-Anwendungen bieten sich als zentrale administrative IT-Lösungen für den Produktentwicklungsprozess an und sind darauf ausgelegt, einen Produkt- und Prozess-Backbone für den Produktlebenszyklus zu bilden. Die ersten PDM-Lösungen kamen Mitte der 80er-Jahre auf den Markt. Sie entstanden häufig im Umfeld von Dokumentenmanagement und CAD- sowie Enterprise Resource Planning-Systemen aus der Problematik, die zunehmende Anzahl an CAD-Dokumenten parallel mit gescannten Papierdokumenten in einer dem herkömmlichen Zeichnungsarchiv entsprechenden Form zu verwalten. Durch die stärkere Verbreitung der 3D-Arbeitstechnik ergaben sich zusätzlich eine stärkere und zwangsläufige Anbindung an die Produktstruktur und damit an das Freigabe- und Änderungswesen, die Versionsverwaltung und das Konfigurationsmanagement. Die typische Einsatzbreite von PDM war meist gekennzeichnet durch die Beschränkung auf abteilungsspezifische Entwicklungs- und Konstruktionstätigkeiten. PLM-Lösungen haben im Kern identische Funktionen wie PDM-Systeme. Durch die Ausdehnung dieser Funktionen über weite Bereiche des Produktlebenszyklus und über die verschiedenen Disziplinen ergeben sich zwangsläufig zusätzliche Anwendungen. Zum Beispiel resultieren aus der Betonung der frühen Phasen des PEP und dem ‚Model Based System Engineering‘ (MBSE) Modellelemente, die einerseits administriert und andererseits den Engineering-Prozessen unterliegen.

Dazu gehören zum Beispiel Anforderungen, Funktionen, Verhalten und logische Systemblöcke. In den der Entwicklung und Konstruktion nachgelagerten Phasen werden Funktionen wie Wartungs-, Service und Ersatzteilmanagement sowie Erweiterungen des Konfigurationsmanagements teilweise angeboten. Außerdem ist die Internet-basierende Einbindung von Kunden und Zulieferern in Form einer Engineering Collaboration-Plattform häufig Teil einer PLM-Lösung. Grundsätzlich identisch ist allen Definitionen von PLM der breitere Einsatz und der höhere Integrationsgrad über alle Phasen des Produktlebenszyklus, über die verschiedenen Disziplinen und über die Prozesskette des Supply Chain. PLM hat sich somit parallel zu den Veränderungen des Produktentstehungsprozesses entwickelt und deckt wesentliche Anforderungen aus Cross Enterprise Engineering, Managementunterstützung, Verwaltung virtueller Produktdaten – Intellectual Property – und Einbindung in die Prozesslandschaft der Unternehmen ab. Dementsprechend bezieht sich die Verwaltung der Produktstruktur nicht nur auf die eigentliche Konstruktionsphase, wenn die Konstruktionsstückliste oder E-‚Bill of Materials‘ ins Spiel kommt, sondern fängt bei der Anforderungsstruktur an und endet bei der jeweiligen Konfiguration, die entweder durch den Auslieferungszustand oder durch Maintenance, Repair und Overhaul (MRO) über die operative Phase entstanden ist.

Unterstützung für Projektmanagement und Kollaboration

Traditionelle, CAD-orientierte PDM-Ansätze konnten vielfach in einer konkurrierenden E-Business-Umgebung nicht mehr funktional Schritt halten, in der Unternehmen neue interdisziplinäre Produkte schneller, billiger und mit Unterstützung der dezentralen internen und externen Kommunikation während aller Phasen des Produktlebenszyklus entwickeln, planen, produzieren und instandhalten. Systeme ohne Funktionen für Projektmanagement und abteilungs- und unternehmensübergreifende Zusammenarbeit können dies kaum angemessen unterstützen. Das ist auch vor dem Hintergrund problematisch, dass sich eine verteilte Entwicklung, Planung, Produktion und Wartung ebenso zunehmend zum Standard bei Zulieferbetrieben entwickelt wie die Integration und der Informationsaustausch mit IT-Systemen des Kunden. Bei den meisten PLM-Systemen sind Funktionen zur Verwaltung von Supply Chain-Prozessen und des Produktlebenszyklus hingegen integraler Bestandteil der Lösung.

Je nach Product Lifecyle Management-Konzept eines Fertigungsunternehmens kann IT-Unterstützung auf verschiedenen Dimensionen sinnvoll sein. Bringen die implementierten Lösungen die erforderlichen Funktionalitäten nicht mit, führt an zeitintensiven und kostspieligen Customizings meist kein Weg vorbei. Bild: Aras

Product Lifecycle Management ‚out of the box‘ gibt es kaum

Viele Wissenschaftler sind sich darüber einig, dass es sich bei PLM-Software nicht um ein ‚Out Of The Box‘-System handeln kann, sondern immer um eine den betrieblichen Funktions- und Prozessanforderungen angepasste Lösung. In diesem Zusammenhang ist es umso bemerkenswerter, dass bei sogenannten PLM-Benchmarks meist mit großem Aufwand der Funktionsumfang des Systems getestet wird, nicht aber seine Adaptierbarkeit an die unternehmerischen Randbedingungen. Für die Anpassung beziehungsweise Adaption der Lösung wird häufig der englische Begriff ‚Customizing‘ verwendet. Den meisten PLM-Einführungen ist dabei ein Problem gemein: Auf einen Euro Investition werden zwei bis drei Euro Customizing und Implementierungskosten dazugerechnet. Nach Angaben der Managementberatung Unity AG werden nur je zwei Prozent der Einführungskosten für PLM-Systeme für Hardware ausgegeben, 25 Prozent für die Software und 71 Prozent der Kosten für das Customizing. Davon entfallen statistisch circa 75 Prozent auf funktionale Erweiterungen und 13 Prozent auf Integrationen und Schnittstellen. Die häufigsten Faktoren des Customizing betreffen:

Erweiterungen auf funktionaler Ebene

Bei einer strategischen PLM-Gesamtplanung lassen sich die Anforderungen an ein PLM-System recht präzise ermitteln. Sofern die erforderlichen Funktionen nicht im Basisumfang eines PLM-Systems vorhanden sind, verläuft die Integration über meist kostspielige Customizing-Maßnahmen. Dafür muss etwa das Datenmodell der Lösung durch Erzeugung neuer Klassen ergänzt werden, zum Beispiel bei Anforderungen, Funktionen, Verhalten und in den Bereichen Requirement, Function, Behavior und Logical Elements (MBSE). Andere Anwendungen benötigen eine Attributerweiterung existierender Objektklassen. Dies kann zum Beispiel notwendig werden bei der Integration von CAD zu CAM beziehungsweise zur ‚digitalen Fabrik‘, wenn die PLM-Stammdaten durch fertigungstechnische und montagerelevante Informationen angereichert werden. Ein anderer Fall der Attributerweiterung der existierenden PLM-Stammdaten ist die Anbindung von CAD und PLM an die internationalen Ökologie-Datenbanken, um ein Lifecycle Assessment (LCA) durchzuführen. Die Erweiterungen führen meist auch zu neuen Methoden, die möglichst einfach zu programmieren und in das PLM-System integrierbar sein sollten. Zudem müssen adaptierte und erweiterte Klassen, Attribute und Methoden bei Upgrades des Basissystems erkannt und mit der aktualisierten Anwendung wieder verbunden werden.

Erweiterungen auf prozessualer Ebene

Bei der Prozessgestaltung im Umfeld von PLM sind viele Kriterien zu beachten und im Vorfeld zu definieren, damit bei der technischen Umsetzung eine eindeutige Lösung implementiert werden kann. Dazu zählen die Fragen, wie sich das Verhältnis vom PLM-System zum Produktionsplanungssystem (PPS) in Bezug auf die Aufteilung der Daten und Prozesse verhalten und wie ein durchgängiger Freigabe-, Änderungs- und Konfigurationsprozess gestaltet werden kann. Wenn verschiedene Produktstrukturen existieren – zum Beispiel im Elektro-BOM und Mechanik-BOM – sind Differenzanalysen möglich und besteht ein Mapping zwischen verschiedenen Strukturen, um durchgängige Freigabe- und Änderungsprozesse sicherzustellen? Außerdem gilt es zu klären, wie sich Integrationsprozesse der Autorensysteme auf der Architekturebene abbilden lassen und welche Rolle zum Beispiel TDM-Systeme übernehmen sollen. Darüber hinaus ist es immer wieder eine betriebliche Herausforderung, die Datenmodellerweiterungen in die existierende Prozesslandschaft zu integrieren. Dabei gilt es auch zu beachten, welche Möglichkeiten der Prozessgestaltung das PLM-System überhaupt liefert in Hinblick auf Verzweigungen, Merge, manuelle Eingriffe und Entscheidungsfindung.

Der zweite Teil [2] des Artikels adressiert weitere Herausforderungen bei Customizing-Maßnahmen. Im Mittelpunkt stehen aber auch Ansätze, wie sich durch den Rückgriff auf PLM-Lösungen mit modellbasierter Software-Architektur Systemanpassungen vergleichsweise effizient vornehmen lassen.