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: A Classic Case Study for the case study.  

Brief Case Re-Cap: We saw an interesting case where the Organization implemented a Product MDM 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 Product MDM 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. 3600 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 Product MDM 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 Product MDM 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 Product MDM 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 Product MDM 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 Product MDM 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 Product MDM implementation should not require drastic change PLM system.  
• Any Other Systems’ Integration to the Product MDM 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. 

In separate articles as listed below, I will address other key questions that my colleagues at different clients brought forth: 

• What is Product MDM 
• What is Master Data Management
• Product MDM: A classic Case Study