MetaCre8® ED – Engineering Design. Eine Methode zur Modernisierung der F&E Tool Chain.

Abstract

Engineering basiert auf einem dichten Netz aus Daten, die in vielfacher und vielfältiger Weise system-, disziplin-, bereichs- und standortübergreifend miteinander in Beziehung stehen. Die F&E¹Unternehmensbereich Forschung und Entwicklung Tool Chain als Dreh- und Angelpunkt für produktbezogene Daten muss so gestaltet werden, dass die Entwicklungsprozesse bestmöglich unterstützt werden. Für die Umsetzung von Entwicklungsstrategien wie Baukasten und Model-based Systems Engineering muss die F&E Tool Chain entsprechend angepasst werden. Um dies zu erreichen, sind Strukturierungsprinzipien nötig, mit deren Hilfe die komplexe Gesamtaufgabe in handhabbare Teilprobleme zerlegt wird. Mit dem MetaCre8^® Engineering Framework wird ein Gliederungsschema vorgestellt, das datenbezogene F&E Artefakte und Prozesse strukturiert. Um die dreidimensionale Struktur des Frameworks operativ anwendbar zu machen, wird mit MetaCre8^® ED – Engineering Design eine Methode vorgestellt, mit der cross-funktionale Teams die F&E Tool Chain mit Hilfe von Templates erfassen, analysieren und gestalten können. Beide Perspektiven, Framework sowie die operative Anwendung, werden in diesem Whitepaper adressiert.

Einleitung

Mit der zunehmenden Vernetzung von Maschinen und Anlagen steigen die Anforderungen an die Engineering Landschaft in Unternehmen. Besonders der Maschinenbau ist geprägt von einer Kombination aus vordefinierten Konfigurationen (Configure-to-Order, CTO) in Verbindung mit kundenspezifischer Entwicklung (Engineer-to-Order, ETO). Da der CTO- Anteil dominiert, spricht man auch von CTO+, wobei das Plus den relativ geringen ETO-Anteil symbolisiert.

Als weitere Differenzierung innerhalb des ETO-Anteils kann unterschieden werden, ob eine geforderte Sonderlösung in der Vergangenheit bereits realisiert wurde. Ist dies der Fall, nutzen wir die Bezeichnung CTO++, solange die bestehenden Lösungen noch nicht in die Standardkonfiguration aufgenommen wurden.

Somit existieren insbesondere im Werkzeugmaschinenbau drei Arten der Auftragsabwicklung auf der Maschineneben: CTO, CTO+ und CTO++, wobei sich CTO und CTO+ wesentlich voneinander unterscheiden. Diese Prozessvarianz allein führt bereits zu einer inhärent hohen Prozesskomplexität. Aufgrund der neuen Möglichkeiten und Bedarfe im Umfeld von Industrie 4.0 bündeln Unternehmen Ihre Aktivitäten zur Digitalisierung häufig in einem neuen Funktionsbereich. Dieser stellt zusätzlich interne Anforderungen an die klassischen Entwicklungsbereiche, insbesondere an die Steuerungstechnik. In den 10er Jahren wurden vor diesem Hintergrund neue Technologien, Systeme und Komponenten zur Herstellung der Konnektivität eingeführt, wie beispielsweise OPC UA und Edge Devices. Während die Komplexität der Entwicklung durch den erweiterten Funktionsumfang weiter steigt, verändert sich die Art und Weise, wie entwickelt wird, in verhältnismäßig kleinen Schritten.

Die Entwicklungsmethodik und die Systemlandschaft gehen jedoch Hand- in Hand mit dem Produkt, das darin abgebildet wird. Eine einfache Systemlandschaft kann auch nur einfache Produkte und Prozesse effizient unterstützen. Für hochkomplexe Produkte und Prozesse ist hingegen eine entsprechend performante Systemlandschaft mit spezifischen Funktionen erforderlich. Erst die Adaption der Systemlandschaft an das Unternehmen, die Implementierung von produktbezogenen Strukturen, die Institutionalisierung der Prozesse sowie die Befähigung der Mitarbeiter bilden die Basis zur Komplexitätsbeherrschung. Der dadurch erreichte neue stabile Betriebspunkt ermöglicht deutlich reduzierte Time-to-Market, kürzere Lieferzeiten, bessere Produkte und geringere Kosten.

Neben den direkten Auswirkungen auf die F&E-Effizienz kann das Engineering auch als Enabler für die zukünftige KI-Fähigkeit betrachtet werden. Dies bezieht sich sowohl auf die Maschine als Produkt als auch auf das Unternehmen, das die Maschinen entwickelt und herstellt. Grundlage hierfür ist die Nutzung strukturierter Entwicklungsdaten, um einen semantischen Kontext, beispielsweise für Sensordaten oder Komponenten, zu erzeugen, den KI-basierte Algorithmen verarbeiten können.

Investitionen ins Engineering sind daher mittel- und langfristig von strategischer Bedeutung. Unternehmen, die dies erkannt haben, stehen vor der Herausforderung, wie sie die Transformation gestalten sollen.

Aktuell lassen sich im Engineering vier wesentliche Paradigmen identifizieren: Die Baukasten-Strategie, das Systems Engineering, die Digitale Transformation²einschließlich KI und Agile. Unternehmen müssen ein Transformationsziel entwickeln, das sich an diesen Dimensionen ausrichtet. Da die Themenfelder erhebliche gegenseitige Abhängigkeiten aufweisen, sollten sie gemeinsam betrachtet werden. Die Baukastenstrategie bildet hierbei die Basis und erfordert erste Umsetzungsschritte der Digitalisierung. Wesentliche Vorteile sind Skaleneffekte und die Vermeidung redundanter Entwicklungsarbeiten. Darauf aufbauend hilft das modellbasierte Systems Engineering (MBSE), neue Funktionen in kürzester Zeit zu realisieren, indem Fehler vermieden werden und Automatismen wie Code-Generierung den Programmieraufwand deutlich verringern. Auch das MBSE erfordert entsprechende Umsetzungsschritte der Digitalisierung. Baukasten und MBSE nutzen standardisierte Produkt- und Funktionsstrukturen, Architektur und Modulschnittstellen. Erst, wenn die Komplexität durch klare Strukturen und unterstützende Systeme beherrscht wird, ist ein sicheres Umfeld vorhanden, in dem es leichter fällt, Kontrolle abzugeben und Mikro-Management zu vermeiden. In einem solchen Umfeld kann verteilten Teams im Sinne von Agile mehr Eigenverantwortung übertragen werden, was Führungskräfte entlasten und ungenutzte Potenziale freisetzen kann.

Die Herausforderungen einer solchen Transformation sind hoch. Als eine der jüngsten revolutionären Veränderungen der Industrie kann die Einführung von Lean Production in den 90er- und Nullerjahren als Vergleich herangezogen werden. Hierbei wurden einige über Jahrzehnte verankerte Praktiken und Denkweisen grundlegend verändert, beispielsweise durch die Umstellung auf getaktete Fließmontage, die Fertigung kleiner Lose oder den massiven Abbau von Sicherheitsbeständen zwischen den Arbeitsschritten. Diese Transformation wurde aktiv von Vorständen getrieben und hat alle Ebenen der Produktion einbezogen³vgl. Womack, J. P. und Jones, D. T. (2013).

Ein essentieller Schritt für die Einführung von Lean Production ist die visuelle Darstellung des Ist- und des Soll-Zustands. Hierfür wurde das Wertstrom-Design entwickelt, mit dessen Hilfe der Fluss von Material und Information eines Produktes entlang der Wertschöpfung analysiert und gestaltet wird⁴Rother, M. und Shook, J., (1999).

Ähnlich wie das Wertstrom-Design die Einführung von Lean unterstützt, ist auch für die Verschlankung und Neuausrichtung der F&E Tool Chain ein grafisches Hilfsmittel für den interaktiven Einsatz in Workshops essentiell. Die in diesem Whitepaper vorgestellte Methode MetaCre8^® ED – Engineering Design wurde für diesen Zweck entwickelt.

Zunächst wird der zugrundeliegende Gedanke zur Strukturierung des Engineerings vorgestellt und das Framework präsentiert.

Darauf aufbauen werden Kriterien für die Bewertung von Lösungsalternativen diskutiert.

Typische Muster heutiger Engineering-Landschaften werden skizziert und bewertet.

Im Anschluss wird die Methode MetaCre8^® ED – Engineering Design detailliert vorgestellt, gefolgt von einem Ausblick.

Das MetaCre8^® Engineering Framework

Übersicht

Das MetaCre8^® Engineering Framework ist ein Grobmodell der datentechnischen Abläufe im Bereich F&E unter Berücksichtigung angrenzender Funktionsbereiche.

Das Framework ist ein dreidimensionales Gliederungs-Schema das die wesentlichen disziplinübergreifenden Artefakte sowie die technischen Prozesse zur Verarbeitung dieser Artefakte ordnet, s. Abbildung 1.

Durch die Einführung des Frameworks im Unternehmen entsteht ein gemeinsames mentales Modell, was dazu führt, dass Diskussionen zielgerichtet ablaufen und weniger aneinander vorbeigeredet wird. Dadurch wird insbesondere die cross-funktionale und interdisziplinäre Zusammenarbeit unterstützt.

Im Folgenden werden die drei Dimensionen des Frameworks näher erläutert.

Die Achse „Konfigurations-Bereich“

An der Entwicklung von Maschinen- und Anlagen sind zahlreiche heterogene Systeme beteiligt, die sich auf Teilbereiche im Engineering spezialisiert haben. Überall, wo modulare und/oder variantenreiche Strukturen mit Produktbezug existieren, müssen diese im Kontext einer Baukastenstruktur betrachtet werden. Gedanklich durchläuft man den Entwicklungs-Workflow und betrachtet dabei die jeweils eingesetzten Werkzeuge für CPQ, Anforderungsmanagement, MBSE, PLM, MCAD, ECAD, Software Entwicklung, Simulation, Test, Produktion, Steuerungs-Parametrierung, Qualitäts-Management, Felddatenverarbeitung etc.. Gesammelt werden Themenfelder und die darin eingesetzten Werkzeug- oder System-Kategorien im Sinne von Engineering-Funktionen. Diese werden auf der Achse Konfigurations-Bereich aufgetragen.

Die Achse „Konfigurations-Schritt“

Die Dimension Konfigurations-Schritt strukturiert den sukzessiven Aufbau von Baukastenstrukturen. Hierbei wird zwischen auftragsneutralen und auftragsspezifischen Schritten unterschieden, s. Tabelle 1.

Auftragsneutrale Schritte

Entscheidend für die Verankerung einer Baukastenstrategie sind die Aspekte Mehrfachverwendung und Varianz. Beide Aspekte können in Betrachtungseinheiten unterschiedlicher Granularität auftreten: Die Granularität gliedert sich in Komponente, Modul, Produktfamilie und Produkt.

Beispiele für Komponenten sind MCAD-Teile und -Baugruppen oder ECAD-Makros mit Wertesätze.

Aus diesen Komponenten entstehen Module, die größere physische oder funktionale Einheiten darstellen, für die i.d.R. auch ein Modulverantwortlicher zuständig ist. Diese Module werden von einer oder mehreren Produktfamilien verwendet. Eine Produktfamilie wird hierbei als Summe hinreichend ähnlicher Produkte betrachtet, die auf einer gemeinsamen Plattform basieren und sich entwicklungsseitig sinnvoll bündeln lassen⁸vgl. Meyer, M. H., Utterback, J. M. (1993), S. 30. Artefakte auf Ebene der Produktfamilie sind beispielsweise Maximalprojekte für ECAD, Automatisierungsprojekte für die SPS Entwicklungsumgebung oder das Master-Part im MCAD.

Die Prozent-Angabe symbolisieren hierbei den Konfigurationsraum. 100% bedeutet keine Varianz bzw. eine eindeutige Merkmalsbewertung, die zu einer voll definierten Ausprägung führt. 150% bedeutet eine Maximalstruktur, die durch Merkmale und Merkmalsausprägungen einen definierten Konfigurationsraum darstellt. Mit 120% wird eine Teilkonfiguration beschrieben, bei der einzelne für das Produkt charakteristische Merkmale bewertet wurden.

Bei der Konfiguration kann weiterhin zwischen additiver und subtraktiver Variantenkonfiguration unterschieden werden. Bei der additiven Variantenkonfiguration wird, entsprechend den bewerteten Merkmalen eine 100% Ausprägung aus Fragmenten automatisiert zusammengesetzt. Bei der subtraktive Variantenkonfiguration wird zunächst eine Maximalstruktur definiert. Die nicht benötigten Elemente werden entsprechend der Merkmalsbewertung gefiltert, so dass eine 100% Ausprägung erscheint.

Aus einer Produktfamilie kann somit subtraktiv oder additiv eine 120% Struktur oder eine 100% Struktur erzeugt werden. Die 120% Struktur ist hilfreich, wenn intern die Produkte z.B. in Maschinentypen nach Format, Features oder Preissgemente unterschieden werden, die jeweils einen eigenen Einstieg in den Konfigurationsprozess bieten, entwicklungsseitig jedoch auf einer gemeinsamen Architektur basieren.

Auftragsspezifische Schritte

Die Unterscheidung zwischen auftragsneutralen und auftragsspezifischen Elementen erfolgt anhand einer gedanklichen Trennebene. Zu den auftragsspezifischen Elementen zählen die Auftragsarten CTO, CTO+ und CTO++. Letztere bezeichnet einen ETO-Anteil auf Basis vergangener Aufträge, die noch nicht in den Standard überführt wurden.

Die Achse „Konfigurations-Ebene“

Die Dimension Konfigurations-Ebene beschreibt, wie die Informationen zur Variantenkonfiguration zwischen der Vertriebskonfiguration und den variantenbehafteten Engineering-Daten fließen.

Die Vertriebskonfiguration entspricht der äußeren Varianz, definiert durch einen Konfigurationsraum aus Merkmalen, Merkmalsausprägungen und deren möglicher Kombinatorik.

Analog dazu beschreiben Technische Merkmale die innere Varianz.

Das Konfigurationswissen verknüpft die äußere mit der inneren Varianz, so dass sich für eine gewählte Vertriebskonfiguration automatisch eine technische Lösung herleiten lässt.

Die beteiligten Engineering- bzw. IT-Systeme sollten Möglichkeiten zur Variantenkonfiguration bereitstellen (beispielsweise in Form Tool-interner oder Tool-naher Konfiguratoren). Die Konfigurationsparameter dieser disziplinspezifischen Konfiguratoren müssen nun durch ein Merkmals-Mapping mit den jeweiligen technischen Merkmalen verknüpft werden, um die Kette vom Vertrieb bis zu den Engineering-Daten zu schließen.

Das Zusammenspiel der Elemente im Framework wird anhand von Abbildung 2 erläutert. Ein Baukastenmodul (a) wird hierbei als Bestandteil ein oder mehrere Produktfamilien konzipiert. Während der Entwicklung werden Tool-interne oder Tool-nahe Konfiguratoren eingesetzt, um die Varianz innerhalb der Engineering Daten zu steuern. Für die Konfigurationsparameter wird ein Mapping (b) auf technische Merkmale definiert, das in ein Gesamt-Mapping für die Produktfamilie einfließt. Ebenso werden die technischen Merkmale im Kontext der Produktfamilie gebündelt und stehen so für die Definition des Konfigurationswissens (c) zur Verfügung. Im Auftragsfall wird die Vertriebskonfiguration des vordefinierten Konfigurationsraums genutzt, um das Produkt vollständig zu definieren (e). Durch das Konfigurationswissen und das Mapping werden die Engineering-Daten in der richtigen Variante gezogen (f). Im Fall von CTO+ wird zusätzlich eine Spezifikation angehängt, weil der vordefinierte Konfigurationsraum die Kundenanforderungen nicht vollständig abdeckt (g). Auf Ebene der Engineering Daten müssen dann z.B. auf Basis der am besten passenden Konfiguration Anpassungen vorgenommen werden. Im Fall CTO++ lassen sich diese Anpassungen aus vergangenen CTO+ Aufträgen wiederverwenden (h).

Die Grundelemente

Elemente, die im Framework angeordnet werden, sind Knoten sowie Kanten zwischen zwei Knoten. Die Knoten repräsentieren beliebige Artefakte im Engineering, während die Kanten Prozesse darstellen, die den Übergang von einem Artefakt ins andere oder eine allgemeine Beziehung zwischen Artefakten darstellen.

Knoten

Artefakte sind beispielsweise mechanischen Baugruppen (MCAD), Makros (ECAD), Funktionsbausteine (SPS), Teilmodelle (OPC UA), Stücklisten (BOM), Projekte (SPS Engineering), Merkmalsbewertung (Kundenauftrag) usw..

Artefakte werden hierbei als allgemeine informationstechnische Strukturen betrachtet. Ebenso werden Dokumente bzw. Dateien, die Träger von Informationen sind, als Artefakt betrachtet.

Artefakte können im Rahmen der Konfiguration kopiert bzw. ausgeleitet werden. Ebenso können Artefakte aus anderen Artefakten zusammengesetzt werden.

Bei weit verteilten Strukturen können Artefakt-Referenzen genutzt werden, um die Beziehung zu anderen bereits vorhandenen Artefakten zu beschreiben. In manchen Situationen verbessert die Verwendung von Referenzen die Lesbarkeit (z.B. für die Beschreibung der auftragsspezifischen Abläufe, die auf Elemente der auftragsneutralen Bereiche zugreifen).

Artefakte könne auch ineinander geschachtelt werden, um die Übersicht zu erhöhen oder um hierarchische Beziehungen, wie beispielsweise die Projekt-Datei und die darin enthaltenen Strukturen, darzustellen.

Kanten

Kanten werden in Flüsse und Assoziationen unterteilt. Zur groben Erfassung der Engineering Tool Chain, sind diese beiden Kategorien zunächst ausreichend. Flüsse symbolisieren hierbei einen zeitlichen Vorgang wie beispielsweise das Zusammensetzen von Projekten aus Modulen oder den Export und Import von Austausch-Dateien. Assoziationen dagegen repräsentieren eher statische Beziehung, deren Entstehungsprozess für die Analyse des Engineerings eine untergeordnete Rolle spielt. Der Prozess kann bei Bedarf in Konstruktionsrichtlinien detailliert beschrieben werden. Beispiele für Assoziationen sind die Kanten zwischen Merkmal und Merkmalsausprägung, zwischen ERP-Material und Arbeitsplan, zwischen SPS-Datenbaustein und OPC UA Teilmodell, zwischen MCAD-Baugruppe und Master Model.

Kriterien für die Bewertung von Lösungsalternativen

Durch die zum Teil überlappenden Funktionsumfänge von Tool-Herstellern ergibt sich ein immens großer Lösungsraum für die zukünftige Tool Chain. Daher ist es wichtig, grundlegende Muster (Design Patterns) herauszuarbeiten, um die Entscheidungsfindung zu beschleunigen. Für diese Muster, aber auch für Einzelfall-Entscheidungen, ist eine möglichst objektive Bewertungsbasis erforderlich. Tabelle 2 zeigt hierfür eine Auflistung der Kategorien Kosten und Mitarbeiterzufriedenheit. Engineering- bzw. IT-Tools müssen den natürlichen Arbeitsfluss der Benutzer hinreichend unterstützen. Ist dies nicht gegeben, beispielsweise durch lange Ladezeiten, fehlende Automatisierung oder starke Arbeitsteilung mit Abhängigkeit von Administratoren oder Key-Usern entsteht Frust und die Innovationskraft kann sich nicht voll entfalten. Gerade bei komplexen Aufgaben wie dem Aufbau und Testen von Varianten in Engineering Systemen kann eine lange Reaktionszeit zu deutlichen Einbußen in der geistigen Effizienz führen, weil der Gedankenstrom durch die künstliche Wartezeit abreißt⁹Vgl. Miller, 1968, S. 268

Beispiele für Architekturmuster

Im folgenden werden alternative Architekturmuster als Extrembeispiele gegenübergestellt. In der Praxis findet man häufig Mischformen.

Disziplinspezifische Konfiguratoren vs. zentrales Konfigurationswissen

Durch die zunehmende Ausweitung der Produktportfolios vieler Maschinenbau-Unternehmen und dem Fehlen einer übergreifenden Konfigurationsstrategie haben die Abteilungen oder Gruppen jeweils disziplinspezifische Konfigurationslösungen eingeführt. Hierbei sind nicht selten hochkomplexe Konfigurations-Silos entstanden, die – übergreifend betrachtet – im großen Umfang redundantes Konfigurationswissen enthalten. Ein Beispiel ist die Variantenkonfiguration von Fertigungsstücklisten im ERP. Die hierfür erforderlichen Konfigurationsregeln werden mitunter für die Parametrierung der Steuerungs-Software, für die Konfiguration von Schaltplan-Unterlagen sowie die Konfiguration der technischen Dokumentation in unterschiedlichen Systemen von unterschiedlichen Personen implementiert.

Als kleinster gemeinsamer Nenner wird beispielsweise die Vertriebskonfiguration mit ihren bewerteten Merkmalen abgegriffen, s. Abbildung 3. Das Mapping erfolgt hierbei bereits auf Ebene der Vertriebsparameter, gefolgt von redundantem Konfigurationswissen.

Alternativ können sich Unternehmen für ein einziges System zur Verarbeitung des tiefen Konfigurationswissen entscheiden (beispielsweise das ERP-, das CPQ-System oder ein anderes System), s. Abbildung 4. Dieses verknüpft Vertriebsmerkmale und technische Merkmale über ein Regelwerk. Die technischen Merkmale werden dann auf die Konfigurationsmerkmale der jeweiligen Disziplin gemappt, beispielsweise zur Steuerung von Varianten und Optionen in der Elektrokonstruktion. Das Mapping kann hierbei in einer Datei oder einer geeigneten Datenquelle hinterlegt werden. Diese Datenquelle wird dann während der Auftragserzeugung gemeinsam mit den Werten der technischen Merkmale (plus ausgewählte Vertriebsmerkmale) verwendet, um das spezielle Format der ECAD-spezifischen Konfigurations-Schalter zu erzeugen. Die erzeugte Datenstruktur wird dann genutzt, um im ECAD-Produktfamilienprojekt automatisiert die benötigten Merkmalswerte zu setzen. Dieser Vorgang erfolgt parallel in mehreren Fachdisziplinen (z.B. ERP). Für unterschiedliche Szenarien (CTO, CTO+) können jeweils mehr oder weniger viele Konfigurationsbereiche beteiligt sein. Beispielsweise werden beim CTO zwar die ECAD-Unterlagen, MBOMs und Arbeitspläne konfiguriert, nicht aber MCAD oder Entwicklungs-Stücklisten, weil beim CTO keine auftragsspezifische Änderung am Produkt erfolgt.

Bewertung der Ansätze

Aufgrund der hohen Spezialisierung und der hohen Komplexität ist es bei Ansatz 1 deutlich aufwendiger, Mitarbeiter-Redundanz aufzubauen. Fehlt die Redundanz, können Ausfälle zu gefährlichen Engpässen führen. Weiterhin bilden die vielen redundanten Daten ein großes Fehlerpotenzial aufgrund von Inkonsistenzen, da es nur schwer durchzuhalten ist, alle Konfigurationsdaten stets zeitgleich zu aktualisieren. Dies hemmt eine zügige stabile Umsetzung von Änderungen, was sich negativ auf Time-to-Market auswirkt. Komplexe Konfiguratoren führen zu hoher Arbeitsteilung zwischen Administratoren und Anwendern. Dadurch wird das Verständnis für Varianz nicht ausreichend kultiviert, so dass sich ein eigenverantwortlicher Umgang mit Varianz nur schwer in der Breite einfordern lässt. Genau diese organisatorische Kompetenz ist aber erforderlich, um eine Baukastenstrategie erfolgreich auszurollen und Engpässe zu vermeiden.

Ansatz 2 verlagert das Konfigurationswissen redundanzfrei an eine zentrale Stelle. Hierbei kommen in den Fachabteilungen auf Datenebene ebenfalls Konfiguratoren zum Einsatz. Die zu gestaltenden 150% Module sind jedoch so aufgebaut, dass die Merkmale ausschließlich den technischen Lösungsraum ohne Restriktionen beschreiben, Dieser Ansatz hat zwei wesentlichen Vorteile. Erstens, ermöglicht er, dass Entwickler die Variantenkonfiguration selbst administrieren (z.B. als Modulverantwortlicher). Dadurch werden Engpässe vermieden und die Entwickler können unabhängiger agieren. Sie identifizieren sich mit der Baukasten-Strategie und übernehmen Eigenverantwortung. Gleichzeitig steigt die Flexibilität für den Einsatz der Module, wenn Konfigurationsregeln erst auf der Ebene Konfigurationswissen in der jeweiligen Produktfamilie definiert werden. Für einfache dezentrale Konfiguratoren sind die Lizenzkosten zudem i.d.R. geringer als für Systeme zur Verwaltung komplexer Konfigurationsregeln.

Konzernstückliste vs. Produktstruktur/EBOM/MBOM

Die Produktstruktur ist das hierarchische Herunterbrechen eines Produktes in eine baumartige Struktur¹⁰Svensson, D. und Malmqvist, J. (2000), S.2. Der Begriff Produktstruktur kann daher im weitesten Sinn genutzt werden, um den hierarchischen Aufbau und die Systemgrenzen eines Produkts zu definieren. Im engeren Sinn beschreibt er Datenstrukturen im PLM-Umfeld, die diese Zerlegung repräsentieren.

Die allgemeine Produktstruktur erfüllt konkrete Zwecke, die sich je nach Bereich unterscheiden. Die Konstruktion hat andere Anforderungen an die Produktstruktur als die Produktion. Eine Trennung in Sichten oder separate Strukturen ist daher naheliegend, bedingt jedoch systemseitige und organisatorische Maßnahmen, um die Datenkonsistenz sicherzustellen.

Um Hürden zur Lösung dieser Herausforderung zu umgehen, setzen viele mittelständische Unternehmen auf eine gemeinsame Struktur als Kompromiss.

Bezogen auf Stücklisten folgt daraus: Konstruktion und Produktion nutzen ein und dieselbe Stückliste, die von der Entwicklung verwaltet wird. Die Produktion hat nur noch lesend Zugriff. Strukturelle Anpassungen führt die Entwicklung als Dienstleistung für die Produktion durch.

Abbildung 5 zeigt dieses Konzept stark vereinfacht. Links sind exemplarisch die Konfigurationsbereiche MCAD und PLM dargestellt. Der PLM-Bereich wird hier als schlanke Zwischenschicht im Sinne eines PDM-Systems betrachtet. Die Konstrukteure pflegen die Master-BOM (c), die von der Produktion nur lesend genutzt wird. Komponenten werden von Modulen referenziert, und Module werden schließlich von Produkten referenziert (d). Die Produktion erstellt die werkspezifischen Maximal-Arbeitspläne. Im Auftragsfall werden diese aktiviert, um das Produkt herzustellen (e).

Die jeweils verwendeten Strukturierungen sind durch Kürzel links dargestellt (a). Ph bezeichnet die rein physische Struktur¹¹Es wird bewußt auf den Begriff „funktionale Baugruppe“ verzichtet, um Verwechslung mit der Funktionsstruktur zu vermeiden., Pr die Prozess-orientierte Struktur. Die Master-BOM muss hierbei die Anforderungen der Produktion im Hinblick auf den hierarchischen Aufbau befolgen. Der Konflikt zwischen Konstruktion und Produktion wird klar deutlich. Entweder die Konsistenz von MCAD und ERP-Material geht verloren, oder der Konstrukteur muss die Baugruppen entsprechend der Produktions-Logistik aufbauen.

Alternativ zur Konzernstückliste kann eine Entkopplung der Stücklistenstrukturen in EBOM und MBOM erfolgen. Abbildung 6 zeigt exemplarisch und stark vereinfacht dieses Konzept in Verbindung mit einer Produktstruktur.

In den Konfigurationsbereichen MCAD und PLM wird hierbei das Produkt durchgängig nach Entwicklungskriterien strukturiert. Beim Übergang von PLM nach ERP erfolgt die Übersetzung in die montageoptimierte MBOM (b). Dieser Übersetzungsschritt kann IT-technisch im PLM oder im ERP-System erfolgen. Die Produktstruktur kann neben Materialnummern auch leichtgewichtige MCAD-Daten referenzieren. Über Transformationsmatrizen wird die räumliche Position berechnet (c). Die Produktstruktur eines Submoduls wird beispielsweise mit eindeutigen Baugruppen als Maximalstruktur definiert. Der Produktstrukturknoten auf Modulebene wird aus diesen Submodulen zusammengesetzt. Der Strukturknoten des Moduls fließt wiederum in die Produktstruktur unter der Spalte Produktfamilie (d) ein. Von dort beginnt beispielsweise die Synchronisation in ein 120% EBOM (e). Diese wird dann durch die Produktion in eine 120% MBOM überführt, wobei produktionsbedingte Umstrukturierungen möglich sind.

Für dieses Konzept existieren zahlreiche Varianten, insbesondere in Hinblick auf CTO+ und CTO++. Aufgrund der hohen Komplexität durch die Prozessvarianz in Verbindung mit unterschiedlichen beteiligten Systemen ist eine sorgfältige Analyse und Bewertung von alternativen Architekturen für die F&E Tool Chain ein Muss.

Bewertung der Ansätze

Mit der Trennung in EBOM und MBOM erreicht man prinzipiell eine höhere Effizienz und Zufriedenheit innerhalb der Fachbereiche, weil jeder Bereich mit den für ihn optimalen Strukturen arbeiten kann und Änderungen dennoch kontrolliert ablaufen. Die Produktion kann Prozess-Optimierungen durchführen, ohne dass die Entwicklung die Stücklistenstruktur regelmäßig anpassen muss. Zudem lassen sich Änderungszeitpunkte je Werk feingranular steuern.

Diese Vorteile gehen jedoch einher mit einer erhöhten Systemkomplexität und zusätzlichen speziellen Werkzeugen. Zudem wird das Aufgabenprofile der Produktion/Arbeitsvorbereitung um Aufgaben wie die Umstrukturierung von Stücklisten und die Synchronisation von Änderungen aus den EBOMs in die MBOMs erweitert. Dies erfordert entsprechenden Kapazitätsaufbau einschließlich Backups sowie den Know-How-Aufbau durch Schulungen und Richtlinien.

300% Projekte vs. Modul-Mehrfachverwendung

Bei 300% Strukturen werden innerhalb einzelner Konfigurationsbereiche mehrer Produkte zu einem Maximalprojekt zusammengestellt, die über den Umfang einer Produktfamilie hinausgehen.

Der Grund dafür liegt meist in einer unzureichenden Modularisierung und/oder fehlender Systemunterstützung. Ohne eine separate, eigenständige Verwaltung von Modulen entstehen zwangsläufig redundante Daten, wenn ein Modul von zwei Produktfamilien genutzt wird. In diesem Fall müssen die Daten des Moduls von einem Projekt ins andere kopiert werden, wenn das Modul nur im 150% Projekt verwaltet wird. Um dies zu verhindern, entscheiden sich Administratoren zum Teil dafür, die Produktfamilien zusammenzulegen. Die Redundanzfreiheit wird hierbei durch einen beträchtlichen Anstieg der Komplexität erkauft. Zudem wird ein durchgängiges Release-Management erschwert, weil durch die Zusammenfassung der Projekte eine separate Versionierung und Freigabe mit erhöhtem Aufwand verbunden ist. Das Testen derart umfangreicher Projekte ist zeitintensiv. Die gesamte Handhabung von 300% Projekten ist träge und die Einarbeitungszeit sehr hoch. Zudem entsteht ein Single-Point-of-Failure.

Das Idealbild sieht vor, dass Produktfamilie mit einheitlichem Scope über alle Disziplinen angelegt werden, und die Werkzeuge so erweitert werden (ggf. durch Add-Ons), dass eine getrennte Modulverwaltung mit 150% Strukturen möglich ist, bei der auch eine Mehrfachverwendung von Modulen in unterschiedlichen Produktfamilien unterstützt wird.

MetaCre8^® ED – Engineering Design

MetaCre8^® ED Template

Ein dreidimensionales Prozessmodell ist für den praktischen Einsatz ungeeignet. Um dennoch den Charakter des Frameworks zu erhalten, wird die Dimension Konfigurations-Ebene schräg auf die 2D Ebene projiziert und komprimiert. Dadurch entsteht ein 2D Template, das sich mit konkreten Artefakten und Prozesslinien befüllen lässt, s. Abbildung 7.

Felder

Je nach Unternehmen oder je nach Fokus können sich die Felder auf der Achse Konfigurations-Bereich unterscheiden. Dieser Teil ist daher individualisierbar. Auf der Achse Betrachtungsumfang sind die Schritte Produkt, CTO+ und CTO++ optional.

Bei offenen Baukästen, wie z.B. Fertigungs-Systemen, kann CTO auch im Sinne einer additiven Zusammensetzung von konfigurierbaren CTO-Produkten verstanden werden. Bei großem Umfang kundenspezifischer Entwicklungen sollte CTO durch ETO ersetzt werden.

Die Felder für Mapping und Konfigurationswissen werden während der Modellierung weiter untergliedert, je nachdem, wie viele Konfiguratoren mit eigenem Konfigurationswissen oder wie viele Mappings im Einsatz sind.

MetaCre8^® ED Pläne

Ein Ergebnis der Arbeit mit MetaCre8^® ED ist in Abbildung 8 dargestellt. Das MetaCre8^® ED Template (a) enthält im oberen Teil die Felder für die Konfigurations-Ebenen (b) und darunter die Felder für die Engineering-Daten (c). Beides erstreckt sich über die Konfigurationsschritte (d).

Durch das interaktive Befüllung des Templates im Team entstehen die MetaCre8^® ED Pläne für die IST-Situation, die Ziel-Situation und für Zwischenziele (e). Über Erweiterungs-Pläne lassen sich flexibel zusätzliche Konfigurationsbereiche integrieren.

Ausblick

Digitalisierung, Systems Engineering, Baukasten-Strategie und Agile haben das Potential, die Wettbewerbsfähigkeit von Unternehmen gravierend zu verändern. Die Vernetzung im Kontext von Industrie 4.0 sowie die Bereitstellung industrieller KI bilden dabei vermehrt neue zusätzliche funktionale Anforderungen an die Maschinenentwicklung.

Über Jahrzehnte haben Unternehmen im Maschinenbau ihre F&E Tool Chain und Methoden inkrementell weiterentwickelt. Innovationsführer im Produkt, Nachzügler im Prozess, so könnte man die Einstellung vieler Unternehmen des Maschinen- und Anlagenbaus beschreiben. Dabei wird übersehen, dass IT-bezogene Produktinnovationen vermehrt eine moderne F&E Tool Chain voraussetzen. Wer heute ins Engineering investiert, wird industrielle KI zukünftig (effizient) bereitstellen können. Denn die automatisierte Verarbeitung von Daten, und insbesondere die autonome Entscheidungsfindung, benötigt eindeutige Strukturen und semantischen Kontext, um deterministisches Antwortverhalten sicherzustellen und Daten direkt zuordnen zu können.

Die Modernisierung des Engineerings entfaltet ihre volle Wirkung erst nach einer Übergangszeit. Neue Methoden werden am effektivsten anhand neuer Produkte eingeführt. Daher kann es Jahre dauern, bis das bestehende Portfolio vollständig durch Produkte basierend auf einer modernisierten F&E Tool Chain und neuer Produktstrukturierung abgelöst wurde. Mit jeder weiteren Maschine, die heute auf gewachsenen suboptimalen Strukturen auf den Markt gebracht wird, verliert der Maschinenhersteller Jahre für die vollständige Transformation.

Wenn industrielle KI als Chance für Hochlohnländer wie Deutschland gesehen wird, auch in Zukunft Produktion, Entwicklung und damit industrielle Arbeitsplätze zu halten, müssen in den Entwicklungsbereichen heute die Weichen dafür gestellt werden.

Quellen

Meyer, M. H. und Utterback, J. M. (1993) „The Product Family and the Dynamics of Core Capability“, Sloan Management Review, 34(3), S. 29–47.

Miller, R. B. (1968). Response time in man-computer conversational transactions. Proc. AFIPS Fall Joint Computer Conference Vol. 33, 267-277.

Rother, M. und Shook, J., (1999). Learning to See: Value stream mapping to create value and eliminate muda. Version 1.2. Brookline, MA: Lean Enterprise Institute.

Svensson, D. und Malmqvist, J. (2000). „Strategies for Product Structure Management in Manufacturing Firms“, in Proceedings of the 2000 ASME Design Engineering Technical Conferences (DETC2000), Baltimore, Maryland, USA, 10.–14. September 2000.

Womack, J. P. und Jones, D. T. (2013): Lean Thinking: Ballast abwerfen, Unternehmensgewinn steigern, 3., aktualisierte u. erw. Aufl., Frankfurt am Main: Campus Verlag.

Zitierweise

Um diesen Artikel in Facharbeiten, Studien oder Publikationen zu zitieren, nutzen Sie bitte folgende Angabe:

Karlberger, A. (2026): „MetaCre8^® ED – Engineering Design. Eine Methode zur Modernisierung der F&E Tool Chain.“. In: MetaCre8 GmbH Fachblog. Veröffentlicht am 03.11.2026. Aktuelle Version: 1.0. URL: https://metacre8.com/metacre8-ed-engineering-design-eine-methode-zur-modernisierung-der-fe-tool-chain (Abgerufen am: [TT.MM.JJJJ]).

Versionshistorie & Changelog