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 realisation 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 tool are adopted, customised and integrated.
In the manufacturing sector, BOMs are characterised by complex data structures, pre-defined technical systems that are customised 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.
| Utopian view | Dystopian view |
| All BOM information is interdependent and can be structured in a consistent single BOM which can be filtered from different perspectives. | Due to the complex nature of products (like in the automotive and aerospace industries), it is not technically possible to compile all BOM related information into a single and comprehensive data structure. |
| Complexity can be managed through robust data modelling, enterprise integration, big data and live business analytics. | Data alignment is a big challenge, and all data sources must be continuously validated one against another to maintain trust in the data. |
| The need for complex data integration will reduce as data searchability and business intelligence capabilities increase. | Tool many PLM/ERP/CRM/etc. tools and legacy databases are used for different purposes; they cannot be all integrated or replaced by a single unified solution to manage complexity. |
| Modern technologies can provide speed for data searchability, automated validation, learning capabilities through artificial intelligence, complex data mining and self-interpretation. | Legislative compliance, standards and historical data traceability are hindering the adoption of modern technologies. |
| Any relevant filter can be applied to any relevant data; powerful statistical model can be used to establish correlations and introduce useful intelligence. | Data security and IP management requirements constrain how teamwork and integrate. |
| Everyone can change and adopt improved working practices; transition plans and technical overlay data mining tools can be adopted to mitigate deployment risks. | The manufacturing sector is a slow adopter due to static legacy systems and practices; there is no appetite for change due to poor risk mitigation ability. |
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?
This post was originally published on LinkedIn on 9 September 2016.
About the Author
