Isn′t it time to let a practice like “OLM” (”Object Lifecycle Management”) replace failed MDM?
As far as I can remember, there has always been MDM, “Master Data Management” initiatives kickstarted to deliver some bolted on quick fix when systems and processes fail to run due to the data that fuels the digital thread is wrong, incomplete or missing.
Those master data initiatives have always failed to deliver as they have never been anchored in a natural process. They are always executed in parallel, never in line with day to day processes.
At the same time I have seen PLM (Product Lifecycle Management) initiatives succeed in establishing routines, standards and rock solid reference points for product objects like parts and BOMs across their lifecycle.
While MDM efforts have always taken the approach of bolting on a set of fixes on top of a fairly weak foundation, PLM initiatives have started by establishing a solid foundation and built “in line” processes on that foundation.
Done right, PLM has the culture of LEAN in it. PLM thrives on the culture of 5S and Poka Yoke while MDM seems to be perfectly comfortable with adding waste; “Muda, Mura Muri” in the form of processes on top of processes, repositories on top of repositories and integrations on top of integrations. I understand that the ambition of MDM initiatives is good, but the result always seems to be one of additional work, artificial information flows and late, downstream fixes poorly hidden under a fake illusion of structure and process.
Isn′t time to take the good practices and culture of PLM and apply it to objects outside the product domain? Why not treat objects in the supplier domain, manufacturing domain, customer domain, etc. as if the where product objects under a PLM process? To establish “OLM”, Object Lifecycle management, with natural roots in business processes rather than bolting on MDM practices as separate processes? After all what is the difference between defining and managing a product object and another business object? Doesn’t a sourcing buyer create new supplier and maintain it across it′s lifecycle in a way that is very similar to how a design engineer creates a part and manages it across its lifecycle? Doesn′t a product manager define the product segmentation objects and basic sellable item in a manner similar to defining a part? Doesn′t sales define customer, consumer and channel objects along processes that in their fundamental steps are similar to how a product object is born, cared for and terminated in a PLM process?
I believe it would be a healthy step towards a better digital thread to abandon the traditional approach to MDM and instead take on PLM practices for object definition and object governance across their life cycle; “Object Lifecycle management”. While doing so might at first seems like a step away from agility, I argue that it is actually the other way around. The centralized and formalized approaches in PLM and thus also in “OLM”, admittedly are rigid but they are possible to position inside the process flow and distribute out in the organization while at the same time providing central reference that allows agility to thrive without losing the consistency that allow digital threads to stay connected despite change in the information landscape they run through.
Product Owner / Business Analyst, Assignment at Alfa Laval
5 年If nobody owns and take responsability it doesn't matter what system is used to store and manage. Tricky to set ownership for all different objects I guess. Who owns "Delivery Terms"? As such I have no objections to use PLM (or OLM). Many PLM systems may be overkill for "smaller" objects though?
Help business to understand and manage product data
5 年Could be, if we move from managing transactions to knowledge.
Stefan, it sounds like something I've heard before? ;) If you do "master data management" (or whatever you choose to call it instead) right, then it actually does look like a product life cycle and it functions like a supply chain. The core differences are that a) there is an “independent" function that owns it because it’s extremely cross-functional and traditional organisations are ill-equipped to handle that in a single line function; and b) that the “master data processes” work to tie functional processes together that may not otherwise have anything to do with each other, but the actual work happens in the functional processes. If organisations were truly mature enough to understand this and put it into practice, you would have the procurement function bragging not only about how many cost savings they have delivered, but also how they deliver high-quality, low-latency vendor data to the rest of the organisation - but how many procurement functions do you know that have KPIs for data quality and accuracy towards other internal stakeholders such as planning?
Sales Director Northern Europe @ Ivalua | #LoveProcurement
5 年In my view the biggest fault made in MDM initiatives is the idea that it is all about implementing a MDM system and centralizing management of master data. Different master data are born in different places and have different life cycles and there is no reason to believe they have to be treated equally. It would be like having an Order Management Initiative where all orders should be managed in a uniform way regardless if they are sales orders, purchase orders or production orders. Central data needed for integration and reporting consistency need to me managed, but nothing says it is done better if everything is done in the same system.