The purpose of this article is to provide a summary of the distinct differences of using an MDM for centralized data visibility vs the use of Digital Fluidity as a means of ensuring that data is formally integrated between and reportable from all systems that make up an organization’s SolutionScape.
The begin with, let’s define the terms MDM, SolutionScape, and Digital Fluidity.
MDM (or Master Data Management) is often defined providing … “a unified view of data across multiple systems to meet the analytic needs of a global business. MDM creates singular views of master and reference data, whether it describes customers, products, suppliers, locations, or any other important attribute.” (Teradata)
SolutionScapeis defined as “the array of systems, applications, and services that are engaged to bring a company’s product from mind to market.”
Digital Fluidity is defined as “the flow of data between the components (or systems, applications, or services (SaaS)) in the SolutionScape.” This denotes that data needs to flow “between” the components of a SolutionScape, which is most often bi-directional (*).
* NOTE: If data entered or changed in one system (i.e. Assortment / Range Planning) then (based on business rules of propagation) it needs to be passed to the PLM (Product Lifecycle Management) system. Likewise, if data that has been passed to a PLM system from an Assortment / Range Planning system, then when that data changes in the PLM system (based on business rules of access) that same change needs be passed back to the Assortment / Range Planning system. Otherwise, the data would be inconsistent within the SolutionScape.
Origin of MDM
MDM arose out of the need for businesses to establish one centralized “source of truth” of data. Its purpose was to ensure that a range of business reports (now dashboards) would be assured of being accurate and up to date (*). This is often referred to as a Hub and Spoke profile, where the MDM is the Hub and each of the component systems are the Spokes.
* NOTE: If the Product Description is 122 characters long on the PLM (Product Data Management) system, but it is only 60 characters long in the ERP (Enterprise Resource Planning) system, then the MDM “may” consider the PLM system to be the “system of origin” of that data field and ignore the ERP version of that data field. However, if the Product Category is a text field in PLM and is a 2-digit code in ERP and the financial system, then the MDM “may” consider the ERP system to be the system of origin of that data field.
Putting Data Into an MDM
This established the requirement for all systems that contained product and/or business data to pass its data (based on business rules of propagation) to the MDM. It also required that the MDM establish a consistent representation of all data, whereby any inconsistencies in how the same data (i.e. Product ID, Product Description) is stored in the array of components be normalized.
NOTE ALSO: The passing of Product Description and Product Category from the PLM and the ERP systems did not replace the fact that both attributes had to first be passed from the PLM system to the ERP system. Which meant that there was an additional (in this example) requirement to have the ERP system pass the Product Category it received from the PLM system (after having been transformed into the proper format) to the MDM.
That meant that the company’s SolutionScape would require the following “integrations”:
PLM to ERP – Product Description and Product Category (transformed)
PLM to MDM – Product Description
ERP to MDM – Product Category
There is generally no intention that anyone would be able to change the data that arrived in an MDM, which guarantees that the data as formed in the original system of record remained aligned with the MDM.
What an MDM Does Not Do
Given the profile of a Hub and Spoke architecture, it should be immediately obvious that this does not resolve the situation where a Spoke needs to pass data to another Spoke. An example of this is when a Voice of the Customer (VoC) system requires data from the PLM system, and then (following completion of it solicitation process) needs to pass back data to the PLM.
This also does not address the situation where PLM needs to pass data to an ERP as described in the previous section.
MDM is a centralized repository of content from a range of components in the SolutionScape but not a centralized facilitator of all information exchanged between all components.
Digital Fluidity throughout a SolutionScape
Digital Fluidity is the process of formalizing the intimation (intelligent integration) of data between all components of a SolutionScape as products move from mind to market. Mind to market is the process of the ideation of a product based on any number of requirements, such as Market Trends and/or gaps identified in the Assortment / Range Planning system, through its 2D and/or 3D Design, the detailing of the product’s technical specifications, on to ERP and ecommerce / on-line market.
Digital Fluidity is most often a point-to-point integration between components, considering the profile (data / function) of the receiving component. In the example above the Product Description in PLM must be “truncated” when it is passed to the ERP from 120 to 60 characters. Likewise, the Product Category must be transformed prior to sending its value to ERP such that it maps the textual value to the corresponding numerical value.
Digital Fluidity also must consider instances when data that is passed from one component to the other can be changed in the receiving component based on specific business rules. An example is where an Assortment / Range Planning system passed data fields to a PLM system and that authorized users can change specific data fields while it is in the PLM system. This requires that the PLM system pass those changed values back to the Assortment / Range Planning system.
Without that bi-directional transfer (and potential transformation) of the data fields change in PLM back to the Assortment / Range Planning system, there would be no consistency of data throughout the SolutionScape.
It could be determined that if the PLM system is required to send the costing data to the ERP system, and (through vendor negotiation) that costing value is changed, then it would either have to pass that data field back to the PLM system OR it could be designed such that the initial data field is named “First Cost”) and cannot be changed in the ERP system, but instead a second data field called “Final Cost” is used in the ERP system and then passed back to fill in the corresponding data field in PLM.
It could also be required that the Assortment / Range Planning system also requires both the First Cost and the Final Cost data fields be populated from the PLM system.
This would require that the PLM system pass the First Cost data field of the product to it at the same time it was passing that data to the ERP system. It then may be decided that (for architectural simplicity) that the PLM system passes the Final Cost data field to the Assortment / Range Planning system.
Summation
To summarize the profile of an MDM as compared to Digital Fluidity, MDM is a receiver of information for the purpose of providing up-to-date/common data reporting to various roles within an organization. Digital Fluidity is the means of ensuring that data flow between systems per specific business rules and systemic data transformation requirements.
A company may have an MDM that serves as that central repository of cross-system data for reporting and the potential to feed/be leveraged by future AI operations, but to operate effectively it is critical that it also have Digital Fluidity through its SolutionScape.
Both have their purpose and neither should be viewed as a replacement of the other.
