Bills of Materials, aka BOMs, are multilevel metadata structures that represent a hierarchical arrangement of components, materials, and other information required to develop, engineer, assemble, produce the finished product, as well as sell and service it.
Creating a BOM is not only a necessary step in the product realization cycle, it is also what makes a product a reality.
- EBOM: the engineering BOM represents a product during the development phase, and all the relevant metadata to make engineering decisions, so that components can be activated or de-activated depending on their lifecycle, maturity, applicability and usage by a specific variant, their historical relevance, market requirements, engineering supply chain, production requirements, etc.
- MBOM: the manufacturing BOM represents a finished product assembled at the production and assembly stage; it consists of an inventory of components that are to align to the sales configuration, in addition to relevant information needed for the assembly and production processes, manufacturing supply chain, etc.
- SBOM: the service BOM represents a finished product with historical information that relates to engineering and production changes, warranty information, spare part information, alternate components, etc.
BOMs are configured views / lists of part numbers, part names, phase, maturity, description, quantities, units of measure, procurement types, reference designators, notes, etc. The detail information that they contain or refer to depends on: 1) the granularity of the information model and how dependencies are managed, 2) what associative data is recorded in the BOM, 3) who is consuming the BOM records and for what purpose, and 4) what reconciliation is needed throughout the different iterations, who is taking care of it and how. These considerations link to which data architecture and data management tools are adopted.
In the manufacturing sector, BOMs are characterized by complex data structures, pre-defined technical systems that are customized and integrated across PLM, ERP, CRM, MES and others systems. Aligning and sharing associative information across functional and technical silos is mother of all challenges while designing and managing BOM data. The following table illustrates some of the utopian and dystopian characteristics of having a single consolidated and unified BOM for the entire enterprise.
There is for sure no ‘one-size-fits-all‘ solutions, hence the single BOM approach might remain a vision at this stage due to complexity and feasibility issues. However, with growing power of analytics and enterprise SOA messaging, the single BOM approach starts to make more sense. The logical data model needs to be consistent and allow for abstraction and technical mapping against the physical data model.
Data needs to understand itself so that it can be pre-interpreted automatically for users to derive possible decisions from it.
Single BOM feasibility requires full traceability at any time and by any party through any views, the right data at the right place at the right time to the right person – almost independently of what system, process, or integration layer is used under the bonnet. It is not really about part numbering rules, workflows, processes, data simplification, visibility to all, etc. It is about complete data representation, a ‘single version of the truth‘, and the ability to track past changes and implement future changes in a holistic manner.
What are your thoughts?