DWC Insight 301 · Executive Decision Guide

Der digitale Produkt-Backbone im Maschinenbau

Wie CRM, CPQ, PIM, PLM/CAD, ERP, MES und Service-Systeme verbindliche Produktinformationen über vier Verantwortungsbereiche hinweg verbinden.

Die Zielarchitektur beginnt nicht mit einer Softwareliste. Sie beginnt mit den Aufgaben, Ergebnisobjekten und Verantwortlichkeiten, die Markt, Entwicklung, Auftragsabwicklung, Produktion und Service verlässlich miteinander verbinden müssen.

Executive Summary

Der Backbone ist kein System. Er ist eine verbindliche Arbeitsteilung.

• Ein digitaler Produkt-Backbone ist weder eine einzelne Suite noch eine möglichst lange Softwarekette. Er verbindet vier Verantwortungsbereiche: Markt und Vertrieb, Produktentwicklung und Engineering, Auftrag und Produktion sowie Service und Lifecycle.
• CRM, CPQ, PIM, PLM, CAD, ERP, MES und Service-Systeme erfüllen unterschiedliche Kernaufgaben. Nicht jedes Unternehmen benötigt jede Rolle als eigenständige Anwendung.
• Entscheidend sind die verbindlichen Ergebnisobjekte: Kunden- und Opportunity-Kontext, freigegebene Angebotskonfiguration, publizierte Produktinformation, technische Produktdefinition, ausführbare Auftragsstruktur, Produktionsnachweis und installierte Basis.
• Überschneidungen sind zulässig, wenn Systeme unterschiedliche Zwecke und Gültigkeiten bedienen. Kritisch sind parallele Originale derselben Logik ohne eindeutige Führungs- und Freigaberegel.
• Zwei Zielbilder sind gleichermaßen legitim: ein integrierter, schlanker Kern für einen CTO-orientierten Serienmaschinenbauer und eine differenzierte Architektur für komplexe CTO-/ETO-Portfolios.

Leitthese: Nicht die Zahl der Systeme macht den Backbone tragfähig, sondern die klare Zuordnung von Aufgabe, Ergebnisobjekt und Verantwortung.

Vier Bereiche bilden die Architekturlandkarte

Maschinen- und Anlagenbauer betrachten ihre Landschaft häufig aus Sicht einzelner Anwendungen. Dadurch entsteht schnell eine Aufzählung von Produkten, ohne dass klar wird, welches geschäftliche Ergebnis jede Rolle zuverlässig erzeugen soll. Für eine belastbare Zielarchitektur ist die umgekehrte Reihenfolge hilfreicher: Geschäftsbereich, Aufgabe und Ergebnisobjekt zuerst – konkrete Anwendung danach.

Die folgende Landkarte trennt vier Verantwortungsbereiche. Sie ist kein universelles Referenzmodell und keine Forderung nach vier Plattformen. Sie zeigt, welche Aufgaben im Unternehmen mindestens verortet werden müssen, auch wenn mehrere Rollen technisch in einer Suite zusammenfallen.

Architekturlandkarte

Vier Verantwortungsbereiche – ein verbundener Produktlebenszyklus

Die Systeme sind Mittel zum Zweck. Verbindlich werden ihre freigegebenen Ergebnisobjekte und die kontrollierten Übergaben zwischen den Bereichen.

01

Markt & Vertrieb

CRM · CPQ/Konfiguration · PIM/DAM · optional Portal/Webshop

Führende Aufgaben

Kunde und Opportunity · Bedarf · Konfiguration · Preis/Angebot · Markt- und Kanalinformation

Verbindliche Ergebnisse

Qualifizierter Bedarf · freigegebenes Angebot · Konfiguration · Sales-BOM · publizierte Inhalte

02

Entwicklung & Engineering

MCAD · ECAD/CAE · PLM/PDM · ALM/Software-Konfiguration

Führende Aufgaben

Anforderungen · Produktdefinition · Mechanik · Elektrik · Software · Version und Freigabe

Verbindliche Ergebnisse

Technische Baseline · eBOM/Variantenmodell · CAD/ECAD-Artefakte · Software-Baseline · Änderung

03

Auftrag & Produktion

ERP · MES/MOM · optional APS, QMS oder Werksplanung

Führende Aufgaben

Auftrag · Material und Disposition · Arbeitsplan · Beschaffung · Fertigung · Qualität und Ist-Rückmeldung

Verbindliche Ergebnisse

100-%-Soll · mBOM/BOP · Produktionsauftrag · Prüf- und Ist-Nachweis · As-built-Rückmeldung

04

Service & Lifecycle

Installed Base/EAM/SLM · FSM · Serviceportal · optional IoT

Führende Aufgaben

Assetidentität · Installation · Wartung · Einsatz · Retrofit · Ersatzteil- und Servicefähigkeit

Verbindliche Ergebnisse

Installed-Base-Datensatz · As-maintained · Serviceauftrag · Historie · zulässige Ersatz-/Retrofit-Lösung

IdentitätVersion & GültigkeitOwner & FreigabeHerkunft & Rückverweis

↺Service- und Betriebswissen fließt kontrolliert in Produktdefinition, Marktangebot und zulässige Änderungen zurück.

Qualitative Architekturlandkarte. Rollen können technisch zusammenfallen; Aufgaben und Ergebnisobjekte bleiben fachlich unterscheidbar.

1. Markt und Vertrieb: vom Bedarf zum belastbaren Kundenversprechen

Der Vertriebsbereich benötigt zunächst Kontext: Wer ist der Kunde, welches Werk und welche Linie sind betroffen, welche Opportunity, Kontakte, Aktivitäten und Vereinbarungen bestehen? Diese Aufgabe liegt typischerweise im CRM. Das CRM führt den kommerziellen Prozess, ist aber nicht automatisch das fachliche Produktmodell.

CPQ beziehungsweise Produktkonfiguration übersetzt den Bedarf in eine zulässige, preis- und angebotsfähige Ausprägung. Das kann von Guided Selling und Preisfindung bis zur technischen Konfiguration reichen. Die Rolle kann als eigenständiges CPQ, als schlankes Frontend auf einem ERP-Konfigurationsmodell oder teilweise im CRM realisiert werden. Entscheidend ist, ob der Prozess nur ein Angebot erzeugt oder bereits eine belastbare Auftrags- und Produktentscheidung.

PIM und DAM strukturieren freigegebene, markt- und kanalfähige Produktinformationen: Beschreibungen, Klassifikationen, Medien, Sprachstände, Datenblätter und Publikationsregeln. Bei wenigen Produkten und Kanälen kann diese Rolle schlank bleiben. Bei internationaler Publikation, mehreren Marken, Portalen oder umfangreichen Medienbeständen wird sie eigenständig relevant. PIM ersetzt weder die technische Produktdefinition im PLM noch die Bestell- und Dispositionslogik im ERP.

2. Entwicklung und Engineering: die freigegebene Produktdefinition

Mechanik, Elektrik und Software beschreiben dieselbe Maschine mit unterschiedlichen Fachobjekten. MCAD führt Geometrie, Baugruppen, Einbauräume und mechanische Zeichnungen. ECAD/CAE führt elektrische Betriebsmittel, Schaltpläne, Verbindungen, Kabel und gegebenenfalls Fluid- oder Automatisierungsdaten. Softwareentwicklung benötigt Anforderungen, Quellstände, Tests, Releases und die Zuordnung zu Hardware- und Maschinenvarianten.

PLM/PDM verbindet diese Definitionen über Artikel, Dokumente, Varianten, Produktstrukturen, Versionen, Freigaben und Änderungen. Es ist nicht zwingend die einzige Datenbank aller Artefakte; es muss jedoch nachvollziehbar machen, welche technische Baseline für welchen Produkt- und Gültigkeitskontext freigegeben ist. Für softwareintensive Produkte ergänzt ALM beziehungsweise Software Configuration Management die Produktdefinition um Anforderungen, Builds, Tests und Releases.

3. Auftrag und Produktion: aus Produktdefinition wird ausführbare Realität

Das ERP führt den kaufmännischen Auftrag, Materialien, Termine, Disposition, Beschaffung, Kosten, Bestände und Produktionsaufträge. Es benötigt eine auftragsspezifische, ausführbare Struktur. Diese ist nicht einfach eine Kopie der Engineering-Sicht: Werk, Lieferant, Eigenfertigung, Zukauf, Materialersatz, Losgröße und Fertigungsstrategie verändern die operative Sicht.

MES beziehungsweise MOM steuert und dokumentiert die Ausführung näher am Werk: Arbeitsvorrat, Reihenfolge, Rückmeldungen, Prüfungen, Traceability, Abweichungen und tatsächlicher Verbrauch. Nicht jeder Maschinenbauer benötigt ein eigenständiges MES. Bei geringer Fertigungstiefe oder überschaubaren Abläufen kann ERP-nahe Ausführung genügen; bei komplexer Montage, hoher Nachweispflicht oder mehreren Werken wird eine eigenständige Rolle wahrscheinlicher.

4. Service und Lifecycle: die ausgelieferte Maschine bleibt ein veränderliches Objekt

Mit der Auslieferung endet die Produktstruktur nicht. Die Installed Base verbindet Maschine, Standort, Kunde, Serien- beziehungsweise Assetidentität, ausgelieferten Stand und spätere Änderungen. EAM/SLM und Field Service Management planen Wartung, Einsätze, Ressourcen, Ersatzteile, Serviceverträge und mobile Durchführung. Ein Serviceportal oder IoT-Dienst kann ergänzen, ist aber nicht automatisch die führende Quelle für die installierte Konfiguration.

Für den Service zählt die tatsächliche Maschine: Welche Kamera, Steuerung, Softwareversion oder Option wurde ausgeliefert? Welche Änderung wurde später eingebaut? Welche Ersatz- oder Retrofit-Lösung ist für genau diesen Stand zulässig? Ohne die Verbindung von As-built, As-delivered und As-maintained bleibt Servicewissen dokumenten- und personengebunden.

Beispiele für technische Ausprägungen – keine Shortlist

Konkrete Produktnamen erleichtern die Übertragung der Systemrollen auf bestehende Landschaften. Die folgenden Nennungen sind bewusst selektive Orientierungsbeispiele – keine Shortlist, Marktübersicht oder Eignungsbewertung. Maßgeblich bleiben Aufgabe, Ergebnisobjekt, Prozessklasse und Betriebsmodell. Produktbezeichnungen und Zuordnung: Stand August 2026.

Wo sich Rollen überschneiden – und wann das problematisch wird

Ein tragfähiges Zielbild beseitigt nicht jede Überlappung. Es entscheidet, welcher Zweck und welches Objekt in welcher Rolle verbindlich sind. Mehrere Systeme dürfen dieselbe Maschine sehen; sie dürfen nur nicht unbemerkt unterschiedliche Originale derselben Entscheidung erzeugen.

Zwei exemplarische Architekturen

Die folgenden Zielbilder zeigen keine Reifegrade. Sie verdeutlichen, dass eine schlanke und eine differenzierte Architektur gleichermaßen richtig sein können. Entscheidend ist die Passung zu Produktkomplexität, Prozessklassen, Wiederholgrad und Betriebsfähigkeit.

Was ist Kern – und was bleibt Add-on?

Kernsystemrollen sind nicht automatisch die größten oder teuersten Anwendungen. Kern ist eine Rolle dann, wenn ihr Ergebnis für mehrere nachgelagerte Prozesse verbindlich ist und dauerhaft geführt werden muss. Ein Add-on kann dennoch geschäftskritisch sein; es braucht dann dieselbe Klarheit zu Owner, Test, Release, Betrieb und Exit.

Fazit für Entscheider

Nicht Suite oder Best-of-Breed ist die erste Entscheidung.

Eine belastbare Maschinenbauarchitektur beginnt mit vier Verantwortungsbereichen: Markt und Vertrieb, Produktentwicklung und Engineering, Auftrag und Produktion sowie Service und Lifecycle. CRM, CPQ, PIM, PLM/CAD, ERP, MES und Service-Systeme sind Mittel, um deren Aufgaben und Ergebnisobjekte dauerhaft zu beherrschen.

Nicht jedes Unternehmen braucht jede Rolle als eigene Anwendung. Ein CTO-orientierter Serienmaschinenbauer kann mit einem integrierten Kern richtig liegen; ein komplexer CTO-/ETO-Anbieter benötigt eher differenzierte Domänen. Beide Zielbilder scheitern, wenn mehrere Systeme dieselbe Produktlogik oder denselben Freigabestand unabhängig führen.

Die Architekturentscheidung lautet deshalb nicht zuerst Suite oder Best-of-Breed. Sie lautet: Welches Objekt wird wo verbindlich, wer verantwortet seine Änderung und welche nächste Rolle darf es ohne erneute Interpretation übernehmen?

Der Backbone ist tragfähig, wenn die Systemlandschaft ein gemeinsames Produkt- und Auftragsverständnis erzeugt – nicht nur technisch verbundene Anwendungen.

English Executive Summary

The Digital Product Backbone in Industrial Machinery

A digital product backbone is not a single suite, a central database or the longest possible chain of applications. It is the binding architecture of leading system roles, product objects, responsibilities and controlled handovers that connects market-facing work, engineering, order fulfilment, production and service throughout the product lifecycle.

Four responsibility domains must be covered. Market and sales manage customer context, needs, configuration, pricing and publishable product information. Development and engineering establish the approved technical baseline across mechanical, electrical and software disciplines. Order and production turn this definition into an executable order structure and confirm what was actually built and tested. Service and lifecycle management maintain the installed asset, its changes and the valid replacement or retrofit options.

CRM, CPQ, PIM, PLM, CAD, ERP, MES and service systems therefore perform different core tasks. Not every company needs each role as a separate application. Overlap is acceptable when systems serve different purposes or validity contexts. It becomes critical when several systems maintain independent originals of the same product logic, price rule, structure or release status.

Two target architectures can be equally valid. A CTO-oriented series machinery manufacturer may benefit from an integrated core in which ERP configuration, a lean selling front end and compact engineering and service roles share a controlled release chain. A complex CTO/ETO portfolio may require differentiated domains with dedicated CPQ, PLM, MES and installed-base capabilities. The latter provides greater functional depth but also creates more interfaces, release dependencies and ownership requirements.

The primary architecture decision is therefore not suite versus best of breed. It is which business-critical object becomes binding in which role, who may change and approve it, and how the next domain can consume it without reinterpreting the decision. The backbone is robust when the system landscape creates a shared product and order understanding – not merely technically connected applications.

Weiterführende Insights

Position: Säule 3 · Produktstrukturen und Systemdurchgängigkeit · Beitrag 1 von 3

• Insight 205 – Produktkonfiguration zwischen Vertrieb, Technik und Produktion – warum Durchgängigkeit an der Struktur entscheidet, nicht an der Schnittstelle.
• Insight 302 – Vom Kundenversprechen zur installierten Maschine – der Datendurchlauf am Beispiel einer Verpackungsmaschine.
• Insight 303 – Wie viel Software-Ökosystem braucht ein variantenreicher Maschinenbauer?
• Insight 207 – S/4HANA-Migration und CPQ-Zielarchitektur – wann ein separates CPQ erforderlich bleibt und wann ein schlanker Frontend-Ansatz genügt.

Vorheriger Beitrag: — Auftakt der Säule

Nächster Beitrag: Insight 302 – Vom Kundenversprechen zur installierten Maschine

Zur Übersicht aller Executive Insights