The enablement of the Bill of Information (BOI) in today’s digital environments lags behind most other major components of digital transformation. Throughout the enterprise, this lag has held back information sharing even as the many elements of digital transformation pull all the parts of the enterprise closer together.

The BOI goes well beyond a superset of conventional bills of material (BOMs). It is an information construct in which BOMs, requirement structures, decisions and all other product-related data are captured and managed. The BOI offers solutions to the many problems of managing the information stuffed into BOMs and extracted from them. This is why the BOI must be part of the core of every enterprise’s product lifecycle management (PLM) environment; without it, many of today’s model-based structures are difficult, if not impossible, to enable.

Beneath every enterprise’s push for innovation and sustainability, the pace and variety of changes in information, methods, structures and personnel is relentless. The information demands of product development can exceed those of the rest of the enterprise combined, which is why engineering, manufacturing and service wrestle endlessly with:

Information gathered and reformatted from sources new and old that remains unverified, and therefore untrustworthy.
Connectivity among the many product-related data structures created as a new product or asset or system is developed, goes into production, and is sold, serviced and modified.
Accessibility for hundreds of people in dozens of enterprise business units and suppliers that create new products.

What is a Bill of Information?

Fundamentally, a BOI is a comprehensive product-related data structure that includes all the part-to-part, part-to-document and document-to-document relationships important to defining the product and processes. The BOI includes all relationships among the product’s various components—all mechanical, electrical, software, documentation and process-related components (i.e., all appropriate elements that define a product and the processes with which the product is made and supported). This greatly expanded data structure includes all the relationships that define a specific product, system or asset, and its processes, attributes and instances. This includes any and all relevant elements, but in particular:

Components. All of the product’s process-related elements, including manufacturing considerations, constraints and subassemblies, plus provision for engineering change orders.
Relationships. All of the part-to-document and document-to-document links scattered through the product’s various elements and constituents—mechanical, electrical and associated documentation, key decisions (and their rationales), regulatory requirements and environmental considerations.

Unfortunately, even the best conventionally-generated BOMs fall short of product development’s expectations. CIMdata finds that many engineering, manufacturing and service staff are convinced that BOM structures can’t meet their needs until they are part of digital transformation. We especially hear this among aerospace and defense (A&D) companies, where creating a new aircraft—assembly, flight testing, certification and more—takes many years and can be painfully complicated.

Many in A&D believe that managers elsewhere in the organization do not realize how much development efforts and productivity depend on the information in BOMs and other supporting data structures. These dissatisfied users insist that BOMs be reinvented as subsets of the BOI to enable integration into the rest of the digitally transformed enterprise, ideally with PLM.

Personally, I see the enablement of a BOI by a PLM solution as providing me with a magnifying glass that allows me to view everything in each of the underlying BOMs dynamically, including all the different views and extracts of information plus the relationships, definitions, constructs and decisions in all the data objects.

Why the Bill of Information Requires PLM

BOMs have been around forever as a fiscal management tool to track component costs, quantities, suppliers, deliveries and inventories. Amid rapid acceleration in nearly all business processes, however, conventional BOM structures have not kept pace. Moreover, when our clients talk about budgets, competitors, customers and scarcities, they say their dissatisfaction with BOMs is worsening.

However, demands on BOMs for information have become so insistent that many outside of product development are unhappy, too. In many A&D enterprises, for example, CIMdata is told that even purchasing and finance realize that BOMs need greater connectivity—although they don’t (yet) fully accept the need for developing the BOI and switching BOM generation and management to PLM as part of a digital transformation.

By adding attribute, instance and location information to ordinary BOM items, quantities and costs, the BOI cuts errors and response times across the extended enterprise. Just one example (among many) is automatically generating different BOM views needed to support all of the product development and lifecycle disciplines—quoting, purchasing and all the others—as well as in engineering, manufacturing and service.

Given its simultaneous access and use in rapidly changing environments, not to mention all its capabilities, the BOI is a uniquely valuable resource. It must, therefore, be managed throughout its lifecycle, as our experience and research verifies again and again.

Since every lifecycle begins with a product’s creation and ends with that product’s retirement, the BOI must be created as soon as product development begins (typically with requirements definition) and not be allowed to fade away until both production and support are ended. This time span may cover years, or sometimes decades. Moreover, through the reuse of a product’s design, portions of its BOI may live on long after the original product’s lifecycle ends.

Conventional BOM structures also face fundamental challenges from outside a business unit. A look at what I refer to as “Forcing Factors” of digital transformation shows why:

In physical products themselves (and assets), product lifecycles keep getting shorter, especially because electronics and embedded software are steadily becoming more important. The latest technological features are designed into everything new, as are advanced materials that are lighter, stronger and more environmentally friendly. Driving these innovations is continuous feedback from service, maintenance, warranty claims, customers and the Internet of Things (IoT)—all of which add to product developers’ demands on BOMs.

In manufacturing, many new technologies are in use, including generative design, additive manufacturing (“3D printing”), artificial intelligence (AI) and machine learning (ML). They tend to increase dissatisfaction with BOM structures’ limitations.

New information technologies and sources also press upon BOM structures’ limitations—topology data analysis, predictive analytics, graph databases, “Agile” coding and process development and virtual reality/augmented reality.

As the name implies, these Forcing Factors are working their way into all of the enterprise’s products, service, systems and assets; to one degree or another, they impact every solution, platform, process and initiative.

How The Bill of Information Fixes Failures to Communicate

Keeping a BOI current and relevant is a substantial task best illustrated by taking a hard look at ordinary BOMs and their shortcomings. For starters, even simple new products and assets typically have dozens of BOMs; moderately complicated products have far more. In A&D, hundreds of BOMs throughout a product’s lifecycle are not unheard-of.

A big part of the BOI challenge is extracting information from the many different product-related data structures used in product and asset lifecycles. Product/asset variants and their unique components often have their own BOMs, sometimes dozens of them, usually no two alike. Other structures address specific needs elsewhere in the extended enterprise, such as the bill of process (BOP). What none of them do well is exchange information. They all tend to be discipline-specific views of information.

Clients tell us that many business units and functions build their own data structures, meaning that there may be dozens of different data structures and types in any given enterprise. Most viable data structures are generated in ERP systems, PLM and accounting solutions. Unfortunately, many business units also use home-grown BOM-like structures that live in spreadsheets.

Engineering, manufacturing and service units increasingly want to use the BOI for geometry and graphics, detailed specifications, physical attachments, electrical connections and on-board electronics. Much in demand, too, are test results, data on peripherals, supplier options and comparisons, sub-assemblies and assembly instructions, compliance status and environmental concerns. PLM solution providers are busily following through with enhancements and new capabilities.

In contrast, most BOMs for a new product start as lists of items, components, subassemblies and suppliers that aim to manage costs and track impacts on inventories caused by any changes. Soon added are quantities and usages (“instances”), part numbers, serial numbers, basic descriptions, substitutions and validations delivered. As this information accumulates, BOMs that do not become subsets of a BOI can turn into frustrating jumbles and stacks of overly formatted paper—digital transformation notwithstanding—with BOMs that are integrated and relational in name only.

Amid the enterprise’s on-going digital transformations, stubborn problems keep appearing, including weak or nonexistent tracking for the product or asset’s myriad of continuous changes throughout the lifecycle. These include changes applicable to specific product versions, rapid changes typical of design and development phases, on-going bug fixes, updates, enhancements, substitutions of parts and suppliers, and tracking changes across large numbers of BOMs, data sets and documentation.

Other challenges persist:

Using spreadsheets to transfer information between BOM structures.
Managing tasks across global supply chains.
Collaboration across projects, especially when they sprawl.
Providing real-time, secure access to all who need it.
Developing a “single source of truth.”

And the quantity challenge: BOMs often have hundreds if not thousands of items, which may be structured differently for each BOM.

Unfortunately, many users of conventional BOMs struggle with these and other issues. Their daily losses of productivity, just in tracking changes and fixing errors, underscore the urgent need to implement the BOI with PLM.

CONCLUSION

PLM solutions facilitate the creation and management of all lifecycle product configurations—as-designed, as-planned, as-built, as-maintained, as-operated and many others. These change over time (often abruptly), making PLM solutions indispensable for tracking configuration versions, revisions, variants and effectivity dates.

The CIMdata-administered Aerospace & Defense PLM Action Group (AD PAG) is working on these issues. A&D Practice Director Jim Roche explains that the BOI not only accesses the current optimized design of the product but can also validate and certify the design, which requires accessing all the information contained in the related conventional BOMs. This is why a BOI is needed.

In addition, the AD PAG foresees using the BOI to develop and define optimized production and support by utilizing configuration management and/or Model-Based Systems Engineering (MBSE). The BOI will also become essential in defining the specific product as ordered and tracking that definition as the product is built and supported over its lifecycle. This tracking extends to any reconfiguration of the product and any reuse of its enabling systems designs.

Replacing the stacks of conventional BOM structures with a BOI is fundamental not just to product lifecycles but to the enterprise's digital transformation, and this is where business and industry are headed.