Cost Engineering

Cost Engineering Today: Balancing People, Machines, and Data


Als der weltweit größte Motorcycle OEM öffentlich erklärte, dass „European manufacturing is dead“ sei, verstand Jürgen Gumpinger, Vice President Strategic Supply Chain Management bei KTM, dies als Signal und nicht als endgültiges Urteil.

Da 80% der Cost of Goods Sold bei KTM auf zugekaufte Teile entfallen, war die Toleranz für Ungenauigkeiten im Product Costing schlicht zu gering, um sie zu ignorieren. Seine Antwort war der Aufbau einer der datenintensivsten und am stärksten automatisierten Cost Engineering Organisationen in der Two-Wheeler-Industrie.

Auf dem Tset Summit 2025 in München blickte Jürgen Gumpinger auf sieben Jahre Praxiserfahrung beim Aufbau einer Cost Engineering Funktion von Grund auf zurück. Nachfolgend finden Sie die wichtigsten Erkenntnisse aus seinem Vortrag.

Starten Sie dort, wo Sie Ergebnisse zeigen können 

Vor sieben Jahren gab der CEO von KTM Jürgen Gumpinger eine klare Vorgabe: eine Cost Engineering Abteilung aufzubauen. Das Team begann dort, wo die meisten erfolgreichen Transformationen starten: mit should cost analysis. 

Ohne should costing kann man nichts machen. Es ist das Fundament. Und gleichzeitig kann man sofort Einsparungen aufzeigen. Das ist der einzige Grund.

 

Should costing verschaffte dem Einkauf eine konkrete Grundlage. Procurement entwickelte sich von reaktiven Verhandlungen hin zu strategischem Denken auf Commodity-Ebene und gewann die interne Glaubwürdigkeit, die notwendig war, um die Funktion weiter auszubauen.

 

KTM: Building the foundation. Process landscape meets roadmap.

 

Vier Säulen, die Skalierung möglich machten 

Jürgen Gumpinger strukturierte die Entwicklung bei KTM rund um vier voneinander abhängige Säulen: Tools, Integration, Change und Data. Dedizierte Costing Tools bildeten das Rückgrat der Berechnungen und wurden über einen zentralen Data Lake mit bestehenden ERP-, PLM- und PDM-Systemen verbunden. Neben den klassischen Commodity Cost Engineers entstanden neue Rollen zur Unterstützung dieser Infrastruktur: Data Analysts, Automation Engineers und Vehicle Costing Specialists.

Von 3 Berechnungen pro Woche zu 500 pro Tag

Die Einführung von target costing zu Beginn jedes neuen Vehicle-Projekts veränderte den Umfang der Arbeit grundlegend. Engineers arbeiteten nun wöchentlich mit dem Cost Engineering Team zusammen, um Part-Level Cost Targets zu erreichen, und die Anzahl der erforderlichen Berechnungen stieg deutlich an. Aus ursprünglich 2 bis 3 Berechnungen pro Woche wurden mindestens 500 pro Tag. 

Wir haben im Grunde mit commodity costing begonnen. Aber je weiter wir vorangehen, desto mehr brauchen wir Automation und Data Analysts.

 

Um dieses Volumen zu bewältigen, führte KTM Automation über similarity search, random forest models für Standardteile sowie NLP-basierte Parameterprognosen ein. Das System identifiziert ein ähnliches historisches Teil, extrahiert dessen Abmessungen, Material und Gewicht und übergibt diese Parameter direkt an eine Berechnung in Tset oder Siemens. Dies funktioniert unabhängig davon, ob 3D-Daten verfügbar sind.

Spend mit 2,5 % Genauigkeit prognostizieren 

Eine der greifbarsten Demonstrationen des Mehrwerts in der Session war der Predictive-Analytics-Ansatz von KTM. Mithilfe eines Spend Cube, der Produktionspläne, Bill of Materials (BOM)-Daten, SAP-Materialinformationen und Zolldaten miteinander verknüpft, führt das Team Sensitivitätsanalysen über rund 260 should cost calculations pro Commodity durch. Das Modell berücksichtigt Veränderungen bei Rohstoffpreisen, Lohnkosten, Energie und Supplier-Aktivitäten. 

Bei den Materialkosten hatten wir eine Abweichung zwischen Prognose und Realität von zweieinhalb Prozent. Das war wirklich präzise.

 

Controlling nutzt inzwischen Cost Engineering Daten direkt zur Erstellung der Midterm-Budget-Forecasts. Ein deutliches Zeichen dafür, dass die Funktion ihren ursprünglichen Umfang längst überschritten hat.

Was KTM auf dem Weg gelernt hat 

Neben den Erfolgen teilte Jürgen Gumpinger auch eine ehrliche Einschätzung der offenen Herausforderungen. Die Explainability der Ergebnisse bleibt eine zentrale Aufgabe: Wenn sich eine automatisierte Whole-Vehicle-Berechnung von einer Woche zur nächsten verändert, ist es alles andere als trivial, die Ursache über 1.500 Teile hinweg nachzuvollziehen. Die Qualität der Ergebnisse hängt zudem stark von den zugrunde gelegten Annahmen ab, insbesondere beim Vergleich von Kosten über unterschiedliche Geografien mit verschiedenen Prozessen und Machine Lifecycles hinweg. Eine frühe Ambition musste im Laufe der Zeit angepasst werden: Ein einzelnes Tool für alles zu finden, erwies sich als unrealistisch. Stattdessen entwickelte sich das Team in Richtung einer offeneren, integrierbaren Architektur.

Bei den Materialkosten hatten wir eine Abweichung zwischen Prognose und Realität von zweieinhalb Prozent. Das war wirklich präzise.

 

Mit Blick nach vorne skizzierte Jürgen Gumpinger sechs Fokusfelder, die aus seiner Sicht die nächste Phase im Cost Engineering prägen werden:

  • Veränderung aktiv gestalten, indem Mehrwert sichtbar gemacht wird
  • In die richtigen Parameter-Sets investieren
  • Datenzugang im gesamten Unternehmen öffnen
  • Nachvollziehbare Vergleiche schaffen, um Vertrauen aufzubauen
  • Tools mit offenen APIs auswählen, um die Prozessintegration zu unterstützen
  • Kostenbewusstsein über den gesamten Entwicklungs- und Produktionszyklus hinweg etablieren

Möchten Sie die komplette Session ansehen?

Die vollständige Aufzeichnung des Vortrags von Jürgen Gumpinger vom Tset Summit 2025 ist auf unserer Website verfügbar. Sehen Sie sich hier die vollständige Aufzeichnung an.

Jetzt ansehen

 

Interessieren Sie sich für die Teilnahme am Tset Summit 2026? Die nächste Ausgabe wird in Kürze angekündigt. Folgen Sie Tset auf LinkedIn und abonnieren Sie unseren Newsletter, um als Erste Ihre Einladung zu erhalten.

Was ist should cost analysis und warum ist sie im Product Costing so relevant?

Should cost analysis beschreibt den Prozess, zu berechnen, was ein Teil oder Produkt in der Herstellung kosten sollte, basierend auf Materialien, Arbeit, Overhead und Prozessannahmen, anstatt den vom Supplier angebotenen Preis ungeprüft zu akzeptieren. Sie liefert Procurement- und Engineering-Teams eine objektive Kostenbasis und macht Supplier-Verhandlungen faktenbasierter und zielgerichteter. Im Product Costing ist should cost analysis in der Regel der Ausgangspunkt: Sie generiert unmittelbar nachweisbare Einsparungen und schafft die interne Glaubwürdigkeit, um Cost Engineering im gesamten Unternehmen auszuweiten.

Wie verändert Automation die Skalierung von Product Cost Analysis?

Manuelle Product Cost Analysis begrenzt Teams auf eine geringe Anzahl von Berechnungen pro Woche. Mit Automation, similarity search und Machine-Learning-Modellen, die Parameterextraktion und Berechnungsinputs übernehmen, können Organisationen auf Hunderte von Berechnungen pro Tag skalieren. Diese Volumenverschiebung macht Whole-Vehicle-Costing, frühe BOM-Kalkulationen und die kontinuierliche Verfolgung von target costing überhaupt erst realisierbar. Der entscheidende Enabler ist die Anbindung der Costing Tools an bestehende Systeme wie PLM, PDM und ERP, sodass Daten ohne manuelle Neueingabe in jedem Schritt fließen.

Was ist der Unterschied zwischen should costing und target costing?

Should costing beantwortet die Frage: Was kostet dieses Teil in der Herstellung? Target costing beantwortet eine andere Frage: Was darf dieses Teil kosten, damit das Produkt profitabel ist? Target costing startet beim Marktpreis, arbeitet rückwärts über die erforderliche Marge und übersetzt diese in Part-Level Cost Targets, die Engineers und Einkäufer erreichen müssen. Beide Methoden ergänzen sich: Should costing liefert die Datengrundlage, und target costing verwandelt diese Daten in umsetzbare Kostensenkungsziele entlang des gesamten Produktentwicklungsprozesses.

Welche Fähigkeiten benötigt ein modernes Cost Engineering Team?

Eine Cost Engineering Funktion erfordert heute mehr als klassische Commodity Cost Engineers, die Berechnungen durchführen und Supplier-Verhandlungen unterstützen. Mit wachsendem Volumen und steigender Komplexität im Product Costing benötigen Teams zusätzlich Data Analysts, die große Datenmengen verarbeiten und interpretieren können, Automation Specialists, die Integrationen zwischen Costing Tools und Enterprise-Systemen aufbauen und betreuen, sowie Vehicle- oder Product-Level Cost Engineers, die eng mit R&D zusammenarbeiten, um Design-to-Cost-Entscheidungen zu unterstützen. Die Balance zwischen diesen Rollen hängt vom Reifegrad der Organisation und dem bereits erreichten Automatisierungsgrad ab.

 

Weiterlesen

Lassen Sie sich benachrichtigen – neue Blogartikel direkt in Ihr Postfach.

Erhalten Sie monatliche Updates zu Engineering, nachhaltiger Fertigung und fundierten Produktentscheidungen.

Blog-Updates