PLM und ERP: Wo die Grenze verläuft

Drei Szenarien, ein Muster

Ein ERP ist kein schlechtes PLM – es ist für eine andere Aufgabe gebaut. Das wird meist erst dann sichtbar, wenn etwas schiefgeht.

Ein Konstrukteur tauscht in CAD eine Komponente. Drei Wochen später kommt eine Reklamation – die Fertigung hat noch die alte Variante gebaut.

In einer Rezeptur wird ein Rohstoff aus regulatorischen Gründen ersetzt. Bei einem Audit kann niemand zweifelsfrei sagen, welche produzierte Charge die neue Variante enthielt.

Ein erfahrener Mitarbeiter geht in Rente. Sechs Monate später soll ein Bestandsprodukt überarbeitet werden – die Auslegungsentscheidungen von damals findet niemand wieder.

Drei verschiedene Branchen, drei verschiedene Symptome, eine gemeinsame Ursache: ein System, das eine Aufgabe übernehmen soll, für die es nicht gebaut wurde.

Dieser Artikel beschreibt die Aufgabentrennung zwischen ERP und PLM (Product Lifecycle Management) für fertigende KMU. Nicht als Feature-Vergleich, sondern entlang der Fragen: Was kann ein ERP strukturell nicht leisten? Wo entstehen daraus reale Kosten? Und wann ist der Punkt erreicht, an dem ein eigenes System für die Produktdaten betriebswirtschaftlich notwendig wird?

Was beide Systeme tatsächlich verwalten

ERP-Systeme verwalten den operativen Ist-Zustand eines Unternehmens: Aufträge, Bestände, Buchungen, Ressourcen. Sie beantworten Fragen wie Wer hat was bestellt? Was haben wir auf Lager? Was kostet die Produktion? Ein ERP ist ein transaktionsorientiertes System, das den laufenden Betrieb abwickelt.

PLM-Systeme verwalten die Produktdefinition im Soll-Zustand: Anforderungen, Konstruktion, Versionen, Freigaben, Änderungen, Nachweise – über den gesamten Lebenszyklus hinweg. Sie beantworten Fragen wie Wie ist dieses Produkt entstanden? Welche Version ist gültig? Wer hat was wann geändert und warum? Ein PLM ist ein objektorientiertes System, das die Produktdefinition pflegt.

ERP-Daten beschreiben, was passiert ist. PLM-Daten beschreiben, was ein Produkt ist und wie es so wurde. Die Lücken zwischen diesen beiden Sichten sind keine Konfigurationsfragen – sie sind architektonisch.

Vier Grenzen klassischer ERP-Systeme

1. Engineering-Daten und Konstruktionskontext

Im ERP existiert die freigegebene Stückliste. Was dort nicht existiert: das CAD-Modell, die Berechnungen, die Materialspezifikationen, die Prüfberichte, die abhängigen Dokumente. ERP weiß, dass eine Baugruppe aus drei Teilen besteht. ERP weiß nicht, warum sie aus drei und nicht aus zwei besteht.

Praktisch: Wenn ein Kunde drei Jahre nach der Auslieferung mit einem Problem zurückkommt, will jemand wissen, welche Variante damals gebaut wurde, gegen welche Norm sie ausgelegt war und welche Tests durchgeführt wurden. Im ERP findet sich der Lieferschein. Alles andere liegt irgendwo.

2. Änderungsmanagement

Im ERP existieren typischerweise die alte und die neue Stückliste. Wer den Wechsel angestoßen hat, welche Alternativen geprüft wurden, welche Tests ungültig geworden sind, welche Auswirkungen es auf andere Produkte gibt – ist in klassischen ERP-Systemen nicht abgebildet.

PLM verwaltet Änderungen als eigene Objekte: Change Request, Wirkungsanalyse, betroffene Objekte, Freigaben, abhängige Dokumente. Eine Materialsubstitution ist dann kein stilles Update einer Stückliste, sondern ein nachvollziehbarer Vorgang mit Begründung, Prüfung und Freigabe.

3. Traceability auf Definitionsebene

Lebensmittel, Kosmetik, Medizintechnik und zunehmend Elektronik unterliegen strengen Nachweispflichten. ERP kann auf Transaktionsebene tracen: welche Charge eines Rohstoffs in welche Charge eines Produkts geflossen ist. Das reicht für klassisches Batch-Tracing.

Was es nicht leistet: die Verbindung zwischen Substanzklassen, regulatorischen Anforderungen, Spezifikationsversionen und Produktvarianten. Bei einer Anfrage „Welche Produkte enthalten Substanz X gemäß welcher Spezifikation in welcher gültigen Version?“ arbeitet ERP nicht mit – nicht weil es falsch konfiguriert wäre, sondern weil seine Datenstruktur diese Beziehungen nicht kennt.

4. Wissen, das nicht mit Personen geht

In KMU sitzt erfahrungsgemäß ein erheblicher Teil des Produktwissens in Köpfen. Welche Auslegungsentscheidung damals warum so getroffen wurde, welche Lieferantenalternativen ausprobiert und verworfen wurden, welche Spezialwerkzeuge für eine bestimmte Variante nötig sind – all das ist implizit.

PLM macht dieses Wissen explizit und versionsfest. Nicht durch zusätzliche Pflichteingaben in Formulare, sondern indem es die natürlichen Artefakte der Produktentwicklung (CAD, Dokumente, Änderungen, Entscheidungen) strukturiert und mit den Produktobjekten verknüpft.

Was die vier Lücken verbindet: Der digitale Faden

Die vier Lücken sind keine vier Probleme, sondern vier Symptome desselben Problems: Produktinformationen liegen verteilt, ohne durchgehende Identität. Die Konstruktionszeichnung weiß nicht, dass sie zur Stückliste gehört. Die Stückliste weiß nicht, dass es ein Prüfprotokoll dafür gibt. Das Prüfprotokoll weiß nicht, gegen welche Norm es geprüft hat.

Der digitale Faden – Digital Thread – ist die Vorstellung, dass jede Information entlang des Produktlebenszyklus auffindbar und kontextualisiert bleibt: vom Lastenheft über die Konstruktion und Fertigung bis zum Service und zurück in die nächste Produktgeneration.

Für ein KMU bedeutet das nicht „Industrie 4.0 End-to-End“, sondern etwas Konkreteres: Jede Produktversion ist eindeutig identifizierbar. Jede Änderung ist nachvollziehbar. Jedes Dokument ist an die richtige Variante gebunden. Diese Eigenschaften klingen banal, sind aber in den meisten KMU heute nicht gegeben – und ohne PLM auch nicht herstellbar, weil sie eine objektorientierte, versionsfähige Datenstruktur voraussetzen, die ERP nicht hat.

Datenstruktur als Voraussetzung für Automatisierung und KI

Der digitale Faden ist nicht nur eine Voraussetzung für menschliche Auffindbarkeit – er ist auch die Grundlage für jede Form der Automatisierung, KI-basiert oder nicht. Der Engpass liegt selten beim KI-Modell allein. Entscheidend ist, ob Produktdaten strukturiert, versioniert und nachvollziehbar vorliegen.

Wer KI auf ungepflegte PDFs, Excel-Stücklisten und Fileserver loslässt, bekommt nicht automatisch Wissen – oft nur schneller erzeugte Unsicherheit. Eine Anwendung, die auf strukturierten, versionierten, beziehungsorientierten Produktdaten arbeitet, kann dagegen nachvollziehbare Antworten geben – inklusive Quelle, Version und Reifegrad.

Konkret: Anfragen wie „Welche Produkte sind von der Substitution dieses Materials betroffen?“, „Erstelle einen Erstentwurf der Servicedokumentation für Variante X-127″ oder „Welche Produkte müssen neu zertifiziert werden, wenn Norm XYZ aktualisiert wird?“ sind technisch nicht möglich, solange die zugrundeliegenden Daten nicht in der Form vorliegen, die der digitale Faden beschreibt.

Der Mehrwert eines PLM liegt damit nicht in der KI-Fähigkeit selbst, sondern in der Datenkonsistenz und Nachvollziehbarkeit, die jede spätere Automatisierungsstufe erst ermöglicht.

Branchenspezifische Akzente

Maschinen- und Anlagenbau.

Variantenmanagement ist der dominante Treiber: kundenspezifische Konfigurationen, mehrere parallel laufende Versionsstränge, langlebige Produkte mit Serviceanforderungen über Jahrzehnte. Die Trennung zwischen Konstruktions-Stückliste (eBOM) und Fertigungs-Stückliste (mBOM) ist hier oft der erste Schmerzpunkt, an dem ERP sichtbar an Grenzen stößt.

Lebensmittel.

Rezeptmanagement mit Allergen- und Nährwertberechnung, Etikettierungspflichten nach EU 1169/2011, Traceability nach EU 178/2002, Reformulationen aus Kostengründen oder regulatorischen Vorgaben. Eine Rezeptur ist hier ein eigenständiges Objekt mit Version, Freigabestand und regulatorischem Kontext – nicht eine Stückliste im klassischen Sinn.

Kosmetik.

INCI-Deklarationen, marktspezifische Regulatorik (EU, UK, CH, US, GCC), CPNP-Notifizierungen, Substitution verbotener oder eingeschränkter Stoffe. Die Komplexität steckt nicht in der Produktstruktur, sondern in den regulatorischen Beziehungen, die eine Formulierung pflegen muss.

High-Tech und Elektronik.

Bauteil-Obsoleszenz (Komponenten fallen mitten im Produktlebenszyklus aus dem Markt), Hardware-Firmware-Bindung, Compliance gegen RoHS, REACH, IEC. Der Lebenszyklus des Endprodukts ist hier oft länger als der Lebenszyklus seiner Bestandteile – eine Aufgabe, die klassisches ERP nicht adressiert.

Allen vier Branchen gemeinsam: Die Produktdefinition ist komplexer als der Auftragsabwicklungsprozess. Wer nur ERP betreibt, hat sein einfacheres Problem gut gelöst – und sein eigentliches Problem unbearbeitet gelassen.

Regulatorische Anforderungen: DPP und branchenspezifische Vorgaben

Digital Product Passport (DPP) unter der ESPR.

Die EU-Verordnung über Ökodesign nachhaltiger Produkte (ESPR) ist 2024 in Kraft getreten. Sie schafft den Rahmen für Ökodesign-Anforderungen und digitale Produktpässe.

Welche Produktgruppen konkret betroffen sind, wird schrittweise festgelegt – über eigene Rechtsakte je Produktgruppe. Der EU-Arbeitsplan 2025–2030 nennt als Priorität unter anderem Textilien, Möbel, Matratzen, Reifen sowie Eisen, Stahl und Aluminium. Für Elektro- und Elektronikprodukte kommen übergreifende Anforderungen hinzu: Reparierbarkeit, Rezyklierbarkeit und Rezyklatanteil. Lebensmittel, Futtermittel und Arzneimittel fallen nicht unter die ESPR.

Der Batteriepass gilt ab dem 18. Februar 2027, zunächst für bestimmte Batteriekategorien: Batterien für leichte Elektrofahrzeuge (etwa E-Bikes und E-Scooter), Industriebatterien über 2 kWh und Elektrofahrzeugbatterien. Relevant ist er für Hersteller, die solche Batterien selbst in Verkehr bringen – oder die in der Lieferkette die nötigen Nachweise liefern müssen.

Technisch betrachtet ist der DPP eine Datenarchitektur-Anforderung. Verifizierte, strukturierte Daten zu Materialien, Herkunft, Reparierbarkeit, Recyclingfähigkeit und vielem mehr müssen auf Produktdefinitionsebene konsistent gepflegt und über den Lebenszyklus aktuell gehalten werden. Klassische ERP-Systeme adressieren die Transaktionsebene; diese Datenstruktur können sie nicht abbilden. Branchenkenner schätzen, dass der Aufbau einer DPP-fähigen Datenbasis 12 bis 18 Monate Vorlauf erfordert – inklusive Lieferantendaten-Erhebung und Schema-Definition.

Branchenspezifische Vorgaben bleiben relevant.

REACH und RoHS in High-Tech, die Verordnungen 1169/2011 (Kennzeichnung) und 178/2002 (Rückverfolgbarkeit) in Lebensmitteln, die Kosmetikverordnung 1223/2009 mit Meldung über das CPNP-Portal. Unabhängig von Vereinfachungen in der Nachhaltigkeitsberichterstattung bleiben viele produktbezogene Nachweispflichten bestehen – zu Inhaltsstoffen, Spezifikationen, Rückverfolgbarkeit, Kennzeichnung und technischen Dokumentationen.

Kundengetriebene Anforderungen.

Auch KMU, die selbst nicht berichtspflichtig sind, werden zunehmend von Großkunden um produktbezogene Nachhaltigkeitsdaten gebeten. Der freiwillige VSME-Standard wird hier zur faktischen Mindestanforderung. Die Daten, die solche Anfragen beantworten, sind genau die Daten, die ein PLM nativ strukturiert vorhält.

Wo ERP und PLM zusammenspielen

PLM ersetzt kein ERP. Die beiden Systeme bedienen unterschiedliche Phasen mit unterschiedlichen Anforderungen, und sinnvoll betrieben arbeiten sie zusammen.

Der typische Übergabepunkt ist die Produktfreigabe. PLM definiert, was das Produkt ist, in welcher Version, mit welchen Dokumenten, gegen welche Anforderungen geprüft. Bei Freigabe wandern die operativ relevanten Anteile – Materialstämme, Stücklisten, Routings – in das ERP, das daraufhin Beschaffung, Fertigung und Auslieferung steuert. Änderungen am freigegebenen Produkt laufen wieder durch das PLM und werden bei erneuter Freigabe synchronisiert.

Diese Arbeitsteilung ist nicht doppelte Datenhaltung, sondern Aufgabentrennung. Das ERP soll das nicht können, was das PLM kann – und umgekehrt. Wer das eine versucht mit dem anderen abzudecken, bekommt entweder ein träges ERP voller Sonderfelder oder ein PLM, das mit dem Buchhaltungsbeleg überfordert ist.

Versteckte Kosten ohne PLM

Die Kosten eines fehlenden PLM verteilen sich auf andere Konten und bleiben dort meist unsichtbar:

• Nacharbeit und Ausschuss durch veraltete Spezifikationen, falsche Stücklistenversionen oder unvollständig kommunizierte Änderungen.
• Verzögerte Time-to-Market durch unklare Verantwortlichkeiten in Freigabeprozessen und manuelle Datenpflege in mehreren Systemen.
• Audit- und Compliance-Aufwand, wenn jede Anfrage einer regulatorischen Stelle oder eines Großkunden Wochen an Recherche kostet, weil die Daten zusammengesucht werden müssen.
• Rückrufkosten im schlimmsten Fall – nicht, weil das Produkt mangelhaft war, sondern weil die Traceability nicht ausgereicht hat, um einen begrenzten Rückruf von einem flächendeckenden zu unterscheiden.
• Wissensverlust bei Mitarbeiterwechseln, der sich nicht beziffern lässt, bis das erste Bestandsprodukt überarbeitet werden soll und niemand weiß, warum es so konstruiert wurde.
• Schatten-IT in Form von Excel-Stücklisten, SharePoint-Strukturen und Fileserver-Ordnerlandschaften, die jedes mittelständische Konstruktionsbüro kennt.

Keine dieser Kostenarten ist katastrophal für sich. In Summe bindet das oft spürbare Engineering-, Qualitäts- und IT-Kapazität – ohne dass diese Kosten sauber als Produktdatenproblem sichtbar werden.

Reifezeichen: Wann braucht ein KMU PLM?

Eine kurze Checkliste zur Selbsteinschätzung. Wenn drei oder mehr Punkte zutreffen, ist die Diskussion über PLM überfällig:

• Stücklisten werden in Excel oder direkt im CAD-System gepflegt – ohne separates System für Versionierung und Freigabe.
• Es existieren mehrere Produktvarianten, die parallel betreut werden müssen.
• Änderungen werden per E-Mail oder Chat kommuniziert.
• Konstruktion und Einkauf arbeiten auf unterschiedlichen „richtigen“ Stücklisten.
• Ein Audit kostet regelmäßig mehrere Personen-Wochen.
• Mindestens ein Mitarbeiter hatte schon einmal die Rolle als „der einzige, der die Daten findet“.
• Anfragen von Kunden zu Compliance, Inhaltsstoffen oder Spezifikationen werden ad hoc beantwortet.
• Dieselbe Information wird an mehr als einer Stelle gepflegt – mit dem Risiko der Inkonsistenz.

Wie man einführt – nicht alles auf einmal

PLM-Einführungen scheitern selten an der Software. Sie scheitern an Big-Bang-Ansätzen: ein 18-Monats-Projekt, das alles auf einmal abdecken will und am Ende weder die ursprünglich definierten Anforderungen erfüllt noch die in der Zwischenzeit entstandenen.

Ein realistischer Weg sieht anders aus. Zuerst die Grundlage: Stammdaten, Stücklisten, Dokumente, CAD-Integration. Diese Phase liefert messbaren Wert – saubere Datenbasis, weniger Suchaufwand, definierter Freigabeprozess – und ist in wenigen Monaten produktiv. Erst danach kommen die nächsten Stufen: strukturiertes Änderungsmanagement, Varianten- und Konfigurationsmanagement, Qualitäts- und Compliance-Prozesse, Integration in ERP und nachgelagerte Systeme.

Dieser stufenweise Ansatz hat zwei Vorteile gegenüber dem Big-Bang. Erstens ist der Nutzen nach jeder Stufe für die Organisation spürbar – das hält die Akzeptanz hoch. Zweitens lässt sich nach der ersten Stufe deutlich besser einschätzen, was die nächste tatsächlich kosten wird, weil das Unternehmen inzwischen weiß, wie es mit dem System arbeitet.

Zum Schluss

Die Frage ist nicht „ERP oder PLM“.

ERP steuert Aufträge, Bestände, Beschaffung, Fertigung und Kosten. PLM hält die Produktdefinition zusammen: Versionen, Dokumente, Freigaben, Änderungen und Nachweise.

Für einfache Produkte und stabile Abläufe kann ERP lange ausreichen. Kritisch wird es, wenn Varianten, regulatorische Anforderungen, häufige Änderungen oder langlebige Produkte dazukommen. Dann entstehen Kosten nicht, weil ERP schlecht ist – sondern weil es eine Aufgabe übernehmen soll, für die es nicht gebaut wurde.

Der sinnvolle Einstieg ist deshalb kein Big-Bang-Projekt. Er beginnt mit einer klaren Frage: Welche Produktdaten müssen in Zukunft eindeutig, versioniert und nachvollziehbar sein?