Multiple Enterprise BOMs
Bills of Materials (BOMs) can be referred as the lifeblood of manufacturing companies. Whether or not the ‘single enterprise BOM‘ vision will ever be achievable is still open for debate from different perspectives: technical feasibility, organisational maturity, cultural reasons, etc. (including data silo mentality, as well as transition challenge perhaps).
It is clear that many product development and manufacturing requirements suggest that it is mandatory to have multiple BOMs and/or several BOM views as they serve different purposes, and every silo considers that it owns the ‘master‘ view; hence the need for continuous synchronization and alignment since there is a lot of common and dependent information across the enterprise.
This needs to be done in a controlled and holistic manner in order to avoid successive technical ‘patching‘ and ‘bridging‘ which might become expensive to maintain and later potentially ‘de-customize‘ when new tools and technologies, and/or new integration frameworks become available (further business benefits will arise, should they leverage Big Data, IoT, business analytics, SOA framework, close loop communication, etc. or all of the above). For that, organisations need to control their logical data model and understand how it maps with the physical data model available with tools and technologies (not the other way around, unless there is a clear / agreed business or technical reason).
Enterprise BOM configuration
In a way, this is like discussing the benefits of configuration management, or more specifically product variants: they combine many common parts and components with contextual product information that relate to a specific platform, model year, build version, market requirement, part version, firmware version, etc. The configuration lifecycle actually includes at least three configuration engines or three levels of configuration: product, manufacturing, and sales which respectively support product definition and changes across engineering R&D, production execution and customer relationship management. Can one ‘single enterprise configuration engine‘ be used to achieve the outcome of the three engines above? Some manufacturers are already achieving this quite successfully…
Aiming for BOM alignment
Considering a similar requirement with regards to the BOM management, various key questions need to be addressed (non exhaustive list):
- What is the enterprise BOM vision and strategy which drives the definition of an optimum business logical data model?
- Would organisations benefit from having a smaller number of BOMs (and smaller number of interfaces) which reuse information and reduce duplication?
- How would these multiple BOMs and/or BOM views, which might be partially segmented, be ‘consolidated‘ or ‘converged‘ into common (or at least a small number of) BOMs, from which the relevant views could be extracted for the relevant teams to operate?
- How to transition from two separate BOMs to a single BOM which serves the purpose of both BOM#1 and BOM#2?
- What if BOM#1 and BOM#2 actually belong to two different organisations and they need to be integrated in order to enable data sharing, reuse and enterprise collaboration? e.g. they may both consider their data as master data.
- What would then be the possible integration patterns to enable BOM data convergence?
- What would be the short and long term considerations to decide on the relevant integration pattern and convergence strategy?
People, process and application / system convergence
BOM convergence usually regroups one of more of the following dimensions: people, process and technologies.
In assessing these considerations and looking for options / solutions to achieve BOM convergence, four enterprise integration patterns can be typically considered:
Pattern 1 – BOM merge
This is when BOM#1 becomes the master while BOM#2 is migrated into BOM#1; this is usually a gradual process to allow for validation and transition of the various relevant interfaces and decommission of BOM#2 related system(s). Data mapping defines how business rules and data quality are aligned and transformed into the target structure of BOM#1, while ascertaining business consistency and performing the required data cleansing operations. This approach is typically a phased approach which relates to system harmonization. It might also require the BOM#1 structure to be augmented with the relevant attributes to support data migration from BOM#2.
Pattern 2 – BOM reconciliation
Data reconciliation between BOM#1 and BOM#2 requires a new hybrid or improved BOM structure that will allow both BOM#1 and BOM#2 to be migrated to it. This is usually more complex as both source BOMs will get transformed during the transition process. System and business impacts need to be carefully planned and phased so that they imply minimum business disruption. The learning curve will be greater and this approach will be expected to mitigate certain technical risks. It is usually a phased implementation approach for obvious validation and risk mitigation purposed.
Pattern 3 – BOM integration
BOM synchronization can be a challenging requirement to support live or near live alignment. Due to large amount of information and change, timely alignment can become a critical business benefit to support high number of concurrent transactions. Enterprise integration is typically an event driven middleware that manages multiple data queues and associated web services through a Enterprise Service Bus (ESB) architecture supporte by SOA-based technologies. This approach requires a robust common message model which aligns to the business logical model and that can be mapped to both physical models representing BOM#1 and BOM#2.
Pattern 4 – BOM handshake
It is possible to create a more simplistic (though still effective) data exchange mechanism when data exchange requirements are more seldom (e.g. up to daily data replication). This sort of handshake between BOM#1 and BOM#2 can be represented as a point-to-point solution or event driven synchronization points.
There certainly other patterns to consider and these four are possibly very simplified versions. Having said that, they represent valid technical alternatives to implement BOM convergence solutions. Other considerations such as skill alignment, process improvement, business change, etc. need to be looked at when selecting the right approach.
What are your thoughts?
This post was originally published on LinkedIn on 13 September 2016.
About the Author
