Gewachsene Strukturen blockieren die Digitalisierung im Maschinenbau

Abstract

Der Artikel beleuchtet die Ist-Situation der Systemlandschaft im F&E-Bereich des Maschinenbaus und macht deutlich, dass ohne eine grundlegende Erneuerung der über Jahrzehnte gewachsenen Methoden, Prozesse und Werkzeuge die Vision der Industrie 4.0 schwer erreichbar ist.

Zunächst werden typische Merkmale einer gewachsenen Systemlandschaft beschrieben. Danach wird skizziert, welche Vorteile moderne Paradigmen wie Baukasten und Systems Engineering in Verbindung mit Digitalisierung haben und welche Risiken im Nicht-handeln liegen.

Schließlich wird ein Weg aufgezeigt, wie sich durch eine strukturierte Vorgehensweise auch gewachsene Systemlandschaften konsequent in eine hocheffiziente State-of-the-Art Entwicklungsplattformen transformieren lassen.

Einleitung

Die Vision eines vollständig vernetzten, durchgängigen Engineering Ökosystems, auch Engineering 4.0 genannt¹vgl. Eigner, M. (2021), S.29, trifft auf die harte Realität der über Jahrzehnte gewachsenen Systemlandschaften etablierter Unternehmen, geprägt von unstrukturierten Daten, unflexiblen Konzernstücklisten, Silo-Denken und einer Wiederverwendungsstrategie nach dem Prinzip clone-and-own.

In der Vergangenheit sind Versuche, Engineering-Daten bereits bei der Entstehung disziplinübergreifend zu strukturieren, gescheitert. Grund dafür sind u.a. ungeeignete Ansätze und technische Restriktionen. Heute schrecken Unternehmen vor der erneuten Überarbeitung grundlegender Strukturen im Engineering zurück, weil sie einen zu hohen Aufwand und Misserfolge befürchten. Zudem werden die Potenziale durchgängig genutzter funktionaler und physischer Strukturen in Bezug auf interne Prozesse, Folgeprozesse und zukünftige digitale Produkte unterschätzt.

Mit einer geeigneten Vorgehensweise und einem effektiven Strukturierungsansatz lässt sich der Abstimmungsbedarf erheblich reduzieren. Mit Hilfe eines klaren, nachvollziehbaren Gesamtkonzepts kann eine hohe Akzeptanz im Entwicklungs-Team erzielt werden. Durch die Implementierung der neuen Strukturen in vorhandene, angepasste oder neue Systeme wird die veränderte Arbeitsweise im Unternehmen verankert. Zukünftige KI-Systeme können dann auf eindeutigen Datenstrukturen operieren, was neue Wege für Produktoptimierungen oder zukünftige digitale Produkte und Dienstleistungen ermöglicht.

Im nächsten Abschnitt werden zunächst einige Charakteristika der heutigen Systemlandschaft betrachtet.

Danach wird skizziert, welche Vorteile Unternehmen haben, die direkt mit modernen Paradigmen wie echter Baukastenstrategie und Systems Engineering starten.

Schließlich wird ein Weg aufgezeigt, wie sich durch eine strukturierte Vorgehensweise die gewachsenen Systemlandschaft konsequent in eine hocheffiziente Entwicklungsplattform transformieren lässt.

Engineering heute

Reifegrade

Teilt man die Systemlandschaft symbolisch in Versionsstände ein, kann man die Einführung von CAD als Engineering 2.0 betrachten. Automatische Workflows und Datenvernetzung, getrieben durch die Einführung von PLM-Systemen, lassen sich der Version 3.0 zuordnen, und die Nutzung digitaler Zwillinge und KI-Agenten sind Teil von Engineering 4.0.

Die Versionsstände können auch als Reifegrade interpretiert werden, wobei das nächste Level erst nach Abschluss des vorherigen erreicht werden kann.

Während die heutige Diskussion sich vielfach um die Einführung von Engineering 4.0 dreht, sollte hinterfragt werden, auf welcher Stufe der Maschinen- und Anlagenbau heute steht, damit die Ressourcen für die Weiterentwicklung des Engineerings optimal allokiert werden können.

Wenn ein Unternehmen die im Folgenden aufgeführten Merkmale zumindest in Teilen aufweist, wäre die Bezeichnung Engineering 2.5 plausibel.

Unstrukturierte Daten

Beispiele für unstrukturierte Daten sind Inhalte von Office- oder PDF-Dokumenten, die vielfach Teil des Engineering-Workflows darstellen, beispielsweise in Form von Anforderungslisten, Lasten-/Pflichtenheften oder Funktionsbeschreibungen, die Screenshots von CAD-Modellen, Fluid- oder Stromlaufplänen enthalten. Selten berücksichtigen diese Dokumente scharfe Systemgrenzen oder hierarchische Strukturen.

Vielfach liegen lokal bereits strukturierte Daten vor, weil Engineering Systeme die Projekte in Datenmodellen verwalten. Hierbei wird angestrebt, über alle Disziplinen hinweg durchgängige Begriffe und identische Inhalte zu verwenden. Diese Versuche sind immer wieder gescheitert, weil ungeeignete Ansätze oder technische Restriktionen die Vereinheitlichung blockieren.

Ungeeignete Ansätze: Lange wurde im F&E-Bereich angestrebt, mechatronische Module zu definieren, die alle Engineering-Daten bündeln, wie beispielsweise CAD-Daten, Stücklisten, Stromlaufpläne, Steuerungs-Software etc.. Hierbei werden Erfahrungen aus der physischen Welt auf die digitale Welt übertragen. Für eine optimale Wiederverwendung wird angestrebt, alle Elemente der mechatronischen Komponente an einem Ort – bzw. in einer digitalen Ablage – zu „lagern“. In der physischen Welt ist dies praktikabel und nachvollziehbar. In der digitalen Welt führt dieser Ansatz jedoch zu unnötigen Einschränkungen, weil die Aufteilung in „Kästchen“ voraussetzt, dass es nur einen einzigen Weg der Zerlegung über alle Disziplinen hinweg gibt²vgl. Weinberger, 2007. Multidisziplinäre Produktdaten müssen jedoch nach unterschiedlichen Kriterien zerlegt werden, weil verschiedene Nutzer unterschiedliche Anforderungen an die Sichten bzw. Systemschnitte haben. Die Konsistenz wird dabei durch Referenzieren aufrechterhalten und nicht durch Kollokation. Die fundamentalen inneren Strukturen sind hierbei

• die physische Produktstruktur³Als Produktstruktur bezeichnet man die hierarchische Zerlegung eines Produkts in ein Baumstruktur (Svensson und Malmqvist (2000), S. 2.) sowie
• die Funktionsstruktur⁴Vgl. Gericke et al. (2021), S. 241-251..

Letztere findet im Maschinenbau außerhalb der Elektrokonstruktion heute wenig Beachtung.

Technische Restriktionen: Idealerweise folgen MCAD⁵Mechanical Computer Aided Design-Baugruppen und Stücklistenstruktur der vom F&E-Bereich definierten Produktstruktur. Bei Verwendung einer Konzernstückliste ist der F&E-Bereich jedoch gefordert, die Struktur der Stückliste auf Basis von Produktionsanforderungen immer wieder anzupassen. Die Folge sind unscharfe Systemgrenzen durch abweichende Inhalte zwischen CAD-Baugruppe und Stückliste des entsprechenden Materials. Dieses grundlegende Problem wird im Folgenden vertieft.

Konzernstückliste

Im Bereich der Stücklisten (BOM⁶Bill-of-Material) hat sich in vielen Unternehmen das Konzept der Konzernstückliste etabliert. Die BOM wird von der Entwicklung aufgebaut und verwaltet. Die Produktion erstellt auf Basis der Stücklistenstruktur die Arbeitspläne. Die Aufteilung der Komponenten auf die Hierarchie-Ebenen der Stückliste bildet eine wesentliche Restriktion für die Montageplanung, denn diese erfolgt separat für jedes Material, d.h. auf jeweils einer Stücklistenebene. Sollen tiefer liegende Bauteile, wie beispielsweise Abdeckungen von Unterbaugruppen, erst am Ende der Hauptlinie montiert werden, müssen diese Teile auf die oberste Stücklisteneben verschoben werden (außer, es werden fehleranfällige Workarounds verwendet). Diese Stücklistenänderungen werden von der Entwicklung als interne Dienstleistung für die Produktion durchgeführt. Durch die Konzernstückliste wird zwar die Datenkonsistenz zwischen Entwicklung und Produktion erzwungen, es entstehen jedoch zerklüftete Stücklisten, die nicht mehr der Baugruppenstruktur im CAD entsprechen. Dies erschwert nicht nur die durchgängige Modularisierung und baukastenbasierte Mehrfachverwendung, es behindert auch die Generierung von Stücklisten aus dem CAD, da die Zielstruktur der Stückliste von der Baugruppenstruktur im CAD abweicht. Zudem ergeben sich bei gleichzeitiger Fertigung in mehreren Werken Einschränkungen hinsichtlich werkspezifischer Montageprozesse und Umsetzungszeitpunkte von Änderungen.

Konfigurations-Silos

Durch die Zunahme an Produktvarianten waren die Fachbereiche bereits vor vielen Jahren gefordert, Konfigurationstechnologien einzuführen, um disziplinspezifische Daten wie Stücklisten, Arbeitspläne, Steuerungsparameter oder Stromlaufpläne automatisch in der richtigen Variante auftragsspezifisch zu filtern und auszuleiten.

Im Konfigurationsumfeld sind oft ausgeprägte Datensilos, teilweise durch Eigenentwicklungen, entstanden. Weil übergeordnete Rahmenkonzepte fehlen, erfolgt die Konfiguration der unterschiedlichen Systeme überwiegend dezentral. Als kleinster gemeinsamer Nenner kommt dann häufig die High-Level Vertriebskonfiguration zum Einsatz, von der die bewerteten Merkmale abgegriffen werden, um sie in spezialisierten Konfiguratoren innerhalb der einzelnen Fachbereiche weiterzuverarbeiten. Weil eine variantenreiche Komponente meist in unterschiedlichen Systemen gleichzeitig repräsentiert ist, entstehen bei dieser Vorgehensweise redundante Konfigurationsregeln. Die Folgen sind erhöhter Verwaltungsaufwand und erhöhtes Fehlerrisko durch Schiefstände. Zudem weisen die dezentralen Konfiguratoren häufig eine hohe Komplexität auf, was zu erhöhtem Verwaltungsaufwand und zu Abhängigkeiten von Einzelpersonen führt.

Carry-over + clone-and-own

Statt einer echten Baukastenstrategie auf Basis von mehrfachverwendeten Modulen und Produktfamilien aufzubauen, wird z.T. die Kombination aus Carry-over, Technologiestandardisierung und Gleichteilestrategie als „Baukastenstrategie“ betrachtet.

Beim Carry-over wird ein neues Maschinenprojekt auf Basis einer bestehenden Maschine aufgesetzt. Ein Großteil der Baugruppen wird dabei übernommen und ein kleinerer Teil angepasst oder neuentwickelt. Prinzipiell kann auch hierbei eine Maschinen-übergreifende Nutzung von Baugruppen erreicht werden. Ohne eine entsprechende übergeordnete Produktfamilien- bzw. Plattformentwicklung ist diese Form der Standardisierung aber kaum aufrecht zu halten.

Wenn sich aus dem Maschinenprojekt neue Anforderungen an die übergreifend genutzte Baugruppe ergeben, steigt der Druck, die Baugruppe maschinenspezifisch anzupassen. In diesem Fall wird eine Kopie erzeugt (neues Material, neue Dokumentennummer) und die Anpassung erfolgt losgelöst von der ursprünglichen Baugruppe. Alternativ wird eine Variante durch Konfigurationsparameter angelegt, die dann jedoch keine übergreifende Varianten-Optimierung durchläuft. So entstehen unkontrolliert Varianten, die die Komplexität im gesamten Unternehmen erhöhen. Um dies zu verhindern, ist eine echte Baukastenstrategie erforderlich, die zwischen Modulentwicklung einerseits und Plattform- bzw. Produktfamilien-Entwicklung andererseits unterscheidet.

Wettbewerbsdruck durch jüngere Unternehmen

Die Bedrohung durch neue Wettbewerber kann sich deutlich erhöhen, wenn diese auf dem Greenfield starten und von Beginn an moderne Paradigmen, Methoden und Werkzeuge einsetzen. Dadurch liegen Daten bereits strukturiert vor, und Digitalisierungsvorhaben lassen sich mit diesen Daten viel effektiver umsetzen (s. Abbildung 1).

Der Ansatz, KI zu nutzen, um unstrukturierten Daten Struktur zu geben, erscheint – bezogen auf das Engineering – wenig zielführend, und entspringt der Hoffnung, Tools, Prozesse, Strukturen und Arbeitsweisen unverändert lassen zu können.

Doch gerade die Verbesserung der Entwicklungssystematik macht bereits einen wesentlichen Teil des Effizienzgewinns aus. Beispielsweise erscheint die Art und Weise, wie heute Anforderungen erhoben und heruntergebrochen werden, um Teilsysteme zu spezifizieren wenig strukturiert. Möchte man Over-Engineering vermeiden, muss man genau hier ansetzen.

Abbildung 1: Greyfield vs. Greenfield

In einer State-of-the-Art Engineering Landschaft müssen Daten nicht erst aufwendig aufbereitet werden, um ausgewertet werden zu können. Sie sind bereits bei der Entstehung klassifiziert bzw. durch standardisierte Datenmodelle semantisch beschrieben.

Mit eindeutiger Produkt- und Funktionsstruktur, durchgängigen, plattformübergreifenden Modulen, Trennung und Synchronisation von eBOM⁷Engineering-BOM und mBOM⁸Manufacturing-BOM, redundanzarmen Konfiguratoren, klaren Anforderungen, System-Modellen mit Code-Generierung sowie weiteren Automatismen lässt sich eine deutlich kürzere Time-to-Market erreichen.

Die grundlegenden Effekte lassen sich vereinfacht als Wirkdiagramm darstellen (s. Abbildung 2).

Durch die Rückführung von Felddaten in die Entwicklung lässt sich eine schnellere Verbesserung und kontinuierliche Weiterentwicklung der Produkte erreichen.

Gleichzeitig ermöglicht eine konsequent umgesetzte Baukastenstrategie die Realisierung von Skaleneffekten und damit kostengünstigere Produkte.

Innovative, hochwertige und gleichzeitig günstige Produkte mit kurzen Lieferzeiten erzeugen in Summe ein erhebliches Potenzial, um Marktanteile zu gewinnen.

Eine konsequent umgesetzte Digitalisierungs-Strategie eröffnet darüber hinaus die Möglichkeiten, strukturierte Engineering Daten für Folgeprozesse automatisiert nutzbar zu machen. So können skalierbare digitale Produkte mit neuen Umsatzmöglichkeiten entstehen. Die daraus generierten Erlöse schaffen wiederum zusätzlichen Spielraum bei der Hardware bzw. beim physischen Produkt, beispielsweise, indem geringere Deckungsbeiträgen angesetzt werden. Somit können etablierte Unternehmen, die die Chancen der Digitalisierung noch nicht voll nutzen, weiter unter Druck geraten.

In Summe entstehen zwei wesentliche positive Rückkopplungen, d.h. Wirkzusammenhänge, die sich selbst verstärken:

Erstens, Skaleneffekte, d.h. schneller billiger und zweiten, die systematische Nutzung von Felddaten zur Produktverbesserung, d.h. schneller besser.

Der entscheidende strategische Punkt ist daher: Wer seine Aktivitäten auf die minimale, inkrementelle Weiterentwicklung des Engineerings beschränkt, läuft Gefahr, seine strategische Erfolgsposition zu verlieren.

Abbildung 2: Effekte von Engineering 4.0

Zudem bietet eine moderne Engineering-Plattform mit ihren strukturierten Daten mittelfristig deutlich bessere Möglichkeiten für KI-basierte Agenten, die zu noch höherer Effizienz und kürzere Time-to-Market führen werden. Abgesehen davon, kann sich eine moderne Engineering-Plattform positiv auf die Talentsuche auswirken, insbesondere in den Bereichen IT, KI und Steuerungs-Technik.

Schlussfolgerung und Lösungsweg

Wer in Deutschland zukünftig weiterhin erfolgreich Maschinen und Anlagen entwickeln, produzieren und betreiben will, muss die Engineering-Landschaft und die durch sie repräsentierten Routinen konsequent erneuern.

Die MetaCre8 GmbH hat für die Modernisierung ein Handlungsrahmen bestehend aus vier Ebenen entwickelt (s. Abbildung 3).

Abbildung 3: 4-Ebenen-Modell zur Modernisierung des Engineerings

Ebene 4: Zielbild

Der erste Schritt ist die Bestimmung des Status quo. Dieser lässt sich methodisch objektiv durch Checklisten, Stichproben und Experten-Interviews anhand des aktuell gelebten Entwicklungsprozesses ermitteln.

Danach folgt die Ausarbeitung der Vision für das Engineering, die aufgrund der bevorstehenden Veränderung der Arbeitsweise sowie der funktionsübergreifenden Wirkung vom Vorstand kommuniziert werden sollte. Ein systematisches Goal Tracking sollte ebenfalls etabliert werden, um die Umsetzung transparent zu verfolgen und bei Abweichungen frühzeitig geeignete Maßnahmen einzuleiten.

Ebene 3: Planung

Die Planung sollte in einem regelmäßigen Turnus erfolgen und in die Geschäftsjahresplanung bzw. Forecasts integriert werden. Um die laufende Produktentwicklung und die Transformation des Engineerings bestmöglich zu verzahnen, ist ein regelmäßiger Abgleich beider Roadmaps erforderlich. Hier wird z.B. entschieden, in welchen Maschinenprojekten welche angepassten oder neuen Strukturen, Systeme, Rollen oder Prozesse zum Einsatz kommen, um die beteiligten Teams und Führungskräfte im Fachbereich rechtzeitig vorzubereiten und aktiv einzubinden. Das Engagement der Führungskräfte ist entscheidend, da sie die erforderliche Kapazitäten aus ihren Bereichen für die Konzeption und Umsetzung der Engineering-Transformation bereitstellen müssen und möglichen Widerständen aktiv begegnen müssen. Die Incentivierung ist insbesondere in Fachbereichen entscheidend, um einen Ausgleich zu bestehenden, produktbezogenen Zielen der Führungskräfte zu schaffen.

Die Prozessverantwortung stellt ebenfalls eine wichtige Möglichkeit dar, um die Identifikation der Führungskräfte mit den neuen Engineering-Prozessen zu unterstützen.

Ebene 2: Team, Organisation, Management

Für eine Programmorganisation sollte eine Matrixstruktur verwendet werden. Mitarbeitende aus den Fachbereichen sowie aus zentralen Bereichen arbeiten anteilig an Projekten der Engineering-Transformation mit. In einzelnen Fällen kann auch eine Vollzeit-Beteiligung erforderlich sein.

Im Kern besteht das Team aus Personen der Funktionsbereiche F&E, IT sowie CAD-/PLM-Support. Diese Bereiche sind am meisten von den Änderungen betroffen. Je nach Thema werden weitere Funktionsbereiche hinzugezogen. Als Methodik für das Projekt- und Programm-Management eignet sich Agile, weil dadurch vor dem Hintergrund der komplexen, neuartigen Entwicklung mit all ihren Abhängigkeiten und den relativ häufigen zeitlichen und inhaltlichen Anpassungen eine hohe Adaptivität und Reaktionsfähigkeit sichergestellt werden kann.

Ebene 1: Werkzeuge und Umsetzungsschritte

Als zentrales Werkzeug sollte ein Framework zum Einsatz kommen. Mit der Methode MetaCre8^® ED – Engineering Design können Unternehmen von einem effektiven Hilfsmittel profitieren. Das zugrundeliegende Framework ist klar gegliedert, lässt sich schnell verstehen und in kürzester Zeit operativ einsetzen. Es unterstützt den Aufbau eines gemeinsamen mentalen Modells, mit der Folge, dass Diskussionen in disziplinübergreifenden Teams erheblich effizienter ablaufen. Durch das gemeinsame Verständnis der komplizierten Engineering Prozesse werden auch bessere Gesamtlösungen erzielt, und Projekte lassen sich einfacher parallelisieren, was die Umsetzungsgeschwindigkeit erhöht. Mit dem Framework lassen sich sowohl die Ist- als auch die Soll-Prozesse übersichtlich darstellen. Es dient als effektives Kommunikations- und Gestaltungsmittel.

Demonstrations-Szenarien auf Basis realer Fallbeispiele sind entscheidend. Sie bilden nicht nur stellvertretend kritische Pain-Points ab und dienen zur Validierung der Systeme, sondern sind auch äußerst nützlich für die unternehmensweite Kommunikation der Ergebnisse.

Wie im Produktentwicklungsumfeld üblich, sollte auch für die Gestaltung des Engineerings eine Möglichkeit für schnelles Feedback und Erfahrungsgewinn geschaffen werden. Daher müssen entsprechende Testumgebungen bereitgestellt werden. Über Proof-of-Concept, optionale Benchmarks, Pilotierung und Rollout wird für jedes Einzelprojekt des Engineering-Programms die Einführung im Unternehmen risikoarm vorbereitet und umgesetzt. Richtlinien- und Prozessportale, interne Schulungen und ein kontinuierlicher Verbesserungsprozess unterstützen die Verankerung und Akzeptanz der neuen Methoden, Prozesse und Tools.

Fazit

Die digitale Transformation gewachsener Engineering-Landschaften ist anspruchsvoll und erfordert hinreichend Ressourcen, auch in Bereichen, die heute bereits stark ausgelastet sind. Um so wichtiger ist es, die begrenzten Ressourcen gezielt und wirkungsvoll einzusetzen. Hierfür ist eine strukturierte Vorgehensweise unter Einsatz eines Frameworks wie dem MetaCre8^® ED – Engineering Design naheliegend. Das Engagement des Top-Managements, die Einbindung der Führungskräfte und die aktive Einbindung von Fachexperten sind ein weiterer wesentlicher Erfolgsfaktor.

Mit dem vorgestellten 4-Ebenen-Modell lässt sich die Transformation hinsichtlich Umsetzungsdauer und Aufwand erheblich komprimieren.

Welche Branchen in Zukunft an Bedeutung gewinnen, wird sich zeigen. Ein effizienter Maschinen- und Anlagenbau ist gewiss eine wesentliche Voraussetzung für den schnellen Scale-up neuer Branchen. Eine deutlich höhere Taktrate im Engineering als bisher wird dazu beitragen, neue Branchen in Deutschland und Europa anzusiedeln und langfristig zu halten.

Quellen

Eigner, M. (2021). „Engineering 4.0 – Grundlagen der Digitalisierung des Engineerings“, in Eigner, M. System Lifecycle Management: Digitalisierung des Engineering. Berlin, Heidelberg: Springer-Verlag.

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.

Gericke, K., Bender, B., Pahl, G., Beitz, W., Feldhusen, J. und Grote, K.-H. (2021). „Funktionen und deren Strukturen“, in Bender, B. und Gericke, K. (Hrsg.) Pahl/Beitz Konstruktionslehre: Methoden und Anwendung erfolgreicher Produktentwicklung. 9. Aufl. Berlin, Heidelberg: Springer Vieweg, S. 241–251.

Weinberger, D. (2007). Everything Is Miscellaneous: The Power of the New Digital Disorder. New York: Times Books.

Zitierweise

Um diesen Artikel zu zitieren, nutzen Sie bitte folgende Angabe:

Karlberger, A. (2026): „Gewachsene Strukturen blockieren Digitalisierung im Maschinenbau“. In: MetaCre8 GmbH Fachblog. Veröffentlicht am 09.09.2026. Aktuelle Version: 1.0. URL: https://metacre8.com/greyfield-blockiert-digitalisierung-im-maschinenbau (Abgerufen am: [TT.MM.JJJJ]).

Versionshistorie & Changelog