Product MDM: A Classic Case Study
Author: Lochan Narvekar . November, 18, 2016
I have put together this interesting scenario to underscore the Product MDM importance in any industry. Nothing here is a new revelation, but merely depicts the right orientation of technical and business component can generate great savings. I highly recommend reading article What is Master Data Management before reading this article.
Our hypothetical company is a High-Tech B2C company called MyTech Inc. with its typically short product life cycle and high innovation curve. But I have kept the problem generic enough so that it can apply to any industry.
Problem Statement: It starts with Finance V.P., George Holder, complaining that Customer Support and one time recall related costs for this quarter were surprisingly high.
Problem Details: It has been noted by his team that the customer support costs have been study but portion of those costs cannot be brought down as a percentage of overall costs. In fact, this slice has been steadily increasing over the last 4 quarters.
Support director, Andrew Whitefield, found out that the major component of support cost was the fact that the support calls were getting multiplied because the marketing product number on the product leads support personnel to the wrong SKU material and this in turn means more time spent in the call or in lot of cases, a wasted call.
George knows that they pay the support vendor $10/call and quick inspection of the number of calls shows the spike in support calls after new product line was introduced last fall. He recalled that there have been many revisions to this product line. He also realized that this may also mean returned products as well as lost customer, at worst!
Please read How to build a Case for Product MDM as an example of ROI justification. Similar ideas can be applied to CDI and other MDM areas.
He contacted CIO, Mark Muller, and requested to propose a solution to this problem. In his team meeting Mark brought the topic up, when Biao Zheng, his Engineering Systems Manager suggested that this problem is in integration between Engineering System and Marketing System. He promised to get back with his proposal.
Analysis: After talking to his Business Analysts, Biao realized that there is one-to-many relation between Engineering SKU and the marketing product number.
There were also many attributes that defined this relationship. Also, he realized that there were many Change Requests that came in monthly for SKU and although most revised the SKU, few indeed changed the SKU number, called Enhancement SKUs. Changing the SKU should be a flow that needs Marketing involvement in changing the corresponding Marketing Product Number, and was not treated that seriously. Anyone could copy an existing SKU into a new Enhancement SKU and with that, copy all the same marketing attributes from previous SKU. He asked his team members to analyze some data to backup his claim, and found out that this was indeed the case!
Solution: Biao realized that this was clearly a Master Data Management problem. Not only Enhancement SKU, but also New SKU creation from Engineering PM should take Marketing input.
He connected the dots with other requirements in his plate such as tightening the attributes control for Manufacturing attributes as well as support need for product information. He decided to use this opportunity to implement a Product MDM Hub for Marketing and Support area consolidation as a first phase.
Although Engineering PLM system is the backbone for Product engineering data, for various reasons given in article “What is Product MDM” Product MDM system was very desirable to Biao and his Business counterparts.
Specifically for MyTech Inc., Biao realized that MDM opportunity was to
- Consolidate Marketing System into the Hub: Marketing V.P. was only glad to see that finally they will have a uniform view of the product and Marketing will be the starting point.
- Consolidate Support function into the Hub: Support director, Andrew Whitefield wanted a formal system for long time. He also wanted access to the Product 3600 data, so that he and his team would not constantly need to send emails.
- Get some key Business Flows like NPI (New Product Introductions) extended through common UI to the rest of the Enterprise.
- Very easily handle publish subscribe model that is needed in agile organization. This was of great importance to MyTech Inc., because in the current architecture, changes made by Engineering were unknown to Marketing and those made by Marketing were unknown to Support, Logistics, DISTIs and other organizations down the supply chain.
- Perform Data Governance: Data Governance is a breeze with Product MDM Hubs: Currently anyone could change the attributes. We will see in detail how this was handled.
- Use the BPEL/SOA capabilities available in the Enterprise: With competitors moving towards SOA oriented architectures for leaner supply chain, MyTech Inc., had put sizable investment Enterprise Integration Platform. Hubs complement the Enterprise Buses in terms of good consolidation Hubs that use Buses to publish and collect data from the Enterprise. Lot of vendors are building standard adapters to their Hub and Bus products making it lot easier to plug these together.
- Use Endless Extensibility to get more internal systems into the Hubs*1.
- Cleanse the data more automatically: There are great data cleansing tools out there. Standard adapters are also available to automate the data exchange between Product MDM Hubs and Adapters.
*1 It should be noted that bringing a system into Hub is a careful study of criticality and complexity of the system.
Detailed Solution
Common MDM Concepts
Let’s see how Biao and his team dealt with this in the implementation.
MDM Systems and Integrations
Biao chose a Product MDM hub solution approach with consolidation model.
Solution footprint:
- Marketing: Today, Marketing used a home grown database employing 2 engineers, one for support of business flows, and second for data merge and mange, such as collaterals from vendors, data from Engineering etc. The whole Marketing Custom DB was merged into the Hub. All the attributes will be populated and validated in the Hub before the SKU is moved to Release status for further systems.
One resource requirement is now alleviated because the manual flows are now merged into the Hub and Integration BUS. So now, you need only one resource to maintain the Hub freeing the resource to help in other critical Marketing functions.
- Support did not have any formal application. Hence when Biao suggested bringing in Support dimension into the Hub, they were thrilled by the idea.
- Marketing Numbers will now be SKUs in their own Item Category with reference relationship to Engineering FG SKUs. Having separate Marketing SKU in the Hub provided for controlled Marketing features to be implemented as Attributes in the Hub.
- Engineering FG Items were integrated into their own catalog category. Here, Marketing and Support attribute were added to them.
- Engineering: will continue to use the current system, but they added another status between the Pre-release and Release statuses, called Preparation. This is where the product would cut into the Hub. Same statuses will be there in the Hub as well.
- Business also agreed to create few new sub-types of Change Requests to focus on the problem areas such as “Hazard” as well as “Support”. This will help later in metrics creation in isolating the problem.
- Also, they decided to create a change Order type called “Enhancement SKU Change Order” to control the Enhancement SKUs creation. This flow will go through the Product MDM Hub where Marketing Role will need to provide the new Marketing numbers as well as other marketing information.
- Integration: The current PLM system where Engineering flows were mapped will be integrated through the Enterprise Integration Platform to the new Product MDM Hub just like the current ERP system where the manufacturing BOMs etc are sent. The Marketing attributes will not be sent back in Engineering PLM System.
The need for integration between current Custom Marketing and Custom Support systems is removed. There is still manual communication between Marketing and Packaging Vendor, collateral vendor. Similarly, Support has manual communication with support vendors. Biao knows that Hub provides the great opportunity to standardize the communication through Web Services.
- The whole solution brings the clarity and traceability to the Marketing and FG Item where by making Recall situations much easier to deal with.
Please read article How to build a Case for Product MDM as an example of ROI justification. Similar ideas can be applied to CDI and other MDM areas.
Ownership
Marketing: These attributes will be owned by 2 Roles, the Global Product Manager will own most of the attributes. The other Marketing Analyst Role will be needed for other Marketing flows that will take care of subordinate attributes and related flows.
Engineering: This department has well structured roles. The current Role “Engineering Project Leader” will still own the new flow.
Common Definitions & Classifications
A logical data model diagram was created to find out the Engineering attributes that go to the Marketing and various other systems thereafter. The same exercise was done for the Marketing attributes that flowed through to other systems especially support etc.
A parallel exercise was taken up to consolidate the names and eliminate any redundancy.
This was also a great chance for Marketing and Support to lobby for key attribute additions.
Data Cleansing
The primary problem was that new Enhancement SKUs had no correct Marketing Numbers. This was a huge cost issue as the Packaging etc had already gone out. Also, the SKUs were already leaning towards end of Stable Demand Curve. So Marketing, rightfully so, was skeptical of changing them now. But a decision was made to flag these SKUs and that was the task given to Support department. A small budget was allocated for this task.
Other missing information on Enhancement as well as main SKUs was responsibility of Marketing Department.
As stated in article What is Master Data Management, there is another aspect of data cleanliness on on-going basis. To this end, the new business flow in the Hub is supposed to check that no SKU can move to “Released” status unless all the information has been validated and accountable Roles have approved the Work flow.
The metrics mentioned in a later section will be indication of data cleanliness.
Business Process Change
As stated above, business process was changed to incorporate the Enhancement SKU. This was called “Enhancement SKU Change Order” process. It starts with Engineering Manager Role in PLM system, but terminates in the Support notification.
Data Governance
We have already talked about who will own the critical data. It will mostly be Marketing Global Product Manager, Carole Graham. She along with her team can see, but only she can change the attribute. She can only change Marketing Product Number before the SKU is released. After release she needs to create a Marketing Change Order which will be routed the regional PMs or DISTIs, terminating in notification to support function.
Any change to other attributes in the hub will be published to related consumers, especially Support, now that they have few key attributes in the standard hub system.
Metrics and Reporting
We are interested in 2 metrics.
One is the number of Change Requests coming per month for “Hazard” and “Support”. Related to this was Open CRs each month.
Second metric was number of ESCOs (Enhancement SKU Change Order) opened and their statuses.
Biao’s team worked with Business Intelligence team to get this data collected in the data ware house against a SKU. Also, to build a simple report. This report will be sent to steering committee decided at the start of the project along with other stake holders such PMs.
In separate articles as listed below, I will address other key questions that my colleagues at different clients brought forth:
Disclaimer: Although loosely based on author’s experience, the case study is a work of fiction merely intended to depict a typical Product MDM scenario in any industry. It is not a real customer scenario where author may have worked or advised in the past. All the names are fictional.
Author: Lochan Narvekar . November, 18, 2016
Praedicere is a MDM and DG strategy, and IT implementation consulting firm based in California. We work with mid-to large corporations throughout US, including fortune 500 clients.
Lochan Narvekar is the Founder and Principal at Praedicere and has published many articles on the broader topic of MDM and DG.