Beyond the BOM · the book
The structural gap under every industrial PLM programme, and what to build instead.
Engineering systems hold the parts. They do not hold the agreements between systems, the evidence behind test results, or the reasoning behind decisions. When people leave, that knowledge leaves with them. This book shows how to give those missing things a home of their own: a thin layer on top of the systems you already run, where they live as managed data that knows when it has gone stale. Nothing gets replaced.
Buy on AmazonWritten based on nearly three decades of experience building complex systems for Europe's major manufacturers. The work continues at Intuitio Oy.
About the book
Every industrial engineering organisation has run into the same PLM pattern. Two years into a programme, most of the work the lifecycle actually requires still happens outside the tool. Decisions live in meeting minutes. Tacit knowledge stays uncaptured. Interface contracts sit in documents nobody indexes.
Beyond the BOM diagnoses the structural cause and specifies the architecture that resolves it. The engineering data model is missing seven primitives it needs as first-class managed objects: system, interface, space, verification, configuration history, decision and rationale, and judgment. The book develops each in turn, then specifies the federation architecture that lets them sit above existing PLM, PDM, ERP, MES, and MBSE tools rather than replacing any of them.
Written in disciplined declarative prose. Anchored in worked cases from Nokia, aerospace, automotive, and process industries. Engages honestly with adjacent traditions including AEC's federation pattern, MBSE, STEP, ISO 15926, OSLC, ShareAspace, and Management of Change.
Who it is written for
- Chief engineers and PLM leads who have been through one or more industrial PLM programmes and want to understand why the recurring failures happen
- Systems-engineering practitioners working across MBSE and PLM boundaries
- Executive sponsors weighing whether to commit to the next multi-year industrial-software programme
- Architects and consultants advising industrial clients on complex data infrastructure
From the article series
Free self-training: The Two-Decibel Question
One engineering question, answered twice. You play a new engineer who is asked whether production can rely on a test result.
You answer the way every organisation answers today: a test report excerpt, review minutes, and an email from someone who has already left. You commit to an answer.
You trace the recorded objects, make the acceptance call yourself, and watch an old decision flag itself the moment the product changes.
About half an hour · free · no signup
Run the diagnostic
Chapter 14 of the book turns the architecture into an instrument, and it is now an interactive page. Score your organisation with your team and see where you actually stand.
Eight questions about how your organisation handles its engineering data, five levels each. The radar takes shape as you answer.
The result is read against what your product actually demands, not against a maximal ideal. It tells you which gaps matter for you, and which can wait.
Best with a small team · nothing you enter leaves the page
Also available: the training programme
For organisations that want to take the architecture from the page into practice, the book's material is also delivered as training. Each module pairs the chapter's argument with worked cases from European industry, and leaves participants with the diagnostic instrument and the language to apply the architecture in their own organisation.
Executive briefing
Diagnosis, architecture, deployment trajectory in one sitting. For sponsors and programme leadership. No deep dive into the primitives.
Architect workshop
Six modules plus the diagnostic from Chapter 14. Designed to leave a team able to run their own architectural inventory.
System as architectural object
A bounded composition with scope, owner, and lifecycle — not just a parts list.
Interface as a first-class object
The contract between subsystems, with its own owner, version, and change control.
Space as a peer to part
Functional regions that own requirements independently of the parts that realise them.
Verification as continuous capability
Evidence tied to a configuration — invalidated automatically when it changes.
Configuration history
As-built, as-delivered, as-maintained: system states across the product's life.
Decision and rationale
Design choices recorded with alternatives, validity conditions, and boundaries.
Bring the training to your team — in-house or open enrolment. Get in touch on LinkedIn.
About the author
