Cost Engineering steht an einem entscheidenden Wendepunkt. Nach Jahren der Zusammenarbeit mit Cost Engineers, Einkaufsteams und Führungskräften aus der Produktion in der Automobil- und Maschinenbauindustrie zeigt sich ein klares Muster: Die Engpässe, die heutige Teams ausbremsen, lassen sich durch den gezielten Einsatz von Daten lösen.
Reduziert auf das Wesentliche folgt Cost Engineering immer dem gleichen vierstufigen Zyklus:
Das gilt in jeder Anwendung – ob Should Costing für den Einkauf, Zielkostendefinition, Design-to-Cost oder Angebotskalkulation.
Jeder Schritt im Cost Engineering-Zyklus wird durch zentrale Hürden ausgebremst.
Modellaufbau ist so zeitintensiv, dass er viele Anwendungsfälle im Vorfeld verhindert.
Die erste große Hürde ist nicht die Berechnung, sondern der Modellaufbau. Die Definition, wie etwas berechnet werden soll, erfordert viel Expertenzeit. Annahmen sind oft nicht dokumentiert, sondern existieren in Köpfen und Excel-Dateien. Neue Modelle entstehen durch Copy-Paste-Varianten alter Strukturen – das führt zu Intransparenz und inkonsistenter Nutzung.
Die Folge: Unternehmen wollen Cost Engineering früh im Produktlebenszyklus einsetzen – doch in der Realität konzentrieren sich 90 % der Arbeit auf den Einkauf, weil sich Modelle nicht schnell genug skalieren lassen.
Die Daten sind vorhanden, aber sie liefern keine schnellen Antworten.
Nach der Bottom-up-Kalkulation ist die Struktur korrekt, die Ergebnisse stimmen. Aber dann? Jetzt müssen Erkenntnisse abgeleitet, Maßnahmen definiert und Fragen aus Fachbereichen beantwortet werden.
Das Problem: Die Daten sind nicht zugänglich genug. Nicht nur für Cost Engineers, sondern für alle Stakeholder – Einkauf, Konstruktion, Controlling, Vertrieb, Management.
Wie lässt sich eine detaillierte Kalkulation so aufbereiten, dass Managementfragen damit beantwortet werden können? Heute ist das oft mit aufwändiger Excel-Arbeit, Mapping und manueller Aggregation verbunden.
Viele sehen ein Softwareproblem. Tatsächlich ist es ein Prozessproblem.
Jeder Schritt hat Inputs und Outputs – und jeder davon ist manuell. Stücklisten kommen unvollständig. Ökonomische Parameter sind nicht dokumentiert. Daten liegen verstreut in verschiedenen Systemen.
„Viele denken, es handelt sich um ein Softwareproblem. Aber das Softwareproblem ist in Wahrheit ein Prozessproblem," so Sasan Hashemi. „Wer abteilungsübergreifend arbeiten will, braucht ein System, das auch abteilungsübergreifend funktioniert.“
Die Lösung beginnt mit einer zentralen Plattform – einer einzigen Source of Truth. Aber nicht alles sollte standardisiert sein, und nicht alles sollte individualisiert werden.
Es gilt zu entscheiden, was standardisiert ist (was der Softwareanbieter übernehmen sollte) und was Offenheit und Freiraum für Innovation erfordert (was intern steuerbar bleiben muss).
Zwei extreme Ansätze dominieren den Markt – und beide scheitern. Einige Unternehmen fordern vollständig standardisierte Lösungen, bei denen der Softwareanbieter alles übernimmt: von der Berechnung über die Analyse bis hin zum Reporting. Der Reiz liegt auf der Hand: Komplexität auslagern. Die Realität ist weniger attraktiv: Roadmaps, die Jahre bis zur Umsetzung brauchen, und Funktionen, die für alle ausreichen, aber für niemanden wirklich passen.
Das gegenteilige Extrem ist ebenso problematisch. Unternehmen bauen individuelle Systeme von Grund auf, behalten dadurch zwar die volle Kontrolle – aber eben auch den gesamten Aufwand. Am Ende investieren sie Ressourcen in den Aufbau und die Pflege von Funktionen, die anderswo als ausgereifte, getestete Lösungen längst existieren.
Die Antwort liegt in der Mitte: eine standardisierte Software für Product Cost Management mit den zentralen Funktionen, ergänzt durch Tools, die es Ihnen ermöglichen, geschäftsspezifische Anwendungen eigenständig – ohne großen IT-Aufwand – umzusetzen.
Das Problem mit Excel ist nicht Excel selbst. Nicht falsch verstehen: In Excel lassen sich sehr gute, detaillierte Kalkulationen erstellen. Das Problem ist die fehlende Zugänglichkeit der Daten. Der geschaffene Wert steckt in der Datei fest – und kann im Unternehmen nicht wiederverwendet werden.
Offenheit und Zugänglichkeit der Daten sind der Schlüssel. Alles sollte auf API-Ebene verfügbar sein. Stammdaten müssen so aufbereitet sein, dass sie von anderen Systemen und Anwendungsfällen problemlos genutzt werden können.
Das grundlegende Prinzip: Die Daten gehören dem Kunden, der sie erstellt hat.
Diese Offenheit eröffnet neue Möglichkeiten: BI-Analysen, Input für KI-Modelle, systemübergreifend nutzbare Stammdaten und die Verknüpfung von Kostendaten mit Informationen aus anderen Quellen.
Nicht jeder Algorithmus muss selbst entwickelt werden. Es gibt gute Gründe, warum Branchenstandards existieren.
Generische Overhead-Berechnungen werden von nahezu allen genutzt. Das Modell dahinter ist bekannt. Was sich unterscheidet, sind die konkreten Kostentypen, Overhead-Basen und Sätze. Diese Konfigurationen können und sollten durch standardisierte Softwarefunktionen abgedeckt werden. Kund*innen sollten diese Grundlagen nicht selbst bauen müssen. Softwareanbieter wie Tset sollten sie konfigurierbar bereitstellen.
Genau hier zeigen Services wie der neue Master Data Service von Tset, wie sich notwendige Flexibilität und Standardisierung miteinander verbinden lassen.
Aber es gibt auch eine andere Kategorie von Algorithmen: sehr spezifische oder stark methodisch geprägte Berechnungen, etwa für bestimmte Teile oder Technologien. In solchen Fällen ist individuelle Logik notwendig.
Die Vision ist eindeutig: Dort, wo Standards existieren, sollten Standards genutzt werden. Dort, wo es keine Standards gibt – oder wo die eigene Methodik einen Wettbewerbsvorteil darstellt – muss es möglich sein, eigene Logiken zu integrieren. Die Software sollte erweiterbar sein, um domänenspezifische Anforderungen abzubilden, ohne den Zwang, zwischen „alles selbst bauen“ oder „sich auf den Standard beschränken“ wählen zu müssen.
Anwendung #3: Integration in bestehende Systeme
Cost Engineering findet nicht im Vakuum statt. Viele Systeme enthalten Informationen, die im Costing-Kontext sinnvoll genutzt werden sollten. Es ist wichtig, PLM-, ERP- und Einkaufssysteme anzubinden, um deren Daten zu nutzen.
Und der Datenfluss geht in beide Richtungen: Costing-Systeme liefern umfangreiche Daten, die wiederum in Reporting-Tools, Analyseplattformen oder Workflow-Systemen verwendet werden können. Kostendaten gewinnen an Wert, wenn sie mit anderen Informationsquellen kombiniert werden.
Wer in modularen Services denkt, kann noch weitergehen: Costing-Systeme lassen sich in einzelne Services aufteilen, die jeweils eigenständigen Mehrwert liefern – und von Kund*innen unabhängig voneinander genutzt werden können.
Die Zusammenfassung ist klar: Es geht darum, in Offenheit zu denken. Offene Systeme, keine geschlossenen. Offene Daten, keine isolierten. Offene Algorithmen, keine undurchsichtigen.
Die Zukunft des Cost Engineering bedeutet nicht, Fachwissen durch Technologie zu ersetzen. Es geht darum, die Engpässe zu beseitigen, die verhindern, dass Cost Engineers ihre Expertise dort einsetzen, wo sie den größten Mehrwert schafft.
Die Bewegung hin zu mehr Offenheit bei Daten, Algorithmen und Systemen ist mehr als eine technische Architekturentscheidung. Sie steht für ein grundlegendes Verständnis: Cost Engineering entfaltet seinen größten Nutzen, wenn Erkenntnisse abteilungsübergreifend fließen, wenn Modelle schnell aufgebaut werden können, ohne an Qualität zu verlieren, und wenn der Aufwand für den Informationsaustausch zwischen Systemen verschwindet.
Die entscheidende Frage für Cost Engineering Teams ist nicht, ob sie diese Prinzipien übernehmen – sondern wie schnell sie sie umsetzen, bevor der Wettbewerb den Abstand vergrößert.