BLOG.PIMSTRATEGY.COM

Prepare (Structure) for Growth….now or in near future?

After my recent to trip to Midwest, I was happy to see American jobs coming back and growth tide starting to come in slowly but steadily.  So this question came to my mind. And, I thought of writing to our esteemed community. Just jump in with your thoughts. Here’s to get it started….

Mid size Companies always struggle with this, but problem is the same, whether you are 500 million, or $10 Billion; Whether to expend resources on creating structure that will pave way for a future growth, or wait till that growth becomes visible before investing. Looks like a classic catch 22 if you ask me. Companies definitely understand the strategic value of their data, whether product, customer or other. But approaches differ based on management experiences and perceptions.

This company, which shall remain unnamed, is coming out of recession in good strides. They have automated the cost sensitive commodity production lines and moved labor and core competencies to differentiator product (ion) lines. I was impressed with the manufacturing efficiency generated. We demoed solutions that could help them remove inefficiencies in their extended value chain activities. All went really great!

But I noticed that they also needed to look at the problem of growth in a fundamental way and at the enterprise level! Up to now, especially out of the recession, they have been putting in resources cheaply and getting sufficient ROI on them. But how to scale from few hundred millions to billions in market size? How to get more out of every incremental dollar you put in?

Among other things, managers turn to creating repeatable and automated business processes in each core value chain activities. They go at it from both process and data angle.
On one hand they create processes that assist in creating, managing and analyzing critical master data. This then turns into wider departmental exercises on operational data management. Data flow diagrams, processes documentation, canonical models are created to help clarify the Governance structures.  Data Owners, attribution and business rules, Change Management workflows, and finally, metrics and reports, all come into being as a result. This not only helps the operational world, but also feeds great Business Intelligence to business leaders putting best information at their fingertips!
On the other hand, managers also look at transforming business processes that create and deal with this data. As they say, “Quality Data needs quality processes, and vice versa!”

Challenge is that all of this costs, hence the opening question! It costs to hire business analysts, to investigate introspect existing processes, to implement enterprise workflows; to hire data stewards; to add to the already busy schedule of core operational staff. Sounds familiar? And that is where Managers start compromising. Most of the time, emphasis shifts from business drivers (and involvement) to simply putting in IT systems around Master (and operational) data. In other places, managers become tactical in approach; start focusing on point-to-point solutions and lose the big picture of creating “Growth Structure”. And this is crux of my argument!

What to do then?  If we agree that some structure like above, is necessary, in order to grow, then by corollary, it is disastrous to wait to put this structure “in” till we see growth. In my mind, the solution lies in baby (OK, little bigger) steps towards the growth structure in each domain, customer, Item, suppliers etc.  Here’s how I would do it.
I would morph these baby steps with tangible and identifiable business projects, so that I can showcase benefits of putting structure (albeit not all at once) by creating a definite ROI for concerned Stakeholders. I would phase out the Strategic growth plan over 18 months to 2 years and pay for it as I go (or pay-as-you-go!)! I solve bottom-up tactical problems, while creating top-down structure for growth. I have seen this work and there are many advantages of this approach.
Obvious one is that you get structure in place one sub-domain at a time. People actually see value of the work (this is big one), and you get favorable (funding) treatment on your next project (or next quarter). You slowly get interest from right people and get your steering committee. Hopefully you also get your Champion executive that will make funding (and a lot of other things) available to you for your big picture!
There are drawbacks, I agree.  You will not be able to reach your vision in a straight-line. And what if economy starts going south?   But in my view, you will make more friends and open more doors by helping people help succeed in their operation while creating a growth structure that helps senior executives get to their agenda.
I have seen this work! Please comment…..

MDM in phase 1, 2 or 3, or later…

The question I am exploring is where lot of organizations are looking at BI in Phase1, followed by MDM later..my short answer is MDM (albeit basic)  should be done now along with BI.

The answer to this lies in whether you want BI data cleanliness guaranteed or not.

It’s much like a new township, where they want clean water (BI). But if there no proper infrastructure built to get the CLEAN water there, getting water alone will NOT help.

By not doing some form of MDM now, what you are doing is making BI rely on IT. Your vendor is not going to guarantee your data quality, without which you do not have good metrics. They will point to your IT, which in turn will need more budget and resources to guarantee accuracy which in first place should have been done through MDM.

So, what is the answer? Expensive, Expansive MDM initiative???

I tackle this question all the time with my clients and through the blog, where we talk about how application of MDM principles to current “application set” can bring us lot of benefits.

So, in my view, orgs should embark on some minimal MDM alongside BI, NOW!

As I explained in last week’s article on MDM,

http://blog.pimstrategy.com/2009/04/27/pillars-of-mdm.aspx

You should at least try to follow 8 pillars of MDM throughout the org, in order to lay those pipelines, that thought process, to eventually get you there. Later on if we have moneys we will take on MDM platform itself or specialized hubs (if needed), but for now, let’s get the right foundation in place….

On each pillar briefly,

Data Ownership: you should know who to hold responsible and let them tell you (for now) how they can assure you data quality. Try a common point of contact in business who can later on be a governance manager.

Common Defs/Classifications: This can be done, although a bit tough, alongside BI. We tried this at one client, but frankly, the scope has to be kept to only the current BI projects.

Data Cleansing:  Good exercise that will happen anyways for BI, but more importantly, create metrics and hold data owners to those.

Applications: there are commonly available data tools that are cheap and good on ROI. These can be used now and later also, after we have full blown MDM platform.  These can speed the data quality work and to a certain extent help in setting some policies.

Business process change: This exercise can be done a lot in meetings with Business where IT needs to emphasis that MDM is in Business (no flames please, but I truly believe in this). Let the business get on this along with data owners, perhaps creating a MDM steering committee. But from Business perspective, I would say taking point successes is key, hence look at project-by project (in this case BI project).

Data Governance: Note that BI comes from operational data that landed in analytics side. So, data governance on operational systems will be key, especially (from BI perspective), not to make data dirty.  Simple policies can be set and hopefully repeated for each BI project.

Metrics and reports: this will be strongest pillar for this phase, especially because we are doing things manually and there is a great danger of people losing focus, given their other day job. Put simple metrics to reward data owners by allowing them to impress you as Management. Metrics can be, percent of Items/Customer records complete (your definition of complete data). Percentage of change requests on Marketing SKUs.

Put simple reports on these and let them present these quarterly. Enough heads will roll, as quality of data will automatically improve even without greatest of MDM systems.

On this topic, especially, but in general, I welcome comments, questions and of course, criticism.

Metrics is everything....

Other way to look at this is how do you as a Project Manager know that your MDM project is a success. That's where metrics are so crucial. Without them, you are going to finish an excellently executed MDM project,go live with it; soon to find that months after, your data is perceived inaccurate by the very users who supported your MDM project. This should not be taken lightly, as I have seen many prohects fall in this trap.
Classic case is where PM / Business Analysts create Data stewards role or make the existing role responsible. But do not provide any metrics (among other things) and the Data Manager/Steward is doing great job without tools/reports to know how to measure the data accuracy.
There are 2 dimensions: first the MDM project metrics; and other, the Data quality metrics.
We need right metrics to measure the success of MDM initiative. Did the MDM project improve number of change orders? Did of customer support cost go down? Did Sales reps have to make calls to support to clarify their territories? So on...
The second, Data quality metrics, is much stratight forward! Number of broken customer records; number of incomplete product SKUs.
Hope this helps.

PIM A Classic Case Study

Author Lochan Narvekar, copyright Datagrip LLC Ref# PIM0004-R01 www.pimstrategy.com


PIM: A Classic Case Study
1st May 2009

 

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!tacted


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 3600 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”.





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. 

 

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

 

  • What is PIM? ”Ref# PIM0001-R01”
  • How to PIM? ”Ref# PIM0002-R01”
  • Pillars of MDM “Ref# MDM0001-R01”
  • ROI on PIM: How to build a Business Case  “Ref# PIM0004-R01”
  • PIM: Beyond Go Live  “Ref# PIM0005-R01”

 

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: Lochan started his career in R&D architecting PLM/PIM software. He moved onto Consulting to learn closely from his clients. He has been successfully consulting for last many years in the PLM, PIM and MDM area. He has also held leadership positions in the IT organizations. He can be contacted at www.pimstrategy.com or Lochan@pimstrategy.com

 

What is PIM? Helping complement existing PLM Implementations with MDM

Author Lochan Narvekar, copyright Datagrip LLC Ref# PIM0001-R01 www.pimstrategy.com


What is PIM? Helping complement PLM Implementations with MDM

1st May 2009

 

The focus of product management has evolved from Product Data Management, Product Life Cycle management to finally Product Information Management.

In its early days, Product Data Management meant mostly engineering data. With only few reach outs to other business functions, such as, “instruction sheets” for manufacturing. There were CAD, CAM files etc. and emphasis was more on the translating the data from engineer’s desk out to the manufacturer in best possible way.

 

Product Life Management took this further to enable companies manage the lifecycle of a product initially from Engineering to manufacturing, but soon beyond manufacturing into functions such purchasing, Order Management, Service and sometimes Support. This was clear extension of original PDM ideas to some, hence most PDM vendors got onto the bandwagon developing their PLM softwares. As much as we agree on the need for strong software in helping engineers create 3-D models in aiding them to innovate, we will agree that there was not an equal need felt on the PLM side.


All the companies know what they are doing when they build a product and sell it. That’s their bread and butter. So, PLM software helped more on aiding cataloging, change order, BOM management and transfer and other niche areas to fill the gaps in already existing processes. Key question companies wanted answered was what needs to happen at various stages of a product life cycle. Emphasis was on management of product from concept to obsolescence.


Product Information Mgmt takes this one notch ahead. There is equal emphasis on PLM, but there is need to supplement it with accurate data and means of getting that data. So, in many ways, PIM complements and completes PLM.

Also, as written above, PIM is unique in that it is more a business need. Companies know what they are building, but need accurate data to build it! PIM addresses this area.

 

 


PIM recognizes the strong product data needs of business functions like Marketing, Sales, Finance, logistics and ties them to the needs of manufacturing, Purchasing. By doing this through same prism, PIM creates a FULL view of product data, and in the process aids organizations in gluing these desperate functions into PLM.  


PIM will then also take this data and feed the analytical tools in standard way. Previously this was done in resource intensive ways. With PIM, there comes standardization in the data which also standardizes the processes that transform that data for analytics.

PIM will lay foundation for quality data communication with external parties. PIM should also consider regulatory compliance needs.
 

PIM is NOT catch all 
 

It’s very important not to burden PIM platform with all the Product attributes that organization needs. Although it’s true that an attribute exists because its needed somewhere, some of the attributes are really key to the business function and have been identified as needing the PIM care and attention.

Something like ABC inventory classes for raw material. You would take more care of the A parts.

Example: at one of my clients, we had a logistical attribute called layers per pallet. Although this was very much proven to be required in logistics, was not required outside of that function and hence was not brought into the PIM effort or under PIM control.

 

Some of the key attributes include engineering attributes related to form, fit, function such as Length, Width, Height; General attributes like product number, description, revision; Logistical attributes like pallet, container quantities. Attributes from Marketing such alternate product categories; Finance needs product hierarchies; Sales related attributes; Key attributes from core functions such as purchasing and Order Mgmt. PLM attributes like statuses, flags needed to move the product along. One interesting area of contention is custom or company specific attributes. These attributes are always needed based on the unique needs of each business.

 

PIM could also include key documents that are needed across the organization like sales collaterals, but these could be referenced rather than brought into immediate PIM concern.

 

Product data is by nature hierarchical. Packaging, Engineering Item categories, product catalogs are all hierarchical in nature. Add to this the key financial product hierarchy, Marketing’s product categorization based on specific portfolio needs. This is also included under PIM umbrella. 
 

Emphasis on Business Involvement
 

PIM also concerns the business processes that deal with the data. I always put on my resume that, “Quality processes need quality data, but also, vice-versa”.

We should not forget that majority PIM projects (if not called so) start with the business process that needs quality data. Often this part is missed somewhere along in PIM initiative. Although this is not a direct function of IT, it’s a responsibility that in my view, MDM charter holds. I will leave it to the informed reader to engage their business counterparts. 
 

PIM is MDM, after all…

 

If not for MDM principles, PIM would be just another IT data integration project. Hence faithful adherence to the MDM principle is very critical; even in the face of tight deadlines, attempt must be made on each of the facets of MDM. This is just not theoretical exercise, it has definite ROI implications as explained in article
 

PIM, what it’s not?

 

This is a tough question to answer and has strong political tone to it. So, I want to caution the reader that take this as only starting suggestion and act based on your individual scenario. Examples will clarify what I mean.

PIM is not data integration platform. In other words, do not expect Enterprise Information Integration platforms to be PIM hubs. By now it’s clear to the reader that PIM is a child of MDM, or MDM applied to product area. In this capacity alone, PIM offers lot of business objective support that cannot be met with Enterprise Bus alone. Enterprise Bus is a layer which makes the PIM projects a reality by integrating systems intelligently.

 

Integration platforms have come long way from basic offerings and have become intelligent brokers between the desperate applications. Yes, they are taking over some key components of MDM such as limited data governance, audits, better business event support and some business rules support.

 

As explained above, PIM is not a catch all tool. Meaning, unless there is enterprise wide consolidation or some other need such as retiring home grown or old system, attempt should not be made to bring in all attributes into PIM system for management; and definitely not as is. But in certain cases deadlines and some of the reasons mentioned above may make it easy to do so. Even then every attempt must be made to apply MDM prism onto the attributes to get optimal results. We do not want to transfer same old problems to PIM system.

 

PIM is also not a data cleansing tool. Although a close cousin and important members of PIM family, data cleansing tools complement the core PIM applications. Lot of clients point at such tools and low cost of ownership and feel tempted to use them as the core PIM platform. I think these tools have definite need, but in addition to strong PIM applications.

 

 

About the Author: Lochan started his career in R&D architecting PLM/PIM software. He moved to Consulting to learn closely from his clients. He has been successfully consulting for many years in the PLM, PIM and MDM area. He has also held leadership positions in the IT organizations and consuting. He has developed "Datagrip MDM Methodology" to deal with PIM problems. He can be contacted at www.pimstrategy.com or Lochan@pimstrategy.com

ROI on PIM: How to build a Business Case

Author Lochan Narvekar, copyright Datagrip LLC Ref# PIM0004-R01 www.pimstrategy.com
 

ROI on PIM Hub: How to build a Business Case

1st May 2009

 

An ROI study is most important aspect of any implementation, let alone an MDM Hub implementation.
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.

Let me clarify one thing upfront. to me PIM and PIM Hub are 2 distinct things. As I write in the "What is PIM?" article, first comes the need for PIM and then followed by verious strategy to solve it. One of these strategies could be PIM Hub.


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.

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!

 

 

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

 

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.

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

 

  • What is PIM? ”Ref# PIM0001-R01”
  • How to PIM? ”Ref# PIM0002-R01”
  • PIM: A classic Case Study “Ref# PIM0003-R01”
  • Pillars of MDM “Ref# MDM0001-R01”
  • PIM: Beyond Go Live  “Ref# PIM0005-R01”

 

About the Author: Lochan started his career in R&D architecting PLM/PIM software. He moved to Consulting to learn closely from his clients. He has been successfully consulting for many years in the PLM, PIM and MDM area. He has also held leadership positions in the IT organizations and consuting. He has developed "Datagrip MDM Methodology" to deal with PIM problems. He can be contacted at www.pimstrategy.com or Lochan@pimstrategy.com

Pillars of MDM

Author Lochan Narvekar, copyright Datagrip LLC Ref# MDM0001-R01 www.pimstrategy.com


What is Master Data Management?
27th April 2009


Master Data Management is really a business problem that is Age-Old. How do I get best out of my business processes?
But to answer this question one should get the underlying data as well in order! I like to quote, “Quality processes need quality data, but also, vice-versa”.  By data I refer to transactional as well as Master data. By consequence, transaction data will depend heavily on the base master data. If there is confusion on master data, how I can guarantee my transaction data to my business? As you can see, this is really an old problem and hence there is multitude of solutions over last so many years. In this article, I will focus on MDM principles I have developed after years of work in this area. There is always scope for improvement, but objective of this article is to set formal base line for understanding MDM scope.


Let’s look at each area,


Ownership

After we scope the MDM effort, we will arrive at a set of entities and attribute groups that are going to be under MDM control. It’s essential to set Ownership of these. Meaning which Roles are accountable for the values in these? This helps in getting data cleansed before the Go Live. Also, it helps after go live in making these Roles accountable for accuracy of these attributes.


Common Definitions & Classifications


An attribute called one thing in one system should not be called as something else in other system. This seems like a common sense, but where each system has different organic growth, different owners, this is bound to happen without MDM understanding. MDM helps us tackle this issue from top down.

 

 


We also need to look at the classification for data element as it drives the attributes needed for that data element. Each classification has different required attributes. As much as possible we need to match the classification across business systems.


E.g. Products are classified as product types in an Engineering system.  We must strive for same product types in Marketing system with same names. There might be more classifications in Marketing and more attributes, but common ones need common names

Logical Data Models are great aid in documenting anomalies and flow of data between systems. 


Data Cleansing


Data cleansing has 2 phases to it. One, before Go Live and another, after Go Live. It has surprised me to see that often folks miss on the latter. Imagine cleaning the data, transforming it and after Go Live, it again gets dirty.  This problem can be solved with following approach.

 

First, get a good data cleansing tool and implement it alongside the MDM tool. If the data is small then, manual effort is good enough.

 

Second, we need to put checks in place to not allow creation of bad data going forward. Treatment here is different for internal vs. external applications.

 

Third, we have to devise a way to clean the data on on-going basis with Data Stewards, and reports.


MDM Systems and Integrations


This is the most important pillar. Management needs to study the current application set and decide if the organization needs and/or is ready for a new MDM application. Lot can be achieved without implementing a new tool, agreed!  But this needs a strong adherence to MDM principles, and a good consultant. I have often reconfigured the existing toolset and with help of MDM principles tightened the business area in question. But, having a specialized tool for especially if the scope is big enough generates good ROI.


Many companies have Enterprise Integration platforms or Enterprise Bus. They play key role in MDM projects tying together the MDM tool and/or all the systems through MDM principles. Newer platforms even offer embedded Business Process Managers to weave the tools together. Remember to look at all of this through MDM lenses as described here. 

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.

Business Process Change


As I wrote above, “Quality processes need quality data, but also, vice-versa”.  What this means to me is, there is a business and IT partnership in MDM success. What good is the data if the processes are allowing data to change uncontrollably? This change is not drastic. Few checks and balances in the process based on MDM principles to make sure that data stays good.

Please read article “PIM: A classic High-Tech case study “Ref# PIM0003-R01” for a good example of business process change.

Data Governance

This is another important pillar! Good data is only going to stay good, if the good data governance is put in place.

This begins with the Attribute/Entity Owner. Who is ultimate authority on this attribute (perhaps more adequately, this business sub-function)?

Then, who can see the attribute or group of attributes? Who can change them? Who needs to be notified of the change? This is most important topic and one needs to use templates to aid in this. Who needs to subscribe to the change? What systems need this data?  All of these questions need to be addressed.

 

 

Metrics and Reporting


We need to put together right metrics so that after go live we can measure the performance of our MDM implementation.  And we need reports on top of these metrics. I have found that often people call a project victory. But then come next quarter we are back at the problem and blame game. Primary reason this happens is lack of metrics or good metrics!  
Please also read article “PIM: Beyond Go Live “Ref# PIM0005-R01”for more details on this.

In summary, each MDM project, whether its for Product, Supplier, Customer or other entity, needs to follow above steps. Each pillar, as I call it, holds the bridge to deal makers such Operational Efficiency , Business Intelligence, Revenue Enablement, and deal breakers such Regulatory Compliances. Each of the 4 above are key to success of the business in today's world.
 
In separate articles as listed below, I will address other key questions that my colleagues at different clients brought forth:

 

  • What is PIM? ”Ref# PIM0001-R01”
  • How to PIM? ”Ref# PIM0002-R01”
  • PIM: A classic Case Study “Ref# PIM0003-R01”
  • ROI on PIM: How to build a Business Case  “Ref# PIM0004-R01”
  • PIM: Beyond Go Live  “Ref# PIM0005-R01” 

About the Author: Lochan started his career in R&D architecting PLM/PIM software. He moved onto Consulting to learn closely from his clients. He has been successfully consulting for last many years in the PLM, PIM and MDM area. He has also held leadership positions in the IT organizations. He can be contacted at www.pimstrategy.com or Lochan@pimstrategy.com

Introduction

This blog is dedicated to the field of Product Information Management and Master Data Management. Please feel free to ask questions on this topic. I will try my best to answer them as fast as I can.
Please start by reading following article "What is PIM? Helping complement existing PLM implementations with MDM"
Blog Software