Baukasten­strategie – Herausforderungen und Lösungen für den Entwicklungs­bereich im Maschinenbau

Zusammenfassung

Das Thema Baukasten zählte vor einigen Jahren bei vielen Unternehmen zu den wichtigsten strategischen Zielen. Da aktuelle Trends wie digitale Transformation und KI auf bestehenden Daten, Prozessen und Methoden aufsetzen, sollte kritisch geprüft werden, wie konsequent die Idee des mecha­tronischen Baukastens tatsächlich umgesetzt wurde und ob Handlungs­bedarf besteht. Denn mit der Einführung einer disziplin- und standortübergreifenden Baukasten­strategie ändert sich die Arbeitsweise im Unternehmen in vielfacher Hinsicht. Die baukasten­basierte Mehrfachverwendung nach dem Single-Source-of-Truth Ansatz führt zu redundanzarmen Datenstrukturen und erfordert neben der Modularisierung der Produkte auch Technologien zur Konfiguration und Synchronisation sowie neue Methodiken und organisatorische Anpassungen. Die Baukasten­strategie führt daher zwangsläufig auch zu hoher Datenqualität und einem hohen methodischen Reifegrad. Beides ist hilfreich, um Themen im Bereich der digitalen Transformation und der KI effektiv und effizient umzusetzen. Gleichzeitig erfordert der Baukasten ein hinreichendes Maß an Systemunterstützung im Sinne der Digitalisierung. Somit bieten die Handlungsfelder im Engineering erhebliche Synergiepotenziale zur Beschleunigung der Transformation. Der folgende Artikel gibt Hinweise für den Handlungsbedarf und mögliche Lösungen zur Umsetzung eines mechatronischen Baukastens.

Single-Source-of-Truth statt Clone-and-Own

Viele Unternehmen sind davon überzeugt, bereits eine Baukastenstrategie implementiert zu haben. Bei näherem Hinsehen zeigt sich jedoch häufig eine Carry-Over-Strategie auf Produkt- und Modulebene. Hierbei wird bei Neuentwicklungsprojekten entschieden, welche Inhalte aus einem vergangenen Projekt übernommen werden, um den Aufwand zu reduzieren. In der Praxis werden bei einer solchen Übernahme häufig Kopien erzeugt, wobei die kopierten Baugruppen an die Anforderungen des neuen Projekts angepasst werden. Ist das neue Projekt kein Nachfolger sondern ein Derivat, existieren die Originalbaugruppe und die angepasste Variante parallel im Unternehmen und im Feld. Diese Arbeitsweise nach dem Prinzip „Kopieren-und-Anpassen“ (englisch: clone-and-own) führt zwar schnell zu Ergebnissen, erhöht jedoch sowohl die Komplexitätskosten im gesamten Unternehmen als auch das Risiko ungeplanter redundanter Entwicklungstätigkeiten.

Die Baukastenstrategie hingegen basiert auf dem Prinzip „Single-Source-of-Truth“. Hierbei wird ein konfigurierbares Modul entwickelt und versioniert. Dieses Modul wird dann von unterschiedlichen Produktfamilien verwendet. Der Verwender kann lediglich die benötigten Varianten durch Konfiguration anwählen. Die Weiterentwicklung der Module erfolgt parallel und synchron zu den Maschinenprojekten, so dass auch neue Anforderungen aus diesen Projekten im Modul umgesetzt werden. Damit im Lebenszyklus eines Moduls nicht permanent neue Varianten entstehen, erfolgt eine systematische Bewertung des optimalen Standardisierungsgrades. Hierbei muss zwischen Überdimensionierung (One-Size-Fits-All) und hohen Komplexitätskosten (viele Varianten durch lokale Optimierung) abgewogen werden.

Für den Entwicklungsbereich ergeben sich durch eine Baukastenstrategie drei wesentliche Vorteile:

• geringere Herstellkosten durch Skaleneffekte,
• Kapazitätsersparnis durch Vermeidung redundanter Entwicklungstätigkeiten sowie
• kürzere Time-to-Market durch Erweiterung einer Produktfamilie bzw. Plattform um neue Ausprägungen.

Einbindung der Software-Entwicklung

Trotz der zunehmenden Bedeutung von Software und Elektrik/Elektronik, basiert der Maschinenbau auf physischen Produkten, die effizient gefertigt und montiert werden müssen. Das Management der Supply Chain für die oft komplizierten und variantenreichen Produkte ist anspruchsvoll – insbesondere im Hinblick auf Änderungen – daher sind Prozesse zur Datenübernahme von der Konstruktion zum Einkauf und zur Fertigung, häufig standortübergreifend, über viele Jahre etabliert und verfeinert worden.

Da Software als Produkt oder Produktbestandteil für den Maschinenbau an Bedeutung gewinnt, sind Prozesse und Tools entstanden, die ähnlich zum physischen Produkt auch für Software-Komponenten den Übergang von der Entwicklung zur Inbetriebnahme und zum Service unterstützen. Viele dieser Tools werden vom Fachbereich entwickelt und verwaltet. Dies hat sowohl positive wie auch negative Aspekte.

Vorteile:

Die Tools werden von Personen aus dem Fachbereich entwickelt, die die darin abzubildenden Prozesse genau kennen. Aus Sicht des Fachbereichs ist keine Abstimmung mit externen Stellen erforderlich, was die Umsetzung zumindest in der Anfangsphase beschleunigt.

Nachteile:

• aufwendige, redundante Entwicklungen, z.B. im Bereich der Produktkonfiguration
• Insellösungen: Jeder Standort entwickelt sein eigenes Tool, was die standortübergreifende Standardisierung erschwert.
• dauerhafte Bindung von Kapazität für die Tool-Entwicklung, die Wartung und den Support
• Abhängigkeit von Einzelpersonen
• Entkopplung der IT (diese lernt die internen Prozesse nie kennen)
• Lösungen nicht an langfristiger IT-Roadmap orientiert
• Abhängigkeiten von IT-Schnittstellen, die sich jederzeit ändern können
• Lösungen nicht immer technologisch State-of-the-Art

Der teils massive Umfang an Schatten-IT im Bereich der Software-Entwicklung führt zu Prozess-seitigen Parallelwelten. Dies erschwert die Konzeption, Umsetzung und Etablierung einer effektiven disziplin- und standortübergreifenden Baukastenstrategie. Für die Baukastenstrategie, aber auch für eine umfassende digitale Transformation, muss die Schatten-IT beleuchtet und im Gesamtkontext objektiv bewertet werden.

Schnittstelle Entwicklung – Produktion

Stücklisten und Arbeitspläne zählen zu den fundamentalen Datenstrukturen im Unternehmen. Ohne diese Informationen kann keine Produktion erfolgen. Zur Zeit der Einführung von Planungssystemen in der Produktion waren die Produktportfolios und Unternehmensstruktur­en überschaubar. Mit zunehmend standortübergreifender Entwicklung und globalem Produktionsverbund ändern sich die Rahmenbedingungen für den Handshake zwischen Entwicklung und Produktion.

Beide Bereiche haben unterschiedliche Anforderungen an die Stückliste (engl. Bill-of-Material, BOM). In der Entwicklung folgt die BOM-Struktur dem Aufbau der CAD-Baugruppe nach Kriterien der Konstruktion. In der der Produktion dagegen entsprechen die Inhalte von Baugruppen der Montagereihenfolge. Diese kann sich von der Entwicklungssicht unterschei­den, z.B. wenn Abdeckungen einzelner Baugruppen erst am Ende der Montagelinie verbaut werden. Wird ein Produkt an mehreren Standorten produziert, kann der Montageprozess zwischen den Werken variieren. Eine Lösung ist daher die Trennung zwischen Entwicklungs­stückliste (EBOM) und Fertigungsstückliste (MBOM). Da sich bei Serienprodukten über die Zeit Änderungen am Produkt und damit an der EBOM ergeben, müssen diese in den MBOMs nachgezogen werden. Ohne Systemunterstützung ist dieser Prozess fehleranfällig, daher nutzen Unternehmen alternativ eine Konzernstückliste, um Datenschiefstände zu vermeiden. Diese durchgängig genutzte Stückliste wird zwischen Entwicklung, Produktion und Einkauf abgestimmt und vom Entwicklungsbereich verantwortet.

Neben dem Vorteil konsistenter Daten und einfacher Prozesse und Systeme weist das Konzept der Konzernstückliste im Hinblick auf Baukasten und Digitalisierung gravierende Nachteile auf. Montagebedingte Änderungen an der Stückliste muss die Entwicklung als Dienstleistung für den Produktionsbereich umsetzen. Die Produktion ist in ihrer Flexibilität eingeschränkt und auf die Zuarbeit der Entwicklung angewiesen. In der Entwicklung entstehen dadurch unvorhergesehene Störungen, und es kann aufgrund der Änderungen zu Abweichungen zwischen CAD-Struktur und Stückliste kommen. Dadurch lassen sich Prozesse wie die automatische Synchronisation von Stücklisten aus dem CAD nur bedingt umsetzen. Die Stücklistenerstellung erfolgt weiterhin händisch, was zu Mehraufwand führt und das Fehlerrisiko erhöht. Besonders nachteilig wirkt sich die Konzernstückliste auf die Mehrfachverwendung im Baukasten aus. Denn die Mehrfachverwendung erfordert stabile Systemgrenzen. Ein physisches Baukastenmodul sollte alle zugehörigen Komponenten umfassen. Dies ist bei produktionsgetriebenen Konzernstücklisten nicht immer gegeben, weil Bauteile in der Stücklistenstruktur entsprechend der Montagereihenfolge verschoben werden können. Zudem ist eine standortspezifische, zeitlich flexible Steuerung von Änderungen mit der Konzernstückliste schwer umsetzbar.

Als Lösung bietet sich die Trennung zwischen EBOM und MBOM mit einer systemgestützten Synchronisation von Änderungen an. MBOMs können dann angelegt werden, wenn diese produktionsbedingt benötigt werden. In diesem Fall werden diese aus EBOMs abgeleitet und die Komponenten zwischen den MBOMs verschoben. Für die nun getrennten Stücklisten muss sichergestellt werden, dass Änderungen an der EBOM in die davon abhängigen MBOMs systemgestützt synchronisiert werden. Für diesen Prozess sind entsprechend leistungsfähige Werkzeuge und organisatorische Rahmenbedingungen erforderlich.

Je nach IT-Architektur kann sich die optimale Aufteilungen von Teilprozessen auf das PLM- oder das ERP System unterscheiden. Auch im Hinblick auf die Variantenkonfiguration ist die Schnittstelle zwischen Entwicklung und Produktion konzeptionell sehr anspruchsvoll. Die Gestaltung sollte durch ein interdisziplinäres Projekt-Team mit Unterstützung des Managements geplant, konzipiert und umgesetzt werden.

Mit der Einführung der Stücklistensynchronisation werden nicht nur die Voraussetzungen für eine Baukastenstrategie geschaffen, es ergeben sich auch zahlreiche Synergien mit weiteren Themen der digitalen Transformation, wie beispielsweise der automatischen Konvertierung von CAD-Baugruppen für den digitalen Zwilling.

Begriffe

Die Mehrdeutigkeit von Begriffen führt schnell zu Missverständnissen und kann die Zusammenarbeit insbesondere über Abteilungsgrenzen hinweg stören. Gefordert sind eindeutige, einheitliche Begriffe, doch gerade im Baukasten-Kontext herrscht oft Unschärfe.

Ein typisches Beispiel ist die Funktionsorientierung. Unter dem Begriff „Funktion“ versteht die Elektrokonstruktion ein in sich zusammenhängendes technisches Teilsystem, wobei es keine Rolle spielt, auf welche physischen Module sich die Komponenten der Funktion verteilen (z.B. Maschinenbett, E-Kette, Schaltschrank). Die mechanische Konstruktion versteht unter einer „Funktionsbaugruppe“ eine aus Entwicklungssicht strukturierte Baugruppe, im Gegensatz zu einer nach Produktionskriterien aufgebauten Montagebaugruppe.

Im Bereich der Produktkonfiguration sind für viele Akteure die Begriffe Vertriebsmerkmal, technisches Merkmal, Merkmalsausprägung, Variante und Option unklar. Diese Unschärfe spiegelt sich dann in den zugrundeliegenden Produktstrukturen wider. So nutzen Software-Projekte nicht selten Mischungen aus physischer Baugruppe, technischer Funktion und Vertriebsoption für die Bezeichnung der Software-Module. Entsprechend kompliziert gestaltet sich der Aufbau eines standortübergreifenden Software-Baukastens als Teil der mechatronischen Baukastenstrategie.

Eine der großen Herausforderungen liegt in der mechatronischen Modularisierung. Der Versuch der Definition eines mechatronischen Moduls, als Container, der alle Teilaspekte von Mechanik, Elektrik und Software einschließlich aller zur Planung und Dokumentation erforderlichen Dokumente bis hin zu Simulationsmodellen beinhaltet, ist im Maschinenbau nicht zielführend. Dies liegt darin begründet, dass sich die Sichten und Systemgrenzen der Disziplinen Mechanik, Elektrik und Software wesentlich unterscheiden. So wäre es wenig nützlich, Software anhand der physischen Modulgrenzen zu zerlegen. Ebensowenig macht es Sinn, die mechanischen Baugruppen rein funktional zu gliedern. Somit ist es unmöglich, einheitliche mechatronische Modulgrenzen zu definieren, die allen Disziplinen gerecht werden. Die Lösung liegt in der Anwendung von zwei Strukturierungsprinzipien parallel: die physische und die funktionale Modularisierung. Jede Disziplin im F&E-Bereich muss sich an eine dieser Strukturen ausrichten. Eine übergreifende Konfigurationssystematik und die Abbildung der funktionalen auf die physische Struktur bilden schließlich ein schlüssiges Gesamtsystem für den mechatronischen Baukasten. Hierbei nutzt jede Disziplin nach Möglichkeit die jeweils vorhandenen Tools, sofern diese über entsprechende Konfigurations­möglichkeiten verfügen.

Unscharfe Begriffe erschweren nicht nur die Zusammenarbeit zwischen Personen, sondern stellen auch die digitale Transformation und den Einsatz von KI vor Herausforderungen. Denn nur durch Eindeutigkeit und Präzision lassen sich Systeme miteinander effizient vernetzen. Gleiches gilt für die Anwendung der KI auf Datenstrukturen im Engineering. Nur wenn diese eindeutig sind, können KI-basierte Systeme effizient trainiert werden und sinnvolle Ergebnisse liefern.

Organisation

Die klassische Organisation des Entwicklungsbereichs besteht aus einer hierarchischen Struktur, die nach Fachdisziplinen gegliedert ist. Projekte werden darin mit Hilfe einer Matrixstruktur organisiert. Im Rahmen einer Baukastenstrategie entstehen durch die Mehrfachverwendung nach dem Single-Source-of-Truth Ansatz Abhängigkeiten zwischen Modul und Produkt, die auch organisatorisch durch neue Aufgaben und Verantwortlichkeiten berücksichtigt werden müssen. Hierfür lassen sich Rollen definieren, die sich flexibel auf bestehende Linienorganisationen abbilden lassen. Zudem können einzelne Personen mehrere Rollen ausführen. Entscheidend ist, dass die Aufgabenprofile dieser Rollen definiert und deren Zuweisung kommuniziert werden. Auch wenn sich Unternehmen in ihrer Aufbau- und Ablauforganisation stark voneinander unterscheiden, sind prinzipbedingt folgende Rollen für eine Baukastenstrategie im Bereich F&E sinnvoll.

Modulverantwortlicher: Ist für die Entwicklung und Versionierung eines physischen Moduls verantwortlich und leitet das Modul-Team.

Funktionsverantwortlicher: Ist für die Entwicklung und Versionierung einer technischen Funktion verantwortlich und leitet das Funktions-Team.

Produktarchitekt: Ist für die Produktarchitektur verantwortlich. Unter Produktarchitektur wird in der Konstruktionlehre die Abbildung der funktionalen Struktur auf die physische Struktur verstanden. Die Architektur bestimmt beispielsweise, ob Komponenten einer technischen Funktion zentral oder dezentral angeordnet werden. Wird die Architektur aufgrund unvorhergesehener Anforderungen innerhalb einer Produktfamilie variiert, resultieren daraus zahlreiche Änderungen auf Baugruppenebene, was die Komplexität erhöht und Skaleneffekte verhindert. Die Architektur innerhalb einer Produktfamilie sollte daher invariant sein. Bedingung hierfür ist eine vorausschauende Planung des Baukastens. Dies beinhaltet auch ein strukturiertes Anforderungsmanagement.

Produktfamilien- bzw. Plattformverantwortlicher: Ist für die Produktfamilie bzw. Plattform insgesamt verantwortlich. Unter Produktfamilie / Plattform wird hier die Summe aller ähnlichen Endprodukte verstanden, die in einem Maximalprojekt zusammengefasst werden.

Produktverantwortlicher: Ist für eine einzelne Ausprägung aus der Produktfamilie/Plattform verantwortlich.

Weitere Rollen stellen beispielsweise die Umsetzung und die kontinuierliche Weiterentwick­lung der disziplinspezifischen Methoden und Tools sicher. Auch die Zuständigkeit für die z.T. komplizierten Projekt-Dateien für Produktfamilien innerhalb der Disziplinen (MCAD, ECAD, PLC etc.) kann durch Rollen geregelt werden.

Da die Tool-Unterstützung einen essentiellen Beitrag zur Umsetzung und Verstetigung der Baukastenstrategie darstellt, ist es wichtig, alle Tool- bzw. disziplinspezifischen Stakeholder in geeigneter Form in die Weiterent­wick­lung der Methodik einzubinden, wobei eine enge Abstimmung mit der Produktentwicklung erforderlich ist.

Führung

Eine umfassende Baukastenstrategie wird die Wettbewerbsfähigkeit von Unternehmen entscheidend verbessern und gleichzeitig die Voraussetzungen für eine effektive Umsetzung der digitalen Transformation und den Einsatz von KI schaffen.

Eine Baukastenstrategie erfordert jedoch Investitionen. Neben Tools und Expertise muss vor allem hinreichend interne Kapazität zur Verfügung gestellt werden, was eine Anpassung der Roadmap erforderlich machen kann. Die Entscheidung über die konsequente Einführung einer Baukastenstrategie muss daher von der Unternehmensführung kommen und von dieser vorangetrieben werden. Die entsprechenden Ziele hierfür müssen in Form individueller Zielvorgaben heruntergebrochen werden, um die Prioritäten zu setzen und die Führungs­kräfte zu motivieren. Zudem sollte die Unternehmensführung auch die cross-funktionale Zusammenarbeit fördern, insbesondere zwischen IT, Entwicklung und Produktion.

Auf diese Weise werden die Rahmenbedingungen gesetzt, um Unternehmen auf Baukasten und damit auf Effizienz und Zukunftsfähigkeit zu trimmen.