What is PIM? Helping complement existing PLM Implementations with MDM

Author Lochan Narvekar, © 2017 Ref# PIM0001-R01 

What is PIM? Helping complement existing PLM Implementations with MDM

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 Engineering, Manufacturing and 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.  

Then, PIM will also take this data and feed the analytical tools in a 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 this data for analytics.

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

By full product view, I do not mean to say that PIM is a hub or even a software product. We see enough people getting trapped in this thought. PIM really starts with recognition of a product data problem anywhere in the company PLM processes and flows through from there into a solution to this problem. Perhaps the solution is software, but never software alone! Note that even the software need not always be a Product Hub. There are different models of solving PIM problem that depend on complexity, scope, funding etc. They begin with integration at one end, going through hybrid approaches to finally a complete Product Hub solution. 

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, only some of these 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. We do need 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 and handled through content management initiatives.

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 like to quote, “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. If MDM principles are followed properly, this requirement should be met automatically.

PIM is MDM, after all…

If not for MDM principles, PIM would be just another IT data integration project. Hence faithful adherence to 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 not just a theoretical exercise; it has definite ROI implications as well as promise of long term success. Please talk to your system integrator or IT to make sure that they follow up on this promise and present their strategy to you. 

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 cousins 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.

What’s next?

I hope that this article clarifies the subject of Product Information Management and how to delineate it from other IT initiatives. Next steps would be to identify what product data related problems you are facing throughout your product’s life cycle. Interview your business as well as IT analysts; they will point to the obvious problems that they want fixed. Then, engage your systems integrators or IT analysts to solve those problems by applying familiar Master Data Management principles.

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.

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.

Pillars of MDM

Author Lochan Narvekar, © 2015 Ref# MDM0001-R01 

What is Master Data Management?

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.

Common MDM Concepts

Let’s look at each area,

Ownership

After we scope the MDM effort, we will arrive at a set of attribute groups that are going to be under MDM control. It’s essential to set Ownership of these attributes. Meaning which Roles are accountable for the values in these attributes? 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 to communize the 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 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.

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; © 2015 Lochan Narvekar.