Yes, many MES platforms can handle nested assemblies and complex aerospace BOMs, but not all do it well, and almost none do it “out of the box” for every aerospace use case. Deep structures, optional content, repairs, and configuration-specific variants usually require careful data modeling, tight PLM/ERP integration, and custom logic. In brownfield environments, the limiting factor is often data quality and integration maturity, not the MES data model itself. You should assume gaps, edge cases, and the need for workarounds rather than expecting perfect alignment between engineering BOMs, manufacturing BOMs, and as-built structures.
Most MES products support hierarchical structures for parts and operations, which allows them to model nested subassemblies to several levels deep. In practice, they often distinguish between a routing/operation hierarchy and a component/BOM hierarchy, and these two must be kept in sync. Aerospace programs with 10+ levels of nesting, interchangeable parts, and repair histories can push basic MES data models to their limits. Some vendors extend the core model with serialized components, unit-level work orders, and subassembly lot tracking, but these extensions must be configured and validated. If your MES has weak support for serialized subassemblies, you will see gaps in traceability, especially when subassemblies move between lines or facilities.
Technically, MES can store complex BOMs, but maintaining alignment with PLM and ERP is often the harder problem. Engineering BOMs (eBOM) from PLM rarely map 1:1 to manufacturing BOMs (mBOM) or service BOMs, so transformations are required. If those transformations are manual, or live in spreadsheets or custom scripts, the MES structure will lag behind design changes and introduce configuration errors. In regulated aerospace environments, any automated synchronization must be validated, version-controlled, and auditable, which adds friction to change. When integration is immature, plants often end up re-keying BOM and routing data into MES, which increases errors and weakens the value of complex BOM support.
Complex aerospace programs rely heavily on options, variants, effectivity dates, and tail-specific configurations. Many MES platforms were originally built for high-volume, low-mix industries, and only later gained configuration support, often through add-ons or custom rules engines. As a result, the system can usually represent variants, but the configuration logic (which serial gets which configuration of which subassembly) may live outside MES or in fragile custom code. You should expect limitations around late design changes, retrofits, and mixed-configuration work-in-progress on the same line. Robust handling of effectivity and configuration-specific BOMs is possible, but only if PLM/ERP, MES, and change management processes are tightly aligned and validated.
For aerospace, the critical capability is not just displaying a complex BOM, but capturing an accurate, serialized as-built record. MES must be able to bind each major and minor component’s serial (or lot) to a specific parent assembly serial, often across multiple plants and over many years. Some MES products handle this with built-in genealogy and component install/remove transactions; others rely on custom tables, barcodes, or integrations to specialized genealogy systems. Failure modes include partial genealogy (only at some levels), loss of history during rework or teardown, and inconsistent practices between shifts or sites. You should validate genealogy behavior explicitly, including corner cases like scrapped subassemblies, cannibalization, and unplanned substitutions.
Complex aerospace assemblies rarely follow a clean, linear build path, which stresses MES models that assume sequential routing. Rework loops, off-line repair cells, and field-return repairs often require branching routes, parallel operations, and state changes that invalidate simple BOM assumptions. Many MES deployments treat rework as an afterthought, leading to manual work orders, paper travelers, or side systems, which then break the traceability chain. Modeling rework properly typically requires additional configuration entities (e.g., rework routings, deviation routes, or conditional operations) and careful training of planners and operators. If your MES cannot easily represent non-linear flows, your nested BOM will look correct on paper but diverge from the real as-built state over time.
In aerospace-grade environments, trying to make MES the single source of truth for all BOM logic almost always runs into qualification and validation burdens. PLM remains the authoritative source for design intent and configuration rules because it is already embedded in certification packages and engineering workflows. Replacing that with MES would require re-qualifying how engineering data is controlled, approved, and traced, which is costly and risky. Additionally, long asset lifecycles and mixed fleets mean historical configurations must remain accessible in PLM or legacy systems for decades. MES is better positioned as the system of record for as-built and as-maintained condition, with controlled links back to PLM/ERP, rather than a full PLM replacement.
In brownfield aerospace operations, a common pattern is: PLM holds the engineering BOM and configuration rules, ERP holds the financial/manufacturing BOM and material planning, and MES holds routings and as-built records. Nested assemblies are usually imported or derived from PLM/ERP into MES, then adjusted locally to match actual operations under change control. Plants often maintain mapping tables between eBOM and mBOM, and use MES primarily to ensure that the right part is installed on the right serial at the right operation. You should plan for coexistence, including: clear system-of-record definitions, controlled interfaces, and robust reconciliation reports when structures or serials do not match.
If you are evaluating whether an MES can really handle your nested assemblies, focus less on vendor claims and more on concrete capabilities and validation evidence. Verify maximum practical nesting depth supported, performance with large structures, and how serialized genealogy behaves under rework, retrofit, and component swaps. Check how options and effectivity are modeled, and whether the system can manage tail-specific or customer-specific configurations without custom code for every case. Review how eBOM and mBOM changes are propagated, who owns transformation logic, and how deviations or concessions are captured in the as-built record. Finally, assess how well the solution integrates with your existing PLM and ERP, and how much of the complexity will end up in customizations you will need to maintain for the life of the program.
Whether you're managing 1 site or 100, C-981 adapts to your environment and scales with your needs—without the complexity of traditional systems.
