What carmakers already have, and where STP fits

Before designing anything, we looked at how ERPs cost a car and what engineers use instead. Six pain points came out of it, and so did the rule that STP must plug into the systems already there, at a carmaker's scale.

Project
STP: Vehicle Cost Platform, part 1 of 10
Published
October 6, 2026
Reading time
3 min read

An internal tool that ignores the systems around it becomes one more island: data typed in twice, numbers that disagree with the ERP, and a pilot nobody scales. So before designing STP, we looked at what a carmaker already uses to cost a car, where it falls short while the car is being designed, and what a new tool would have to connect to in order to be adopted.

How ERPs cost a car

The three ERPs we studied, SAP S/4HANA, Oracle Fusion and Dynamics 365, cost a product in much the same way, and they do it accurately. Three traits make them late for design work:

  • They cost a released BOM. The structure has to be frozen first, while engineering changes it every day.
  • They cost in scheduled runs. Mass costing runs monthly or yearly, so decisions are made on the last run.
  • Simulating means duplicating. Each hypothesis is a separate costing version to set up and compare.
Engineering changes the BOM every few days; the ERP costs the last released version at its next scheduled run. Versions illustrative.

During design, engineers fill that gap with spreadsheets, which have no traceability and don't scale past one person's file. Upstream, the PLM holds the car's structure, and it's a source for a tool like STP rather than a competitor.

Six pain points

From that, we listed what slows a cost decision down or hides it, and gave each one a feature to answer it. Every later design choice in STP traces back to one of these lines.

With an ERP and spreadsheetsIN STP1 Numbers arrive latedecisions wait for the last monthly runRecomputed on every changein memory, only what the change touched2 A frozen BOM is requiredwhile design changes it every dayDrafts, then frozen versionscost a draft at any revision3 Variants are expensiveone BOM per optionOptions inside one BOMone structure, several configurations4 Volume is fixeda cost for one lot sizePrice tiers at any volumeeach part at the tier it reaches5 What-if is heavya costing version per hypothesisScenarios next to the baselevers, differences, curves6 The margin is missingviability shows up too lateMargin against the marketa verdict on every computation
Six pain points from studying how ERPs cost a car and how engineers work around them, and the feature that answers each.

The timing is what matters. Corbett's often-cited figure is that 70 to 80% of a product's cost is committed at the design stage, so an answer that arrives with the next monthly run arrives after most of the cost is decided.

Plugging into what's there

A cost tool is only as good as the data it gets, so STP was designed to connect to the systems that own that data rather than to replace them.

PLMdesign toolsERPbuys and buildsSTPdrafts → frozen versionscost, margin, scenariosquotesengineering BOMOData v4 JSONSTP pulls prices (cursor)supplier pricespublished BOMOData v4 JSON, idempotentexchange ratesWho uses itdesignedits draftsplantsread released versionsadminsset market prices
STP between the PLM and the ERP. Every flow uses a format or contract the other side can serve, and the ERP never has to call STP.
  • Structure comes from the PLM as an engineering BOM in OData v4 JSON, imported as a draft, or typed and validated in STP's own editor.
  • Supplier prices come from the ERP. STP pulls them with a cursor, so the ERP never has to call STP or know it exists (the ERP never pushes goes through the details).
  • Published BOMs go back to the ERP in OData v4 JSON, with an idempotency key so a retry can't create one twice.
  • Each kind of user sees their part. Design edits drafts, the plants only read released versions, the ERP talks to the controller's endpoints, and admins set market prices.
Each kind of user gets the part of STP they need, and nothing that would let them change what someone else relies on.

OData was a deliberate bet. It's what SAP and many integration platforms already expose, so any ERP or middleware that speaks it can connect without a connector written for it.

At a carmaker's scale

A car has around 30,000 parts, and a whole range with its options is 10,000 to 50,000 BOM nodes. The people reading those BOMs number in the thousands: Stellantis alone had 14 brands and about 248,000 employees in 2024. So three choices were made for scale from the start rather than added later:

  • An in-memory engine instead of computing in the database on every read, so thousands of readers don't wait (recomputing only what a price touched).
  • Kafka between instances instead of instances calling each other, so every instance sees the same number (any instance, the same answer).
  • PostgreSQL as the source of truth, for frozen versions and locks that hold across instances.

We tested it at that scale, not only at the size of the demo cars. At 30,000 parts, every step of the benchmark passes: a cached cost is served in 11 ms, and recomputing after a price change takes 83 ms in the engine. The remaining limit at that size is the 15 MB response itself, which a single extra instance doesn't help with, and the performance post lists it as the next thing to fix.