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).
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?
BOM convergence usually regroups one of more of the following dimensions: people, process and technologies.
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.
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.
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.
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.
This post was originally published on LinkedIn on 13 September 2016.