Stücklisten-Analyse automatisieren

Das echte Ausmaß des Problems

In der Elektrotechnik sind Stücklisten keine simplen Einkaufslisten, sie sind verbindliche technische Dokumente, die mehrfach geprüft, freigegeben und versioniert werden müssen. In einem typischen Schaltschrankprojekt mit 300–1.000 Positionen sind Fehler bei manueller Prüfung fast unvermeidbar: Verwechslungen zwischen ähnlich klingenden Bauteilen, veraltete Typenbezeichnungen nach Lieferantenwechsel, Normabweichungen bei Übernahme von Positionen aus alten Projekten.

Wie viel Arbeitszeit von Konstrukteuren und Projektingenieuren in BOM-Pflege, Revisionsprüfung und Normabgleich fließt, weiß kaum ein Betrieb genau, und eine belastbare Branchenerhebung dazu haben wir nicht gefunden. Jonas’ Nachmittag oben ist die bessere Messlatte: 200 Positionen in zweieinhalb Stunden, für 847 Positionen also mehr als ein voller Arbeitstag. Für Fehler, die erst in der Fertigung auffallen, gilt im Qualitätsmanagement die Faustregel der Zehnerregel: Jede Phase, die ein Fehler weiterwandert, macht seine Korrektur um ein Vielfaches teurer, weil Teilebestellungen, Montagezeiten und Projektverzögerungen hinzukommen. Das ist eine Daumenregel, keine Messung für die Elektrotechnik.

Der strukturelle Grund für den hohen Fehleranteil liegt nicht an mangelnder Sorgfalt, sondern am Format: Excel-Tabellen haben keine eingebaute Validierung gegen Normbibliotheken oder aktuelle Einkaufspreislisten. Jede Prüfung ist manuell, jede Prüfung ist subjektiv, und jede Prüfung ist vom Wissensstand der prüfenden Person abhängig.

Mit vs. ohne KI, ein ehrlicher Vergleich

¹ Für die Fehlerquote vor und nach der Einführung gibt es keine belastbare Branchenzahl. Jonas’ Auftrag oben hatte drei Fehler auf 847 Positionen, rund 0,4 Prozent. Zähle deine eigene Quote über die Nacharbeitsmeldungen der Fertigung, bevor du dir ein Ziel setzt.

Einschätzung auf einen Blick

Zeitersparnis, hoch (4/5) Was ein Ingenieur 4–8 Stunden kostet, dauert mit automatisierter BOM-Prüfung noch ein bis zwei Stunden, weil nur die markierten Positionen von Hand geprüft werden. Direkt und je Revision messbar. Knapp unter der Spitze, weil der Spezifikations-Generator ganze Lastenheft-Kapitel erstellt, ein noch größerer Einzelhebel pro Dokument, und damit auf dieser Achse die Führung hält.

Kosteneinsparung, mittel (3/5) Die Einrichtungskosten für eine ERP-integrierte BOM-Analyse liegen bei 15.000–40.000 Euro, nicht trivial. Der Nutzen entsteht über freie Ingenieursstunden, die erst dann Geld sind, wenn die Konstruktion euer Engpass ist, und über vermiedene Fehlerfolgekosten in der Fertigung, die schwer direkt zu messen sind. Wer nie konsequent erfasst hat, wie viel Nacharbeit durch BOM-Fehler entsteht, hat Schwierigkeiten, den vollen ROI nachzuweisen. Im Vergleich zu anderen Anwendungsfällen in diesem Bereich ist der monetäre Effekt real, aber nicht sofort sichtbar.

Schnelle Umsetzung, mittel (3/5) Die ERP-Anbindung und Konfiguration der Prüfregeln braucht realistisch 6–10 Wochen. Ohne ERP-Integration (z.B. Excel-basierter Einstieg per ChatGPT oder Claude ) geht es schneller, bringt aber nur einen Teil des Potenzials. Für den vollen Automatisierungsgrad inklusive Normabgleich und Preisprüfung ist technische Integration unvermeidbar.

ROI-Sicherheit, hoch (4/5) Der Nutzen ist gut messbar: Prüfstunden vor und nach der Einführung, Fehleranzahl in freigegebenen BOMs, Anzahl der Nacharbeiten wegen BOM-Fehler. Damit ist der Nachweis gegenüber der Geschäftsführung vergleichsweise einfach, ein klarer Vorteil gegenüber Use Cases, deren ROI primär über schwer messbares Wissensmanagement entsteht.

Skalierbarkeit, hoch (4/5) Ein einmal eingerichtetes BOM-Analyse-System läuft auf jede neue Produktlinie, jeden neuen Kundenauftrag und jede neue Normversion. Die Regelbibliothek muss bei Normaktualisierungen gepflegt werden, das ist der begrenzende Faktor. Ohne laufende Pflege der Prüfregeln verliert das System über Zeit an Genauigkeit.

Richtwerte, stark abhängig von ERP-Landschaft, Produktkomplexität und Normvielfalt.

Was das System konkret macht

Eine automatisierte BOM-Analyse-Lösung arbeitet typischerweise auf drei Ebenen:

Ebene 1, Formale Validierung: Das System prüft jede Position auf Vollständigkeit (sind alle Pflichtfelder belegt?), auf konsistente Typenbezeichnungen (entspricht die Formatierung dem Normmuster?) und auf logische Widersprüche (passt die Nennspannung zum angegebenen Bauteiltyp?). Diese Ebene ist regelbasiert und liefert sehr hohe Treffsicherheit.

Ebene 2, Norm- und Katalogabgleich: Das System vergleicht jede Position gegen eine hinterlegte Normbibliothek (z.B. DIN VDE 0100, IEC 60947 für Schaltgeräte) und den aktuellen Einkaufskatalog. Veraltete Typenbezeichnungen werden markiert, Nachfolgeteile vorgeschlagen, nicht mehr verfügbare Artikel sofort gekennzeichnet.

Ebene 3, Semantische Analyse via LLM: Bei unstrukturierten Feldern, Freitextkommentaren und importierten Kundenstücklisten hilft ein Generative KI-Modell dabei, Felder zu interpretieren, Tippfehler zu erkennen und abweichende Schreibweisen desselben Bauteils zu normalisieren. Hier liegt auch das Kostenoptimierungspotenzial: Das System erkennt technisch gleichwertige Bauteile unterschiedlicher Hersteller und schlägt preisgünstigere Alternativen vor.

Das Ergebnis ist ein prüfbarer Report, der für jede Position den Prüfstatus zeigt und begründete Handlungsempfehlungen liefert, kein Blackbox-Urteil, sondern transparent nachvollziehbare Ergebnisse, die der Konstrukteur bestätigen oder ablehnen kann.

Konkrete Werkzeuge, was wann passt

Siemens Teamcenter , für integriertes PLM und BOM-Management Das meistgenutzte PLM-System in der deutschen Elektrotechnikindustrie. Teamcenter verwaltet BOM-Revisionen, Freigabeprozesse und Engineering Change Orders in einem System. Seit 2024 verfügt es über einen KI-Copilot, der natürlichsprachliche BOM-Abfragen erlaubt. Sinnvoll ab ca. 100 Mitarbeitenden mit mehreren Produktlinien. Einrichtung: 12–24 Monate, Kosten: fünf- bis sechsstellig jährlich.

SAP Digital Manufacturing , für SAP-S/4HANA-Umgebungen Wer bereits auf SAP setzt, kann BOM-Validierung direkt in den SAP-Workflow integrieren. Digital Manufacturing ist SAPs Cloud-MES: Es übernimmt die Fertigungsstückliste aus S/4HANA auf den Shopfloor und bringt Analysen über die eingebettete SAP Analytics Cloud mit. Die Prüfung der Konstruktionsstückliste selbst liegt davor, in S/4HANA oder im PLM. Nur sinnvoll als Teil eines bestehenden SAP-Ökosystems, als reines BOM-Prüfwerkzeug ist es zu groß.

Claude + Make.com , für einen schnellen, leichtgewichtigen Einstieg Wer ohne ERP-Integration starten will: BOM als CSV oder Excel exportieren, via API oder Make.com an ein LLM schicken, das gegen eine hinterlegte Regelbeschreibung prüft. Kein vollautomatischer Prozess, aber für Teams ohne PLM-System ein gangbarer erster Schritt. Einrichtungszeit: 1–2 Wochen. Preis: Make.com ab 9 USD/Monat plus API-Kosten je nach BOM-Volumen (siehe Kosten unten).

Microsoft 365 Copilot , für Excel-basierte BOM-Workflows Wenn BOMs als Excel-Dateien in SharePoint leben, kann M365 Copilot bei Abfragen, Formatprüfungen und Konsistenzcheck assistieren. Kein tiefes Normverständnis, aber hilfreich für formale Validierung. Kosten: 18,20 Euro je Person und Monat im Jahresabo (Aktionspreis 15,60 Euro, nur im ersten Jahr und nur bis 31.12.2026), im Enterprise-Plan 26,00 Euro, jeweils zusätzlich zur M365-Lizenz und zzgl. MwSt.

Wann welcher Ansatz:

• Teamcenter-Umgebung vorhanden → Teamcenter Copilot nutzen und ausbauen
• SAP-Umgebung vorhanden → SAP Digital Manufacturing
• PLM fehlt, Volumen gering → Claude + Make.com als Einstieg
• Microsoft 365 als primäres Tool → M365 Copilot

Datenschutz und Datenhaltung

Stücklisten in der Elektrotechnik enthalten oft vertrauliche Konstruktionsdaten, Preise, Lieferanteninformationen und IP-relevante Bauteilkonfigurationen. Das bedeutet: Bevor ihr BOMs in Cloud-KI-Dienste einspeist, muss die Frage beantwortet sein, wo diese Daten landen.

Für PLM-Systeme wie Siemens Teamcenter und SAP Digital Manufacturing gilt: EU-Datenhosting ist verfügbar und Standard in deutschen Installationen. DSGVO-Anforderungen sind durch die On-Premises-Option vollständig erfüllbar.

Beim Einsatz von Cloud-LLMs (ChatGPT, Claude API, Microsoft Copilot) gilt: Stücklisten sind in aller Regel Geschäftsgeheimnisse. Den Schutz des GeschGehG gibt es aber nur, solange ihr angemessene Geheimhaltungsmaßnahmen trefft, und eine BOM im privaten Chatbot-Konto ist das Gegenteil davon. Ihr solltet klären, ob der Cloud-Anbieter die Daten für Modelltraining nutzt, und das per AVV und Nutzungsbedingungen dokumentieren. Microsoft 365 Copilot mit EU-Datengrenze liegt für Microsoft-Häuser nahe, mit einer Einschränkung: Flexibles Routing kann die Verarbeitung bei Spitzenlast in die USA, nach Kanada oder Australien verlegen und ist bei neuen Mandanten voreingestellt. Für besonders sensible Produktdaten empfehle ich eine eigene Instanz in der EU-Region mit vertraglichem Trainingsausschluss (z.B. Azure OpenAI Service ) oder ein lokal betriebenes Modell.

Was es kostet, realistisch gerechnet

Einmalige Einrichtungskosten

• ERP/PLM-integrierte Lösung: 15.000–40.000 Euro Implementierung, je nach Komplexität der Regelkonfiguration und Schnittstellen
• LLM-basierter Einstieg ohne ERP-Integration: 3.000–8.000 Euro für Regelwerk-Entwicklung und Prompt-Engineering

Laufende Kosten (monatlich)

• Siemens Teamcenter: Die PLM-Lizenz selbst läuft ohnehin, der Teamcenter Copilot ist aber ein modulweise lizenziertes Add-on mit Aufpreis, Preis auf Anfrage
• SAP Digital Manufacturing: nicht in der S/4HANA-Lizenz enthalten, sondern eine eigene Cloud-Subscription. SAP listet rund 11.314 USD pro Monat je 100 Mio. USD Warenherstellungskosten im Jahr, verhandelt wird im SAP-Gesamtvertrag
• LLM-API-Kosten (Claude/ChatGPT): 30–150 Euro/Monat je nach BOM-Volumen, dazu Make.com ab 9 USD/Monat
• Regelpflege: Normbibliothek und Bauteilkatalog quartalsweise prüfen (siehe Einstiegsfehler 3), das ist Arbeitszeit, die ihr einplanen müsst

Nutzenrechnung, mit offenen Annahmen 3 Ingenieure prüfen je 4 BOMs pro Monat zu je 5 Stunden = 60 Ingenieursstunden im Monat, 144 Revisionen im Jahr. Das ist fast das Dreifache der Schwelle, ab der sich das Ganze laut Ausschlusskriterium unten überhaupt erst lohnt, also kein vorsichtiges, sondern ein gut ausgelastetes Szenario. Bei 75 % Reduktion werden 45 Stunden im Monat frei, zu 45 Euro Arbeitgeberkosten je Stunde rund 2.000 Euro.

Das ist Kapazität, kein Geld auf dem Konto: Die drei Gehälter laufen weiter. Zu Geld werden die Stunden erst, wenn die Konstruktion euer Engpass ist und die Zeit nachweislich in zusätzliche Aufträge fließt, Überstunden abbaut oder eine geplante Einstellung überflüssig macht. Unter dieser Bedingung trägt sich der LLM-Einstieg (3.000–8.000 Euro Einrichtung, rund 40–150 Euro laufend im Monat) nach ein bis vier Monaten, die ERP-Variante mit 15.000 Euro Einrichtung nach rund acht Monaten, mit 40.000 Euro nach knapp zwei Jahren, jeweils vor Regelpflege und etwaigen Modulaufpreisen. Ohne diese Bedingung bleibt als harter Rückfluss nur, was ihr an Fehlerfolgekosten in der Fertigung vermeidet, und den kennt nur, wer Nacharbeit wegen BOM-Fehlern heute schon zählt.

Wie du den Nutzen tatsächlich misst Erfasst vor der Einführung die durchschnittliche Prüfzeit pro BOM-Revision und die Anzahl der Nacharbeiten wegen BOM-Fehlern. Die gleichen KPIs nach 3 Monaten Betrieb geben dir einen ehrlichen Vergleich, ohne Interpretation, direkt aus den Projektdaten.

Typische Einstiegsfehler

1. Mit einer globalen Regelkonfiguration für alle Produktlinien starten. Der Reflex: eine universelle Prüfregel, die für alle Projekte gilt. In der Praxis haben verschiedene Produktlinien unterschiedliche Normanforderungen, eine Niederspannungsanlage für den Wohnungsbau läuft nach anderen Regeln als eine industrielle Steuerungstechnik. Wer das nicht trennt, bekommt entweder zu viele Fehlalarme oder übersieht reale Probleme. Lösung: Mit der Produktlinie starten, bei der BOMs am häufigsten und mit den höchsten Folgekosten falsch sind.

2. Kein Feedback-Loop für falsch positive Meldungen einplanen. KI-Prüfungen sind nicht unfehlbar, sie werden anfangs Positionen als fehlerhaft markieren, die korrekt sind (z.B. Sondertypen ohne Datenbankeinträge). Wenn Ingenieure diese Falschmeldungen nicht systematisch zurückmelden, verbessert sich das System nicht. Ohne aktives Feedback-Management sinkt die Akzeptanz, weil “das System immer falsch liegt”. Lösung: Ein einfaches Feedback-Formular direkt im Prüfreport, “korrekt” oder “Fehlalarm mit Begründung”, und monatliche Regelüberprüfung.

3. Die Normbibliothek einmal einrichten und dann vergessen. Das ist der teuerste Fehler, weil er still passiert. IEC- und VDE-Normen werden aktualisiert, Typenbezeichnungen ändern sich bei Lieferantenwechsel, neue Bauteilgenerationen kommen hinzu. Ein System mit veralteten Prüfregeln gibt nach 12–18 Monaten systematisch veraltete Empfehlungen, und das Schlimmste: es klingt weiterhin zuverlässig. Lösung: Normbibliothek und Bauteilkatalog quartalsweise überprüfen. Wer entscheidet, ob die Daten aktuell sind? Diese Frage muss vor dem Launch beantwortet sein.

4. Excel-Import ohne Datenqualitätsprüfung. Wenn Kundenstücklisten in verschiedenen Formaten importiert werden, variiert die Datenqualität erheblich, manche haben Spaltenüberschriften auf Englisch, andere nutzen hausinternen Kürzeln, wieder andere mischen Leerzeichen in Typenbezeichnungen. Wer das System ohne Normalisierungsschritt betreibt, kämpft dauerhaft mit schlechter Erkennungsqualität. Lösung: Datenqualitäts-Pipeline vor der eigentlichen Analyse definieren, was muss bereinigt werden, bevor das Prüfsystem seine Arbeit tun kann?

Was mit der Einführung wirklich passiert, und was nicht

Die Technik löst das Prüfproblem gut. Was sie nicht löst: die Frage, wem die Ergebnisse gehören und wer bei Konflikten entscheidet.

Konstrukteure werden die ersten Prüfergebnisse kritisch beäugen, und in vielen Fällen zu Recht. Ein System, das Normpositionen anhand von Datenbankeinträgen prüft, kennt keine Sonderfreigaben, keine firmeninternen Abweichungshistorien und keine kundenseitig akzeptierten Alternativen. Diese Kontextlücken sind real und müssen in den Prüfprozess eingebettet werden.

Was hilft: Die Prüfergebnisse als “Prüfvorschlag mit Begründung” positionieren, nicht als “Entscheidung des Systems”. Der Ingenieur bleibt verantwortlich für die BOM, das System liefert ihm einen besseren Startpunkt. Diese Positionierung klingt wie eine Kleinigkeit, entscheidet aber über Akzeptanz oder Boykott.

Was nicht hilft: Das System als Kontrollmechanismus für Ingenieursfehler einführen. Wer das intern so kommuniziert, baut Abwehrhaltung auf, die schwer wieder abzubauen ist.

Realistischer Zeitplan mit Risikohinweisen

Häufige Einwände, und was dahintersteckt

“Unsere Stücklisten sind zu individuell für ein standardisiertes Prüfsystem.” Stimmt teilweise, aber ein großer Teil der Prüfregeln gilt produktlinienübergreifend: formale Vollständigkeit, Normbezeichnungen, Verfügbarkeitsprüfung. Die individuellen Regeln kommen als Erweiterungsschicht dazu. Ein System muss nicht alles auf einmal können, um sofort Mehrwert zu liefern.

“Das erhöht nur den Aufwand, weil wir jetzt Falschmeldungen abarbeiten müssen.” Das ist ein valides Risiko in den ersten Wochen, und ein Zeichen, dass die Regel-Kalibrierung noch nicht abgeschlossen ist. Die Fehlalarmrate sinkt, sobald Sondertypen und Ausnahmen dokumentiert sind. Wie schnell, hängt davon ab, wie konsequent die Konstrukteure Fehlalarme zurückmelden, also zähle sie ab der ersten Woche. Wer nach drei Monaten noch viele Falschmeldungen hat, hat ein Konfigurationsproblem, kein KI-Problem.

“Das funktioniert nur bei standardisierten Produkten, nicht bei kundenspezifischen Sonderprojekten.” Gerade bei Sonderprojekten, wo BOMs häufig aus Teilen verschiedener Vorprojekte zusammengestellt werden, ist das Fehlerrisiko am höchsten, und der Prüfaufwand am größten. Die formale Validierungsebene funktioniert unabhängig vom Projekttyp.

Woran du merkst, dass das zu dir passt

• Du hast Ingenieure, die regulär 4–8 Stunden pro BOM-Revision für Prüftätigkeiten aufwenden, und dabei trotzdem Fehler übersehen
• Eure Fertigung meldet regelmäßig Nacharbeiten, die auf fehlerhafte Stücklistenpositionen zurückgehen
• Ihr pflegt BOMs in mehreren Systemen (PLM, ERP, Excel) und verliert bei Revisionen die Versionskontrolle
• Ihr habt Kunden, die Stücklisten in ihren eigenen Formaten einreichen und ihr diese mühsam in euer System übernehmen müsst
• Neue Ingenieure brauchen Monate, um die interne Normlogik und die Bauteil-Namenskonventionen zu verinnerlichen

Wann es sich noch nicht lohnt, drei harte Ausschlusskriterien:

1. Unter 50 BOM-Revisionen pro Jahr. Der Einrichtungsaufwand amortisiert sich nicht. Für kleine Betriebe mit wenigen Projekten reicht eine gut gepflegte Excel-Vorlage mit integrierten Validierungsformeln.

2. Keine strukturierten Daten im ERP oder PLM. Wenn Bauteilkataloge, Normversionen und Preislisten nicht digital und strukturiert vorliegen, also wenn das Wissen hauptsächlich in Köpfen und physischen Ordnern steckt, dann ist der erste Schritt Datendigitalisierung, nicht KI-Analyse. Das System kann nur prüfen, was es kennt.

3. Kein dedizierter Verantwortlicher für Regelbibliothek und Systemwartung. Ein BOM-Analyse-System, das eingerichtet und dann sich selbst überlassen wird, gibt nach 12–18 Monaten falsche Empfehlungen auf Basis veralteter Normen. Ohne eine namentlich benannte Person mit Pflegeverantwortung wird das System zur Haftungsfalle statt zur Effizienzlösung.

Das kannst du heute noch tun

Du brauchst keine ERP-Integration, um das Konzept zu testen. Exportiere eine BOM aus Excel oder deinem PLM als CSV und nutze den folgenden Prompt, um die Analyse zu starten. Nimm dafür eine abgeschlossene Stückliste oder entferne vorher Preise, Lieferantenkonditionen und Kundennamen, und nutze einen Business-Zugang, dessen Eingaben nicht ins Modelltraining fließen (siehe Datenschutz oben):

Quellen & Methodik

• Prüfzeiten und Fehlerquoten: Für beides haben wir keine belastbare Branchenerhebung gefunden. Die Prüfzeiten in der Tabelle sind Richtwerte für eine Stückliste mit 500 Positionen, die 75 Prozent Reduktion in der Nutzenrechnung eine Annahme. Miss beides vor dem Start im eigenen Haus.
• Fehlerfolgekosten: Zehnerregel der Fehlerkosten, eine Faustregel aus dem Qualitätsmanagement, keine Messung für elektrotechnische Projekte.
• Tool-Preise: Microsoft-Preisseiten zu Copilot Business und Microsoft 365 Copilot (Stand 17.09.2026), SAP Store zu SAP Digital Manufacturing (Stand Juli 2026), Make.com-Preisseite. Siemens veröffentlicht für Teamcenter und den Copilot keine Listenpreise. Einzelheiten und Links auf unseren Toolseiten.
• Implementierungskosten: Richtwerte für ERP/PLM-Integrationsprojekte im deutschen Mittelstand (Stand April 2026), kein Angebot. Holt vor einer Entscheidung zwei Angebote ein.

Willst du wissen, ob dieser Ansatz für eure Produktlinien skaliert, und welche ERP/PLM-Schnittstellen bei euch am sinnvollsten wären? Schreib uns, wir schauen uns euren konkreten Setup gemeinsam an.