Master Data – A Prerequisite Requirement for Successful Transformations
Randy Spires
Product, Program, and Project Portfolio Management Executive | Digital Transformation | Organizational Development
Introduction
One of the most significant reasons for digital transformation failure is the failure to identify and qualify organizational master data adequately. Digital transformations can still be successful with less-than-adequate solution functionality. However, lacking a qualitative and quantitative master data inventory and dictionary creates significant delivery risk, from which issues and increasing technical cost of ownership (TCO) compound daily. ?
Master Data is the core information that describes a business's most critical entities, such as customers, products, suppliers, installation bases, locations, services, price lists, catalogs, etc. Master data is typically shared across multiple systems and processes as the single source of truth.
Master Data is crucial in enabling the integration, interoperability, and collaboration of different applications and platforms that support a business's digital transformation goals. It goes beyond this as the glue that binds disparate data sources and creates a unified view of the organizational reality.
Therefore, it cannot be overstated that identifying, qualifying, inventorying, and governing Master Data effectively is a prerequisite for initiating, planning, and delivering a successful digital transformation.
Master Data Types
As in the prior article, “Basic Requirements for Successful Digital Transformations ”, we defined the cross-enterprise master data types, which are the following:
The master data inventory across all three types will often drive the key performance indicators (KPIs) or outcomes and key results (OKR) measurements. The configuration master data provides an additional dimensionality to the measure and trends.
All three categories of master data and the respective object inventory are critical prerequisites to planning a successful transformation. If these categorizations and inventories are not drafted, reviewed, and approved before a transformation starting, the program, with its portfolio of projects and initiatives, will continuously attempt to recover from schedule delays and budget overruns.
Master Data’s Critical Role in Digital Transformations
To understand the criticality of master data in a digital transformation, one must start with the end-state objective. What product platform, service, etc., and solution(s) of the organization is being digitalized for the desired end function and service?
From that desired end function and service, one can conduct a fishbone analysis (or Ishikawa diagram) to identify all the critical master data objects required to deliver that desired end state. This exercise provides the organization with the initial inventory of master data that must be further qualified and quantified for transformation planning purposes.
For example, an organization may desire to evolve its HVAC products into an environmental management solution and service to capitalize on the growing sustainability movement and respective ESG standards. Thus, HVAC products will become an installation base for additional revenue from automated and manual services. So, the HVAC install base is the desired objective, and now an Ishikawa diagram can identify all the master data critical to enabling that install base.
领英推荐
Going right to the left, one can start with all the service master data required to support an install base. Service master data can include the ‘as maintained bill of materials’ (as maintained BoM), lowest repairable unit (LRU), lowest detectable unit (LDU), and inspection list per LRU and LDU. Monitoring master data can include airborne substances, wastewater discharge substances, environmental regulatory thresholds per those substances, etc.
The installation, manufacturing, and supplier master data feed the service master data. That manufacturing master data can include the “as built and shipped BoM,” valid part substitutes or alternatives, part firmware version, and respective compatibility matrix to connected parts and firmware.
Failure to identify and define the master data inventory before initiating a transformation will create and compound technical debt and TCO as the transformation progresses. In some cases, executive leaders would be warranted to issue a “Stop Work” order to address the issue before allowing any additional transformation work to progress.
Master Data RACI
Understanding the master data definition requirements before initiating a transformation is also crucial, as is sharing ownership of that master data. The master data RACI (responsible, accountable, consulted, and informed) is also a prerequisite to transformation success.
An example of this RACI is the following:
The key roles in this RACI are primarily data governance and business owner(s). Following leading practices, the data governance team should consist of organizational executives whose domain is in that master data functional area.
In this example of the LRU, the data governance team should be a combination of executives from engineering, services, manufacturing, and quality. The business owner would be the designated service business owner. A consistent theme in failing transformations is the lack of an apparent data governance team (or council) constituted by the responsible functional area executives.
Master Data Preparation –Prepare Now or Pay More Later
The customer, supplier, part number, and GL accounts are master data objects. Yet these four master data objects are 10% or less of the master data that should be defined and governed before initiating a transformation program.
In my experience, when I was asked to assess a struggling transformation program, adequate master data scope definition, inventories of master data, governance on the master data, etc., were not fully understood or addressed. The symptoms of this are often found in the data transformations and migration plans and their lack of progress, poor testing results, and subsequent integration testing and user acceptance testing delays (or failures).
When master data failures occur during these testing cycles, the overall delivery schedule pushes to the right, costs overrun approved budgets, and the morale of the delivery team and business declines. A transformation can be delivered on the approved schedule with less-than-optimal solution functionality. That less-than-optimal solution functionality can continuously be improved and optimized for the organization.
However, forcing a transformation delivery to meet a prior approved delivery date with bad master data only ensures compounding issues with that master data governance, which results in ever-increasing technical debt and total cost of ownership to address the issues and govern the respective master data.
Which option sounds less costly: to issue a “Stop Work” order and address the master data need or to continue to lose delivery momentum, overrun the budget, increase TCO, decrease the expected organizational benefits, continue to pay for additional transformation layers to harmonize the data, store the data, etc.?