Can one ontology replace PLM + ERP + ALM + Excel + tribal knowledge, across six OEMs?

The data-continuity problem at six-OEM scale

A new oil-filter spec for a next-generation electric vehicle lands from one of the six OEMs. Inside the supplier's R&D organization, the engineer's question is multi-part:

"Which existing filter elements meet this OEM's certification for this engine program? Which fluid-handling integration tests have we run for adjacent OEM programs that share this thermal envelope? Which historical revisions match similar geometries and viscosity profiles, and which had service-side defect history?"

Today that check spans the OEM's data-exchange portal, the supplier's PLM, the supplier's ALM history, and the senior engineer who knows the OEM's engineering counterpart by name. Multiply that across all six OEM portfolios in parallel, each imposing its own data-exchange standard, and the same question returns inconsistent answers, because different engineers reconcile different OEMs' data layers in different ways.

That inconsistency is the structural risk. Loss of data continuity translates directly into lost OEM relationships when re-quoting season hits, and each lost relationship is a multi-million-euro annual revenue line.

What the customer is testing on one Product Twin

For the OEM oil-filter query, the multi-product engagement runs SPREAD's engineering ontology to return a coherent answer across:

• Product Explorer surfaces candidate filter elements certified for similar OEM engines, ranked by closeness of certification fit + thermal-envelope similarity
• Requirements Manager matches the new [OEM] spec against the customer's portfolio of validated solutions and the OEM's prior requirements records, with confidence scores attached
• Action Tower tracks the multi-step certification cycle for whatever solution is chosen, with the OEM-specific gates surfaced explicitly
• Knowledge Agent answers tribal-knowledge questions ("how did we handle the thermal cycling problem on the [OEM] program three engine variants ago?") in natural language, querying the digitized engineering-team records

The structural argument is that all four answers come from the same Product Twin, meaning the engineer's concurrent OEM questions across the six-OEM portfolio return consistent base data, with each OEM's specific deltas surfaced as filterable layers. Consistency holds across all six OEMs at the supplier's actual data scale.

The oil-filter scenario is illustrative of public automotive-supplier process; specific program details are out of scope.

Why this evaluation is shaped differently from a typical Tier 1 pilot

Most Tier 1 supplier evaluations test a single workflow, sequenced over 18 months. This one runs one ontology underneath all six OEM relationships at once, the layer below the workflows, not the workflow itself.

Why the scale anchor matters

The customer is the global #1 in filtration and fluid management, €4.6B revenue, 22,500 employees, six major European and Asian OEM relationships, with sales into automotive (oil, fuel, air, cabin filters), industrial filtration, water treatment, and life sciences.

That scale is what makes the test legible. The supplier's engineering data is fragmented today across PLM, ERP, ALM, Excel, and tribal knowledge, and that fragmentation reasserts itself at every OEM boundary. The engagement runs one ontology across all six OEM relationships at the actual scale Tier 1 suppliers operate at.

Program shape