Managing Aerospace BOM and Multi-Disciplinary Product Structures — Contromax Customer Story

How Contromax keeps mechanical, electronics, and software teams working from the same page

Why Aerospace Products Are Naturally Multi-Disciplinary

Electromechanical servo actuators are deceptively complex objects. On the outside, they’re compact, precisely machined components installed in aircraft flight control and steering systems. On the inside, they’re three products at once — a precision mechanical assembly, an electronic control system, and an embedded software stack — all of which have to work as one and be documented as one.

For Contromax, an aerospace actuator developer serving both crewed aircraft and unmanned systems, that internal complexity was manageable when the company was smaller. As the team grew and product lines expanded, the cracks started showing. Not in the hardware — in the paperwork behind it.

“Our products include mechanical parts, electronics and software, so the product structure can be complex,” the Contromax team explains. “With OpenBOM we are managing product BOM and configuration data in a structured way.”

That might sound straightforward. It wasn’t, before they got there.

The Spreadsheet Problem in Multi-Disciplinary Engineering

For a long time, the way most engineering teams handle multi-disciplinary product data is the same: spreadsheets, shared drives, and institutional memory. Someone knows where the current BOM lives. Someone else manages the electronics component list in a separate file. The software versioning is tracked somewhere else entirely.

This works until it doesn’t. A revision gets made on the mechanical side that doesn’t propagate to the electronics documentation. A component gets substituted and the change is captured in one place but not another. In a commercial product, these gaps create rework and confusion. In a flight-critical aerospace component, the stakes are higher.

What Contromax needed wasn’t a bigger spreadsheet. They needed a system where all of the following could live together:

• Engineering BOM structures spanning mechanical, electronics, and software
• Component attributes and supplier information
• Configuration data tied to specific product variants
• Revision history that reflects how the product evolved
• A shared view that every discipline could work from

That’s a different problem than “better spreadsheet.” It’s a product data problem.

Why Contromax Did Not Choose a Traditional PLM System

The obvious answer, when engineering organizations outgrow spreadsheets, is enterprise PLM. Contromax looked at the major platforms. What they found were systems built for organizations an order of magnitude larger — expensive to license, complex to implement, and loaded with features built for problems they didn’t have.

The overhead wasn’t just financial. Enterprise PLM deployments typically require:

• Dedicated system administrators
• Months-long implementation projects
• Extensive user training before engineers can do productive work
• Ongoing maintenance and customization as needs evolve

For a focused aerospace engineering company, that level of overhead felt disproportionate to the actual problem. The goal wasn’t to deploy a platform. It was to stop losing track of product data across three engineering disciplines.

How Contromax Uses OpenBOM to Manage Product Structures

OpenBOM’s interface looks like a spreadsheet — deliberately so. Engineers can work in it without relearning how to think about their data. That design decision matters more than it might seem. When a new engineer joins the team, they’re not learning a foreign system before they can do anything useful. They’re working in something immediately familiar, with structure and discipline enforced underneath.

But the familiarity is a starting point, not the whole story. What sits beneath that interface is a properly organized product hierarchy — not a flat grid of rows, but a real bill of materials where assemblies contain subassemblies, components carry their own attributes, and the relationships between parts are explicit rather than implied by spreadsheet proximity.

For Contromax, this meant building out the full product structure for an actuator in one place — mechanical assemblies down to individual precision parts, electronic control components, software configurations — each organized within the same coherent product definition. In practice, that translates to a few things engineers notice quickly:

• Revision tracking that’s actually reliable. When something changes, the change is recorded. Engineers can see what the product looked like at any prior point without digging through file history.
• Component data attached to the right place. Attributes, specifications, and supplier information live on the component itself, not in a separate reference sheet someone might forget to update.
• A shared record the whole team works from. A mechanical engineer making a change and an electronics engineer checking component compatibility are looking at the same product structure. No emailing updated files. No wondering which version is current.

That combination — familiar enough to adopt quickly, structured enough to actually solve the problem — is what made OpenBOM a practical fit where enterprise PLM wasn’t.

The Impact of Structured BOM and Configuration Data

The practical difference isn’t dramatic in any single moment. It accumulates. Engineers spend less time hunting for the current version of a BOM. Fewer errors slip through when a component change needs to be reflected across disciplines. New team members can get oriented faster because the product structure is documented and accessible rather than living in someone’s head.

For a company building flight-critical components — where traceability and accuracy aren’t optional — having that foundation matters beyond day-to-day efficiency. It’s the kind of organized, auditable product record that aerospace development demands.

At OpenBOM, we think of this as building Product Memory: the structured accumulation of product decisions, configurations, and component data over time. For Contromax, it started with a practical need to manage complex BOMs across three engineering disciplines. What they’ve built in the process is a foundation that will support their products through future iterations, new programs, and continued growth.

Best, Oleg 

FAQ

What is a multi-disciplinary aerospace product structure?

A multi-disciplinary aerospace product structure includes mechanical assemblies, electronic systems, and embedded software components organized within a single engineering BOM. These disciplines must be documented together because they operate as one integrated product.

Why is BOM management important for aerospace engineering?

Aerospace products require precise traceability of parts, revisions, and configurations. Proper BOM management ensures that engineering teams can track product changes, maintain accurate documentation, and support manufacturing and certification requirements.

Why do some aerospace companies avoid traditional PLM systems?

Traditional PLM platforms can be expensive and complex to implement, often requiring large IT teams and long deployment timelines. Smaller engineering organizations sometimes prefer lighter solutions focused specifically on BOM and configuration management.

How does OpenBOM help manage multi-disciplinary engineering data?

OpenBOM allows engineering teams to manage product structures, components, revisions, and configuration data in a structured environment while maintaining a familiar spreadsheet-like interface that is easy for engineers to adopt.

Contact OpenBOM for more information — sales@openbom.com.

Contact OpenBOM for more information – sales@openbom.com. 

Contromax develops electromechanical servo actuators for aircraft and unmanned systems. Learn more about Contromax.