Why Is a High-Speed Train BOM Modular, While a Car BOM Is Flat?

Step 0 of smart manufacturing. In the management meetings and project reviews of many manufacturers, the same sentence comes up:

"Because the BOM is inaccurate."

"The BOM is wrong" has become the universal excuse. The project is late, the MRP result is off, the purchase plan is unrealistic, the shop floor is short of parts or has the wrong ones. Every chain reaction in the operating system can be traced back to the BOM.

Oddly enough, the theory of EBOM and MBOM is already well studied. Textbooks and system training both explain the BOM tree in detail. But go to the front line of any company and you find BOM problems are almost everyone's pain point.

Is it a lack of effort? No. I believe what is missing is not BOM theory but a practical method for building a BOM from zero to one.

The three root causes of an inaccurate BOM

• The product structure is broken down badly, and module boundaries are unclear.
• The BOM has too many levels, which hurts both system performance and management efficiency.
• There are no unified configuration constraints, so highly customized products cannot be handled.

Based on my earlier work on high-speed rail projects and in the automotive industry, I have organized three ways of thinking about building a BOM. I hope they help managers, and especially R&D and process engineers, when they plan the E/MBOM structure.

1. Modular design in high-speed rail: how to split a complex product

Modular design is the foundation of a sound BOM. The core idea is to divide the product by function into relatively independent modules, each of which is a unit that can be managed on its own and replaced locally.

Take a high-speed train body. Simply put, the body is welded from the roof, one- and two-end side walls, the underframe (including the end underframe) and other large assemblies. The side wall contains doors and other sub-assemblies, a door contains door posts and door panels, and so on, level after level down to the lowest stamped part. The number of parts can reach tens of thousands.

To simplify management and support several train types, R&D and process engineers usually define a phantom part (virtual item) as the carrier for each functional module:

• A phantom part gathers its child parts into one structural unit.
• When a module changes, you only replace the materials under the corresponding phantom part, so the logic of the operation is clear.
• Production planning can also generate an independent production order for each module, so the shop can work in an orderly way on each welding line.

Modular design answers the question "how do we split the product?" It is the precondition for every optimization that follows.

2. Flat design in automotive BOMs: fixing levels that are too deep

Introducing phantom parts creates a new problem: too many levels. A train body is already complex, and once phantom levels are added, the whole BOM easily reaches ten-plus levels. The direct consequences:

• ERP (SAP, for example) takes too long to run the MRP explosion.
• It is very hard to confirm the scope of impact when a change is made.
• Cost roll-up in finance is too inefficient.

The automotive industry developed a method over long practice: a flat BOM structure.

With the same train body as the example, the automotive approach moves the door up to the same level as the side wall assembly, which greatly compresses the BOM depth. Once the hierarchy is gone, the industry needs another way to say where a part sits, so it introduced functional area codes and position codes, which identify the installation position of a part on the vehicle directly and replace position information that used to be carried by the hierarchy.

General Motors, for example, combined position codes with a modular BOM to achieve a flat BOM, greatly compressing the hierarchy of the whole-vehicle BOM, with clear gains in both system performance and management efficiency.

Theory is only the ideal. It matters more to solve the real problem efficiently than to be bound by theory.

3. Template design for automotive BOMs: product line and configuration management

If a company's products are fairly uniform and change little, modular design and flat structure are enough to build a BOM that supports the business.

But in most industries product complexity is very high. Cars are split into platforms, models and series, and many new-energy carmakers now let customers customize color, tires and interior trim. That puts a higher demand on the BOM.

3.1 The automotive solution: VPPS

A. Product line management. The carmaker first defines how many kinds of vehicles it will build, by platform, model and series. For example, Xiaomi's SU7 and YU7 are different models, but both are developed on the Modena platform, and under SU7 there are series such as SU7, SU7 Pro, SU7 Max and SU7 Ultra.

B. Configuration management (VPPS). Most Chinese carmakers have borrowed GM's VPPS concept. The OEM sets up in advance, at platform, model and series level, a VPPS (Vehicle Product Planning Structure), also called a generic BOM or a 150% BOM.

VPPS is not the BOM of any real vehicle. It is the theoretical maximum set of every possible configuration for the product family, including:

• The ten major vehicle systems (powertrain, chassis, interior, body and others)
• 57 kinds of sub-systems
• More than 240 kinds of modules
• All option combinations and the constraint rules between modules (for example, a car with a panoramic sunroof must include the matching roof reinforcement part)

C. Configuration rules engine. Based on VPPS, the system uses a configuration rules engine (for example, the logic handled by the Variant Configuration module in SAP) to automatically extract an exact 100% MBOM from the options on a specific sales order. With this mechanism, missed and extra parts are removed by system rules, rather than depending on human judgment.

3.2 The practical option: a template framework as a transition

The solution above presumes that the company has a full configuration rules engine. Most companies in China do not yet have that capability. A pragmatic transition is to build a standard template framework in advance that defines the position, level and mandatory fields of each module, so process engineers fill in specific materials within that framework instead of configuring freely from a blank page.

For large enterprises that have the means, product line and configuration management is a long-term direction worth investing in. For small and mid-sized companies that cannot yet do this, BOM templating is a pragmatic and necessary choice, but you need to plan deliberately a path that evolves toward configuration management.

Where are the position codes in high-speed rail and large aircraft?

Using business rules flexibly to solve BOM problems. Some people say: "The auto industry has a hundred years of history and a mature position code system, but my industry has no such concept." In fact every industry has similar concepts; they are just not standardized.

High-speed rail has the preconditions to introduce position codes: the railway industry already has a complete position coding standard, TB/T 3416, Coding and Identification System for EMU. Its Part 3, Identification of Installation Location and Position, defines clear rules for identifying each installation position of a vehicle, covering end, position and corner. It is foundational course content in railway universities.

In reality, the BOM system of Chinese high-speed rail followed Siemens' design logic at the time and did not make full use of this standard. That is what led to the deep hierarchy and poor performance mentioned above.

Similar standards exist for large aircraft. The aviation industry has built a very mature spatial position coding system:

• Fuselage Station (FS): measured from the nose.
• Left/right structure: measured from the fuselage centerline (BL, buttock line).
• Wing Station (WS): position coding along the wing.

Once engineers see these position codes, they can quickly locate a specific region of the aircraft structure.

In complex equipment industries, the structural BOM is often not just the product structure but also a mapping of spatial structure. In many cases the different data in a company are already related to each other and can be borrowed from. Do not create position codes for the sake of position codes alone.

You cannot discuss the BOM and forget the routing

A BOM is only a product structure and cannot, on its own, meet supply chain planning needs. An MBOM designed according to modularity, flat structure and BOM templates only says what parts the product consists of. Before it enters production planning, the MBOM must also be linked to the routing to say where it will be made, how long it takes and what resources it needs.

There is a very common problem here in Chinese companies: embedding the operation concept directly into the MBOM structure.

Many companies, when defining the MBOM, express the production operation as a level of the BOM, trying to make the BOM reflect the manufacturing process directly. The problems with this:

• Production operations change often with shop layout, line adjustments and the switch between trial and mass production.
• Fixing operations in the MBOM makes production planning rigid.
• Every change in production organization requires a matching BOM change, which is costly to maintain and easily leads to data errors.

The right approach is to keep the MBOM and the routing separate: the MBOM expresses what the product is made of, the routing expresses how the manufacturing process is organized, and the two are maintained independently in ERP and linked through the production order, each doing its own job.

Conclusion

In many companies people often stress that their business is special and complex and cannot be standardized, so the methods above do not apply. Objectively, though, the complexity of non-standard machinery is hard to put above that of a car or a high-speed train. Complexity itself should not be a reason to avoid optimizing.

The core method for building the E/MBOM of a complex product comes down to three points:

• Modularization: solves design reuse.
• Flattening: solves manufacturing efficiency.
• Templating: solves configuration complexity.

Understanding BOM hierarchy theory is the foundation, but in real work you need to hold on to the theory and apply it flexibly to local conditions. The management method ultimately serves the business goals: solve real problems, lower management cost and raise operating efficiency.

A BOM is hard to explain in one article. Companies differ a lot in product structure, production mode and management model, and many scenarios need to be designed around the specific business.

Translated from the original Chinese article on the WeChat account “犀牛鸟智造”.