What is Product MDM? Helping complement existing PLM Implementations with MDM
Author: Lochan Narvekar . February, 28, 2017
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, Product MDM complements and completes PLM.
Also, as written above, Product MDM is unique in that it is more a business need. Companies know what they are building, but need accurate data to build it! Product MDM addresses this area.
Product MDM 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, Product MDM creates a FULL view of product data, and in the process aids organizations in gluing these desperate functions into PLM.
Then, Product MDM will also take this data and feed the analytical tools in a standard way. Previously, this was done in resource intensive ways. With Product MDM, there comes standardization in the data which also standardizes the processes that transform this data for analytics.
Product MDM will lay foundation for quality data communication with external parties. Product MDM should also consider regulatory compliance needs.
By full product view, I do not mean to say that Product MDM is a hub or even a software product. We see enough people getting trapped in this thought. Product MDM 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 Product MDM 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.
Product MDM is NOT catch all
It’s very important not to burden Product MDM 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 Product MDM 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 Product MDM effort or under Product MDM 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;
Product MDM could also include key documents that are needed across the organization like sales collaterals. But these could be referenced rather than brought into immediate Product MDM 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 Product MDM umbrella.
Emphasis on Business Involvement
Product MDM 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 Product MDM projects (if not called so) start with the business process that needs quality data. Often this part is missed somewhere along in Product MDM 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.
Product MDM is MDM, after all…
If not for MDM principles, Product MDM 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.
Product MDM, 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.
Product MDM is not data integration platform. In other words, do not expect Enterprise Information Integration platforms to be Product MDM hubs. By now it’s clear to the reader that Product MDM is a child of MDM, or MDM applied to product area. In this capacity alone, Product MDM offers lot of business objective support that cannot be met with Enterprise Bus alone. Enterprise Bus is a layer which makes the Product MDM 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, Product MDM 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 Product MDM 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 Product MDM system.
Product MDM is also not a data cleansing tool. Although a close cousins and important members of Product MDM family, data cleansing tools complement the core Product MDM applications. Lot of clients point at such tools and low cost of ownership and feel tempted to use them as the core Product MDM platform. I think these tools have definite need, but in addition to strong Product MDM 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.
Author: Lochan Narvekar . February, 28, 2017
Praedicere is a MDM and DG strategy, and IT implementation consulting firm based in California. We work with mid-to large corporations throughout US, including fortune 500 clients.
Lochan Narvekar is the Founder and Principal at Praedicere and has published many articles on the broader topic of MDM and DG.