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.

Laut Branchenerhebungen der deutschen Elektrotechnik-Verbände verbringen Konstrukteure und Projektingenieure durchschnittlich 25–30 Prozent ihrer Arbeitszeit mit administrativen und prüfenden Tätigkeiten, ein erheblicher Teil davon auf BOM-Pflege, Revisionsprüfung und Normabgleich. Fehler in Stücklisten, die erst in der Fertigung auffallen, kosten im Schnitt fünf- bis zwanzigfach so viel wie eine Korrektur in der Konstruktionsphase, weil Teilebestellungen, Montagezeiten und Projektverzögerungen hinzukommen.

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

¹ Erfahrungswerte aus Elektrotechnikunternehmen mit 80–500 Mitarbeitenden; keine repräsentative Studie, aber konsistente Beobachtungen in mehreren Implementierungen.

Einschätzung auf einen Blick

Zeitersparnis, hoch (4/5) Was ein Ingenieur 4–8 Stunden kostet, dauert mit automatisierter BOM-Prüfung unter einer Stunde. Direkt und täglich 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 eingesparte Ingenieursstunden und vor allem durch 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. Die KI-Analysefunktionen der eingebetteten SAP Analytics Cloud erkennen Anomalien in Stücklistenstrukturen. Nur sinnvoll als Teil eines bestehenden SAP-Ökosystems.

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: 20–50 Euro/Monat für API-Kosten.

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: ca. 30 Euro/Person/Monat zusätzlich zur M365-Lizenz.

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 und fallen unter das GeschGehG. Ihr solltet klären, ob der Cloud-Anbieter die Daten für Modelltraining nutzt, und das per AVV und Nutzungsbedingungen dokumentieren. Microsoft 365 Copilot im EU Data Boundary-Programm ist die DSGVO-freundlichste Variante für Cloud-Einsatz. Für besonders sensible Produktdaten empfehle ich lokales Deployment (z.B. Azure OpenAI Service in der EU-Region oder On-Premises-Modelle).

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: bereits in PLM-Lizenz enthalten wenn Teamcenter vorhanden
• SAP Digital Manufacturing: in SAP-Lizenz enthalten
• LLM-API-Kosten (Claude/ChatGPT): 30–150 Euro/Monat je nach BOM-Volumen

Konservative Nutzenrechnung 3 Ingenieure prüfen je 4 BOMs pro Monat zu je 5 Stunden = 60 Ingenieursstunden/Monat. Bei einem Bruttostundensatz von 45 Euro: 2.700 Euro/Monat Zeitkosten. Bei 75 % Reduktion durch Automatisierung: 2.025 Euro/Monat eingesparte Arbeitszeit. Dazu kommen vermiedene Fehlerfolgekosten, die im Einzelfall ein Mehrfaches dieser Summe ausmachen können, wenn ein BOM-Fehler erst in der Fertigung auffällt. Bei 15.000 Euro Einrichtungskosten: Amortisation in ca. 7–10 Monaten allein über die Zeitersparnis.

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 70–80 % der Prüfregeln gelten 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. Erfahrungsgemäß sinkt die Fehlalarmrate nach 4–6 Wochen Betrieb deutlich, sobald Sondertypen und Ausnahmen dokumentiert sind. 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 3–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 aktuelle BOM aus Excel oder deinem PLM als CSV und nutze den folgenden Prompt, um die Analyse zu starten:

Quellen & Methodik

• Arbeitszeit-Benchmark: VDE-Studie “Digitalisierung in der Elektrotechnik” (2023); Ergänzend: Eigenerhebungen aus Projekten bei Elektrotechnikunternehmen mit 80–400 Mitarbeitenden.
• Fehlerfolgekosten-Verhältnis (5–20x): Klassische “Rule of Ten” aus der Qualitätssicherung, bestätigt durch ZVEI-Branchenberichte zur Fehlerentstehungsphase in elektrotechnischen Projekten (2022).
• AI-Erkennungsraten (90–95 %): Herstellerangaben Siemens Teamcenter Copilot (2024); eigene Erfahrungswerte aus pilotierten BOM-Analyse-Projekten.
• Implementierungskosten: Erfahrungswerte aus ERP/PLM-Integrationsprojekten im deutschen Mittelstand (Stand April 2026).

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.