Wie BMW Group Master Data Services für Anwendungen außerhalb von Tset nutzt

Auf der ersten Ausgabe des Tset Summit 2025 haben wir gemeinsam mit BMW Group diskutiert, wie das Unternehmen Cost Engineering über einen außergewöhnlich breiten Anwendungsbereich hinweg angeht. Die Präsentation zeigte einen strategischen Ansatz zur Verwaltung von Kostendaten, der weit über typische Automotive-Anwendungen hinausgeht.

Cost Engineering im gesamten Unternehmen 

Die meisten Hersteller wenden Cost Engineering in erster Linie auf Fahrzeugkomponenten an, doch BMW Group verfolgt einen anderen Ansatz. Die Cost-Engineering-Funktion erstreckt sich über Direct Materials, Indirect Goods, Services, Machinery, Facilities und sogar Marketing Events. Diese Breite schafft einzigartige Herausforderungen, die für jede Kategorie unterschiedliche Methoden und Tools erfordern. 

Der Umfang spiegelt eine grundlegende Überzeugung wider: Wenn Purchasing involviert ist, sollte Cost Engineering es analysieren. Dazu gehört alles von Aluminiumkarosseriekomponenten bis hin zu Werksgebäuden, von Logistik-Services bis zu Software-Lizenzen für Mitarbeitende. Jede Kategorie erfordert ihre eigene Kalkulationsmethodik, doch alle müssen auf konsistente, grundlegende Daten zurückgreifen.

Die Herausforderung mehrerer Software-Lösungen 

Cost Engineering auf so unterschiedliche Kategorien anzuwenden, schafft eine grundlegende Herausforderung: Kein einzelnes Tool kann alle Use Cases effektiv abdecken. Beispielsweise erfordert Service Costing grundlegend andere Strukturen als Component Costing; und Schätzungen in der Concept Phase benötigen andere Ansätze als detaillierte Bottom-up-Berechnungen für Lieferantenverhandlungen. 

Standardsoftware stark an unternehmensspezifische Anforderungen anzupassen erzeugt Wartungsaufwände, die für Software-Anbieter langfristig nicht tragfähig sind. Diese Erkenntnis führte zu einer „Clean Core“-Policy für Standardsoftware, bei der Modifikationen minimal gehalten werden, während Flexibilität über andere Wege aufgebaut wird. 

Die Lösung bestand darin, mehrere Tools zu akzeptieren und gleichzeitig eine zentralisierte Datenbasis zu etablieren. Dafür war ein Umdenken in der Systemarchitektur erforderlich.

API-First Architecture als Fundament

Der Ansatz von BMW Group basiert auf einer API-First Architecture für die Master-Data-Grundlage. Diese technische Entscheidung ermöglicht etwas strategisch Entscheidendes: die Fähigkeit, Custom Applications auf standardisierten Daten aufzubauen, ohne Core Systems zu verändern. 

Alle Funktionalitäten bleiben während des gesamten Software-Development-Prozesses aus Anwendungen außerhalb von Tset heraus zugänglich und ermöglichen einen nahtlosen Datenfluss sowie Daten-Transformationen über verschiedene Systeme hinweg. 

Mit diesem Ansatz werden mehrere Szenarien möglich. Teams können cloudbasierte Anwendungen entwickeln, die auf spezifische BMW-Group-Workflows zugeschnitten sind und dabei auf zentralisierte Cost-Engineering-Daten zugreifen. Semi-automated Tools können Supplier Offers bewerten, indem sie Calculation Premises aus dem zentralen Repository abrufen. Ein Data Management Cockpit bedient Nutzende aus verschiedenen Funktionen mit Live-Monitoring- und Analytics-Funktionen. 

Der entscheidende Vorteil liegt darin, dass End-to-End-Datenflüsse möglich sind, ohne dass alles in einem einzigen System laufen muss. Unterschiedliche Clouds, unterschiedliche Tools, dieselbe zugrunde liegende Datenbasis.

Öffnung von Daten über Funktionen hinweg 

Vielleicht der bedeutendste Wandel betrifft die Frage, wer auf Cost-Engineering-Daten zugreifen kann. Historisch gesehen hielten Cost-Engineering-Abteilungen ihre Daten häufig stark abgeschottet. BMW Group geht den entgegengesetzten Weg. 

Das Unternehmen hat sich dazu verpflichtet, Cost-Engineering-Daten für andere Divisionen zu öffnen – eine Abkehr von früheren Praktiken, bei denen Abteilungen isolierte Datensätze pflegten und nur geringe Bereitschaft bestand, Informationen funktionsübergreifend zu teilen. 

Dies stellt sowohl eine technische als auch eine kulturelle Veränderung dar. Der Einstieg erfolgt über Standortfaktoren wie Löhne, die mehrere Abteilungen benötigen, und wird dann schrittweise durch eine Ausweitung der Datenzugänglichkeit ergänzt. Der Ansatz berücksichtigt, dass einige Datensätze risikoreicher sind als andere und daher sorgfältige Entscheidungen darüber erfordern, was mit wem geteilt wird. 

Anwendungen, die Cost-Engineering-Methoden nutzen, ohne sensible zugrunde liegende Daten offenzulegen, bieten einen einfacheren Einstieg. Sie ermöglichen es anderen Abteilungen, von Cost-Engineering-Expertise zu profitieren, ohne zwangsläufig alle detaillierten Berechnungen im Hintergrund zu sehen.