Cross-brand parts commonality: turning a platform strategy into real savings
A single question, in natural language, to see where commonality already exists, where it should exist, and what it's worth.
To illustrate the method without exposing real data, the example uses a fictional automotive group, "Ravelin Group," with entirely invented brands, models, platforms and suppliers. The logic itself carries over to any multi-brand industrial group.
The problem nobody really looks at
Paying twice for the same thing, at two prices
Each brand buys on its own, with its own part numbers, in its own system. Even when two brands share the same technical platform (same body architecture, same engine mounting points), nobody checks whether they're buying the same part under two part numbers, from two suppliers, at two prices.
Not because teams do their job poorly: because the information needed to see it is spread across dozens of systems that don't talk to each other.
The technical platform isn't enough
The strategy is official
Converging brands onto a small number of shared platforms is announced to investors, documented, tracked by the markets.
The layers in between
Between the platform and the actual purchase: the model, the functional assembly, the part, the contract, the supplier — each run by a different team and a different system of record.
No automatic bridge
Engineering thinks in platforms, purchasing thinks in part numbers and contracts. Technical convergence exists; purchasing convergence is checked by no one.
An ABS sensor or an electric door handle can be fitted on two vehicles from the same platform, at two brands, without the two purchasing teams ever comparing their terms.
One structure to connect everything
Brand → model → platform → part → contract → supplier
This chain is exactly what's missing in most industrial organizations. Not because the data doesn't exist. It's in the PLM, the purchasing ERP, the contract systems. But because it has never been connected into a single, queryable structure.
The most important link is equivalent_to: two parts can carry completely different codes from one brand to another while performing exactly the same function. Without this relationship documented in the graph, that identity stays invisible to any conventional purchasing system, which can only compare strictly identical part numbers.
Three questions, three answers in seconds
A calculation that would need four sources
Done by hand, this calculation requires cross-referencing a parts database, a price database, a volume database, and a functional-equivalence database documented by engineers: four sources that generally don't exist in comparable form.
Here, the answer arrives with the figure already included, with no analyst cross-referencing Excel exports from five different systems.
It's not just a purchasing tool
The same data that describes a technical platform on the engineering side directly answers a purchasing question: no re-keying, no export, no juggling between systems.
Today, every cross-cutting question requires an ad hoc project: pulling in a data analyst, extracting tables, reconciling them in a spreadsheet, documenting assumptions, publishing a result that's already partly stale because a contract changed in the meantime.
Two takeaways
A platform strategy is only worth as much as it can be verified
Down to the part and supplier level. Without this fine-grained visibility, the announced convergence stays an intention, not a measurable result.
Digital continuity avoids redoing everything
The day engineering wants to know how many platforms share a component, the same base answers: no new project, no new reconciliation.
What holds true for a multi-brand automotive group holds for any manufacturer structured into entities sharing a technical base: multi-subsidiary equipment suppliers, capital goods with common subassemblies, aerospace or rail programs. The same question comes up, and the same method applies.
Ask the question on your own scope
We model a sample of your product and purchasing data, then you ask your questions in natural language. The figure comes out of the graph, not a spreadsheet.
Subscribe to our newsletter
Insight on knowledge graphs, straight to your inbox.