PIM: A Classic Case Study

Author Lochan Narvekar, © 2017 Ref# PIM0003-R01 

PIM: A Classic Case Study

I have put together this interesting scenario to underscore the PIM 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 “Pillars of MDM “Ref# MDM0001-R01” 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 article “ROI on PIM: How to build a Business Case Ref# PIM0004-R01” 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 PIM 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 PIM? Ref# PIM0001-R01” PIM system was very desirable to Biao and his Business counterparts.

Specifically for MyTech Inc., Biao realized that MDM opportunity was to

1. 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.
2. Consolidate Support function into the Hub: Support director, Andrew Whitefield wanted a formal system for long time. He also wanted access to the Product 360⁰ data, so that he and his team would not constantly need to send emails.
3. Get some key Business Flows like NPI (New Product Introductions) extended through common UI to the rest of the Enterprise.
4. 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.
5. Perform Data Governance: Data Governance is a breeze with PIM Hubs: Currently anyone could change the attributes. We will see in detail how this was handled.
6. 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.
7. Use Endless Extensibility to get more internal systems into the Hub^*1 .
8. Cleanse the data more automatically: There are great data cleansing tools out there. Standard adapters are also available to automate the data exchange between PIM 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

Here are the MDM pillars from article “Pillars of MDM Ref# MDM0001-R01”.

Common MDM Concepts

Let’s see how Biao and his team dealt with this in the implementation.

MDM Systems and Integrations

Biao chose a PIM 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 PIM 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 PIM 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 “ROI on PIM: How to build a Business Case Ref# PIM0004-R01” 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 “Pillars of MDM Ref# MDM0001-R01”, 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.

Disclaimer:  Although loosely based on author’s experience, the case study is a work of fiction merely intended to depict a typical PIM 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.

About the Author: About the Author: Lochan started his career in R&D architecting PLM/MDM software. Moved to Consulting in 2005, and has been successfully consulting for many years in the PLM, PIM and MDM area. He can be contacted Lochan@gmail.com.

This is copyrighted material; © 2017 Lochan Narvekar.

ROI on PIM: How to build a Business Case

Author Lochan Narvekar, © 2017 Ref# PIM0004-R01 

ROI on PIM: How to build a Business Case

A typical investment in hub runs close to a $500K at least and a lot more if full scale implementation is carried out. It’s imperative that we justify this cost with a great Return On Investment.

To me, there are 2 aspects to this. One is immediate dollarized benefits and other, mid-to-long term benefits. The latter is expected of any horizontal technology such as MDM.

I think the best way to answer the ROI question will be with help of a case study. Please read the article “PIM: A classic Case Study “Ref# PIM0003-R01” for the case study.

Brief Case Re-Cap: We saw an interesting case where the Organization implemented a PIM Hub to cut down costs associated with customer support and hazard recalls. In the process, they consolidate the Marketing DB as well as the Support systems into the Hub. This provided single view of the product to both the organizations and paved the way for future integrations.

Mid-To-Long Term Benefits: Before we get into the top line, bottom line discussion (short term ROI), lets recap the long benefits that PIM Hub brought.

1. Consolidation of Marketing and Support DBs into the Hub meant removed need for integration, either manual or semi-automated. Both are generally resource intensive.
2. 360⁰ view of the Product data: Marketing benefitted immediately by saving time on going back and forth between legacy and PLM systems to find the data.  And very soon other business functions can benefit from visibility of the full product data. Support function added operational efficiency by being able to see and request product data change without relying on email communication. 
3. Common Definitions: By bringing the Product Data under one roof, Management has made sure that there is no duplicate attribute.
4. Get some key Business Flows like NPI (New Product Introductions) extended through common UI to the rest of the Enterprise.
5. Very easily handle publish subscribe model that is needed in agile organization. Just catch a business event and send the data to the interested party/system. You will be surprised how many business users are interested in some key attributes that drive their area, but are enable to know when the attribute changes, hampering their productivity.
6. Perform Data Governance: Data Governance is a breeze with PIM Hubs. Especially history and lineage helps a lot in contentions.
7. 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 into the Enterprise Integration Platform. Hubs complement the Enterprise BUS in terms of good consolidation Hubs that use BUS 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.
8. Cleanse the data automatically: There are great data cleansing tools out there. Standard adapters are also available to automate the data exchange between PIM Hubs and Adapters.
9. Web Services Adaptability: Note that our MyTech Inc, has manual communication between Marketing and, Packaging and collateral vendor. Similarly, Support has manual communication with support vendors. These can easily be converted to the Web Services in near future.
10. Use Endless Extensibility to get more internal systems into the Hub.

Let’s look at the investment we made into the Hub.

Following are the direct costs.

• First, there is license cost for the software.
• Then, there is consulting cost. Typical PIM project should run about 16-18 weeks. If the scope is greater than our example, then the duration will accordingly increase.
• There is hardware cost for the server.

Following are the indirect costs.

• Integration BUS Development: This is required to integrate the Hub to other systems. This incremental cost should be very limited if architecture is done right.
• Data Ware House Modification: Again, this should be as easy as adding attributes to the dimensions already in the ware house.
• Intelligence reports: these can be easily built from the PIM software standard queries as well as queries built on objects in data warehouse. This cost should be minimal.
• PLM Software Development: This is the component required to integrate the PLM software to the PIM Hub.

This has 2 components, first to exchange the product information with Hub and other, to integrate the product flows into the Hub. Effort should be made to integrate in standard ways through Enterprise Integration Platform.

           A good PIM implementation should not require drastic change PLM system.

• Any Other Systems’ Integration to the PIM Hub: This is incremental cost with incremental benefit, and hence can be kept outside the equation for now.
• Business Resource Time Expenditure: typically 1 or 2 users from each area being integrated will be needed to guide as Subject Matter Experts and to test the project. This can be about 25% X duration of the project. Beyond this there is involvement of actual business users during testing. Typically this runs into 4 or 5 business days per resource.

Now, let’s move to the tangible returns of our project:

• Recall related savings: It’s difficult to exactly calculate the savings associated with the recall scenario. But, we can take an old recall event and check its effect on old and new architecture to check the savings. In our hypothetical scenario, product recall was on a Marketing product.

In the old scenario, this would mean the entire FG item with all its variants be recalled^*1 .

In the new scenario, since we are able to trace back to the exact original SKU or Enhancement SKU, we can limit the scope to those units only.

^*1 Either recall all, or an extensive study required to limit the scope of recall.

• Support cost savings: This number can be easily calculated by asking Support Vendor Manager to survey the support vendors about the missed SKU calls Percentage estimate. Based on the annual support vendor budget, we can easily divide the said percentage from the cost to quantify the savings.
• Customer Satisfaction with product: Lot of industry surveys tell us that good customer support is stands between a WON customer and lost customer. 
• Returned Product due to frustrated Customer: This is a real cost and one that cannot be quantified.
• Lost customer: Another of those costs that cannot be quantified. I may not buy a product again from the same company.
• Savings from removal of Custom Application: In our case study we removed 2 custom applications. In both the cases we saved the hardware, and in one case even a resource. This is one of the greatest immediate savings a Hub model offers.

Actual savings are always organization and case specific, but I hope that some (if not all) MDM building blocks of savings were clearly exhibited in the above example, especially beyond the short term benefits which drive any IT project.

About the Author: About the Author: Lochan started his career in R&D architecting PLM/MDM software. Moved to Consulting in 2005, and has been successfully consulting for many years in the PLM, PIM and MDM area. He can be contacted Lochan@gmail.com.

This is copyrighted material; © 2017 Lochan Narvekar.