I have probably touched on this topic many times before: accessing the data that has been loaded into a master data environment. In recent weeks some client experiences are really highlighting something that is increasingly apparent (and should be obvious) for master data management: the need to demonstrate that it really works.
In many of the client sites in which we have been engaged, there is a continuous demand for explanations, resulting in a persistent parade of PowerPoint presentations. Each of these presentations describe what master data management (MDM) is, why it is necessary to have MDM, how MDM works, or more operational aspects about the data sources that have been loaded into the master repository, the number of data sources that have been loaded into the repository, etc. – typical IT-oriented performance measures that intended to demonstrate that progress is being made. The problem is that corporate “memory” is somewhat fickle – once you think that you have satisfactorily explained the value of MDM to a set of business managers, a few days later that knowledge seems to have evaporated.
I believe that part of the problem has to do with the medium of communication, not the message. First, although the value of a master data repository is not just the ability to ingest data from multiple sources and link similar entity records together, data integration seems to be the primary message being pushed. Second, as data practitioners, we are not always completely precise in describing what exactly is “managed” as master data. And third, I contend that unless you are able to show how to integrate the use of the master data in support of a business process, you run the risk of being deemed useless.
That suggests that having an integration plan for master data should be an absolute requirement, although that is often left as an afterthought to the data integration activity. But in retrospect, developing a standard process business application-MDM integration might even be setting the bar high.
I am beginning to think that there is one practical approach that might address both the communications challenge and provide insight into the complexity of master data accessibility: building a demonstration application. A working demo can be used to show business users the end-to-end life cycle for master data from ingestion through use. At the same time, it can act as a conversation starter to discuss what the business process owners need to consider when developing applications that use master data.
Over the next few posts we will look at two use cases for master data accessibility and then the steps for developing the MDM demo.
2 Comments
Hi David,
I totally agree with your post : communication have to be a part of the implementation methodology in a MDM project. For example, in a "Customer MDM" project, you need to explain very carefully what is deduplication process, how it works, how you need to set it up and tune it. It's an iterative process, based on workshops with some real data and a demo application. In our projects, we made many workshop on this thematic during the implementation phase, before the technical and functional validation phases.
In these case, you need to communicate very carefully the duplicates percentage because you can challenge directly the official figures of your customer ... Without a good appropriation and explanation of the MDM process, it can be very hard to communicate easily this kind of information !
Regards
Julien
Hi David,
Your post took me back to some of Verdantis' early projects. The point about corporate memory being fickle is spot on and we realized that something needed to be done if we wanted to waste time and money on the presentations.
This led us to incorporate just the thing you suggest in our process. Every customer gets a detailed demo of the life cycle of the data being managed. This has helped Verdantis build better relationships with clients, while saving time and money, both for our clients and ourselves.