During the last several decades, the ability to manufacture customized products for customers has become increasingly attractive to a growing number of companies. However, customization has led to manufacturers drowning in a sea of increasingly complex bills of material (BOM).
ADVERTISEMENT |
Standard products are great when product changes are minimal, when identical products can be put into identical boxes hour after hour. The custom world, on the other hand, is always dynamic and ever-changing. Common tools that work well for standard design, engineering, and manufacturing resist adaptation into solutions for customization. An early symptom of looming problems is the need for huge repositories of parts masters or BOMs to be maintained.
Issues with the ‘150-percent BOM syndrome’
There are solutions that draw from established technologies and are designed from the ground up for dynamic, generative methodologies. Before outlining these, we must dig deeper into why standard solutions cause problems.
The drive to somehow repurpose standard practices into a custom infrastructure has led to the well-known “150-percent BOM,” also known as “master BOM,” “variant structure,” and “configurable BOM.”
Such BOMs strive to contain everything—every possible product variant. A configurable BOM has many permutations loaded into one product structure. When left unconfigured, the BOM contains more parts and subassemblies than needed—far more than 100 percent. Configurable BOMs try to store optional components or modular subassemblies as static entities, which then must be pared down—or configured—to contain only the parts needed for that particular variant, thus creating a usable 100-percent BOM from the all-encompassing 150-percent BOM.
150-percentism often has its origin in the company’s CAD system. CAD “master models” try to solve the “to-order” design process with 150-percent CAD models that end up producing excessive BOMs. Using this approach, every variant envisioned is pre-engineered. Every design is anticipated; every design is recorded in the CAD or BOM system. Throwing every option into a master model, followed by turning required elements on and off is not lean, efficient, or effective.
The problem with 150-percent approach in real-life applications
Requests for unending arrays of additional solutions can never be fully anticipated, and the engineers responsible for these innovative designs are unfairly put in a difficult position.
Similarly, the downstream manufacturing group gets new assemblies to build, and the quality group struggles for new sets of documentation and tests for each variant. Every new design modification or custom option frequently results in hundreds of new entries in the BOM management system, often injected into the workflow by hand—and unfortunately prone to mistakes.
The negatives of the master BOM approach are significant. The system has no record for the design and engineering rationale. BOM-juggling for true configuration or custom engineering is not acceptable.
150-percent approach is inefficient
The 150-percent approach can record only design history. It can’t effectively anticipate future designs because it stores only the specific embodiments of specific decisions and methods that are behind variants, not the engineering decisions, calculations, and methods used to create the variants. At heart, master CAD or master BOM systems are like junior drafters or clerks, forever caught on a treadmill of describing or notating fully baked pieces, parts, or assemblies. When these are badly baked, no amount of juggling is going to staunch the flow of money.
When engineers must manage a broad, ever-changing range of products, companies often compensate by packing more bodies into ever-larger and ever more expensive “application engineering” teams. These teams are meant to absorb the manual labor that goes into new models and variants, but more engineers rarely result in faster throughput. Project bids and requests for quotes arrive late, and customers (or prospective customers) complain that the response time is too slow. At the same time, the design engineers are quickly frustrated by the routine, quasi-clerical work that shackles them. In the world of the master BOM, there are simply too many “special” cases.
The way out: dynamic technologies for dynamic needs
The solution is to stop forcing change on value-stream practices designed for standard operations. The alternative to forever juggling semi- or wholly static BOMs and various BOM combinations is to step up to a “meta” level. This is an overarching level, where software rules capture how products are engineered and configured, as well as how they dovetail with business intelligence, such as profitability.
As the rules are triggered, they enforce why certain parts go with other parts. This allows computer logic to generate new product configurations—and new BOMs—automatically. Adding a new rule to the software requires a single entry, but it is a change that often ripples down to dozens or hundreds of configurations automatically, configurations that are created dynamically. In the end, a unique BOM is automatically created for every customized part.
This alternative, generative approach builds configurations from scratch, generatively, from the rules, and changes automatically when customer specifications are fed into the design model. This model is always exactly as big as it needs to be and is significantly easier to edit and manipulate when further changes are needed.
Add new comment