Federated BOM Module

Federation enables Single BOM yet Multiple Views

In Traditional System's Architecture, BOM are created in different systems and several copies of it are maintained in different systems. These copies are indeed different renditions and versions of the same BOM. It is difficult to decipher which is the correct truth or is a combination of them that makes it the truth.

Single Attribute Multiple Consumers

The Federated BOM module is designed to ensure that there is only one copy of data maintained by the Original and Dedicated SoR (System of Record), while the same data is made available to other interested systems as ROR (Reference of Record). As an example, if the Design Weight (DW) is stored as SoR in PLM, Net Weight(NW) is stored as SoR in ERP, and Packaging Weight (PW), then it is redundant to maintain copies of these weight attributes across these multiple systems. When the transportation company requests the Gross Weight(GW), all that is needed to store in the SCM system is the RoRs of NW, PW, and DW attributes, such that at runtime the GW can be calculated as NW + PW. Similarly DW can be used as a validation of NW for proximity.

Single BOM Multiple Views

The Federated BOM module fully ensures that only SINGLE Part, Specification, Design, BOM is stored in its relevant SoR, while other interested Systems are simply referencing these original objects as RoRs at runtime without needing N X N asynchronous or synchronous integrations. The N x N integrations cause enormous overhead for IT and tremendously slows the business applications having an overall negative impact on Time to Market. Additionally once you allow for multiple systems to make their own renditions and versions of an object, it can no longer be considered a Single Source Of Truth.

Write Once Use Many

Federated BOM module enables, all functions relevant to Part, Specification, Design, and BOM, to be available and shared across the interested systems. This in turn reduces the burden on IT reducing redundancies in:

  • Developing duplicate custom functions

  • Running duplicate redundant functions on additional Infrastructure

  • Maintaining redundant DevOps and TechOps Teams to support above activities

  • Opening the door for inconsistent and non-standard outputs across systems

Imagine if Upper Case or UOM Conversion functions used in many programming platforms product inconsistent outputs and if the parameters were non standard what would happen to all of our systems. Lets take an example of Short Description function for a product that is the most important attribute across all pillar applications. If the short description were not consistent, and sometimes it really isn't across pillar applications, what terrible things can happens to the entire SCM of that product. On the contrary in the Federated BOM module, there is only one function in Universal Named Federation Space, that is shared across all relevant and interested systems for Make Product Short description (MakePrdShtDesc) Function, resulting in consistent output every single time.

MakePrdShtDesc( PartID, AppID, Zone ) = 40 Chars Consistent Output Regardless of Calling App

All Systems, Applications, Integrations, and Processes can make call to the Federated BOM functions at runtime by providing the standard input, and always expect the same consistent output.

Copyrighted and Trade Marked by BOMAtic360