Join recognised industry experts Mark Allen and Dalton Cervo, who answer questions across a range of topics detailed in their recent publication:
- Understanding the different approaches and types of MDM strategy
- What are the obstacles to the smooth delivery of an MDM initiative
- How to establish a quality culture for your MDM environment
- What is the difference between a Customer MDM model and an Enterprise MDM model?
Please note that Dalton and Mark will also be answering questions related to this webinar, the book and any other general MDM queries in an online forum Q&A after the webinar.
Please click the “Play” button below to listen to a recording of the webinar.
DYLAN JONES: Hello and welcome to another Data Quality Pro webinar.
Okay, so today I’m delighted to be joined by long-time Data Quality Pro member and expert analyst Dalton Cervo and a more recent introduction, Mark Allen.
They’re with us today because we’re going to be discussing some topics around Master Data Management or MDM as it’s more commonly known.
Now this is a topic these guys are certainly equipped to tackle as they have collaborated on and recently released a book entitled:
“MASTER DATA MANAGEMENTINPRACTICE: Achieving True Customer MDM” published by Wiley.
If you take a look just below this webinar viewer you can see a link to the web site for the book plus some other useful links I’ve put in there.
You’ll also notice a link there through to a discussion forum on Data Quality Pro where attendees can post questions to Dalton and Mark, so you can perhaps ask about the topics we cover today, MDM in general and of course anything relating to the book.
So, guys, thank you for sharing your time with our members and listeners today.
DYLAN: Okay, let’s start with the book and an obvious question, what types of professional will benefit from the book the most? Did you have some archetypal roles in mind when you were both working on the book?
MARK: Thanks Dylan, by the way first of all thanks for inviting us we both appreciate being here.
You know Dalton and I really believe that there’s broad audience for the book. We focus a lot throughout the book on the “how and where” perspective of customer MDM.
We are sharing our practical hands on experiences that we have, from a program management and data steward point of view. So, I think there’s a lot to offer from that point of view.
We really think that almost any data management professional should be able to relate to this book. We hope that the executive decision making audience that is looking at MDM investment or certainly looking at launching an initiative, will find a lot of the planning considerations that we offer of value.
The directors and program managers that are tasked with more of the day to day, implementing and driving of the program, we think that they will appreciate a lot of practical insides that we’ll share.
Some of the data stewards, analysts, consultants or, people on the ground doing the day to day execution of the programs, well, we have a lot of advice and techniques that we offer that will be helpful in their role also.
So, we realize that MDM is, can appear to be a very complex equation, so we are trying to, throughout the book, break this down into more practical terms and things that are more digestible and easier to put into planning and program management perspective. So, we think there’s a lot of audience for that type of content.
DYLAN: I guess we sometimes take things for granted when it comes to the various terminologies in our industry and there are probably people tuning in to this webinar right now who are unaware of the different approaches to MDM so can you clear that up by telling us a little about the 3 main approaches to MDM that you present early in the book, namely Analytical MDM, Operational MDM and Enterprise MDM?
DALTON: Sure Dylan, basically data can be classified in many classifications, i.e. domains and as we explain through the book, our focus is on customer domain but it can also be classified in product, partners, suppliers and other things.
But, we can also look at the data from another perspective which is operational data versus non-operational data, and that’s what makes the difference between what we use to define those 3 approaches.
So in the Analytic MDM, your primary focus is on non-operational data, and when you are talking about operational MDM, it is actually churn data, and the enterprise MDM is the combination of the two approaches.
So, we were focused on operational and non-operational data. So, even within each of those approaches, there are multiple architectures and there’s also (Indiscernible) between choosing any of them. So, when you talk about analytical MDM, because address is non-operational data it is usually less intrusive than an operational MDM. Obviously if enterprise MDM is the all-encompassing solution, then it’s very pervasive to the organization.
So to each one of them, if there are multiple architectures, and like you mentioned earlier in your question, there’s still terms and terminologies for MDM. There’s still a little bit of lack of standard for [MDM].
So we have our definitions, but when we try to cover all the possible varieties, but there’s a multitude of combinations. So, when you look at analytical MDM there are multiple ways you can architect how you are going to solve the challenge. You can leverage your data warehouse solution, you can do federated systems, or when you look at the operational MDM you can have a stand through hub and spoke structure or serial hub structure or federated system.
In the enterprise MDM adding to that pile is a combination of the two, it can help all these multiple combinations in registries and all that, that makes the MDM pretty complex.
DYLAN: From your own experiences, what are the principal business drivers for MDM. Is there a common trend or bias that you see or does it vary considerably by industry sector?
MARK: I think the initial drivers for MDM probably most often come from the BI and the IT areas. So reporting and compliance issues are certainly frequent, they are large drivers and as is the overall frustration with data quality or fragmentation or data integrity issues in a company.
So, those tend to light the fire, and then I think if these types of issues prompt companies to start looking at the MDM solutions about there and probably can formulate program.
It becomes more apparent that the MDM initiates to be primarily driven on the business side with heavy accountability and engagement at the data steward and operational support level. Unfortunately, usually the business is not immediately equipped to take the ball and run at that point so they is usually a lot of justification and level setting, program development, research, planning and so forth, that needs to occur first before the program gets off the ground.
But I think once the value proposition, objectives and a lot of the role definitions are determine then I think the business becomes more comfortable with becoming the driver of the MDM program and then you start seeing the business getting behind the program and understanding the value of proposition with it, but a lot of times it starts outside the business and gets the business engaged, that usually is the process..
DYLAN: What are some of the obstacles to the smooth delivery of an MDM initiative that you’ve witnessed? For example, do they tend to be data governance and data quality related or more technical in nature?
DALTON: Well Dylan, I say it’s a combination. It’s really, all of them are so important that they can be a challenge, because they are so pervasive and affects lots of groups, affects IT and multiple groups.
You need all of these engagements and you need really a collaboration between all of these groups so to have a successful delivery, and you are really trying to address all the three components, people, process and technology.
So, when you look at technology or technical perspective you will have multiple challenges because most likely and then improvement is going to include data integration, so in data integration could have data migration, you will have a lot of technical challenges, you wanna be able to apply data quality during the migration, otherwise you will end up with garbage in and garbage out.
So you have data quality challenges and then you also… because in integrating this data from multiple sources in multiple lines of business, you will start to have initially data ownership.
So, data governance and data stewardship become really key components to actually control and arbitrate some of the issues you have and, so any way I want these things have to come up and have to really play together otherwise you won’t have a successful living and plus you need the executive sponsorship on top of it to really make sure you have the proper resources and everything goes in place to move forward.
So, data quality has to be started early and so as data governance data… you know, has to be early and along for it to be successful.
DYLAN: Let’s move now to Part 3 of the book which focuses on Achieving a Steady State and also Part 4 which covers more Advanced Practices.
In the book you have emphasized the importance of establishing “quality culture” and how that needs to be supported by regular data maintenance and monitoring practices, Dalton – can you please elaborate on this?
DALTON: Definitely, we emphasize in the book that quality is everyone’s responsibility. Everyone in the organization needs to be cautious about what they are doing. The organization has the approach of… besides fostering that, they also have to provide the infrastructure to facilitate that.
One of the things, you know, what the organization should try to do is start moving from a reactive state towards a proactive state. Obviously, you are never going to get away from not being reactive and more, there’s always going to be data quality issues that how it’s going to be reactive.
But again you are trying to move towards a more proactive approach and with that you need to start creating conditions and start monitoring the quality of your data and creating score card, so monitors for example, it can be monitoring conditions that can be very critical to the business.
So when the articulation happens you have to alert the business immediately about further damage, let’s say. So that’s when you start to try to follow through this is try create this quality culture and supported, you know, you create monitoring practice is you can also create scorecard, so you actually have a score for your data.
So you know at any point anytime what’s the number you have associated to your data, so you know you are at 80% or 90%, whatever your target is, you can put a number to your data and you can see what is your [0:12:52.8] (Indiscernible). If you are getting better or getting worse with time and be able to correct what needs to be corrected.
So, that makes the air and all these views are tools that you use to focus and create particular data cleansing target and also use the results to derive whatever changes are happening to the organization to the new business group coming.
You have to be able to support it and be able to engage IT, if there’s technology change or the business, if there process change and really be able to have the proper tools to support all of it.
DYLAN: Regarding MDM Maturity, in the book you use this quote from Jerry Wright: “The first sign of maturity is the discovery that the volume knob also turns to the left.”
For the benefit of those looking to deliver MDM, Mark, can you explain what that means in relation to the maturity of a Customer MDM model?
MARK: Yeah, I think there are two aspects to that, one is to promote noise in a height perspective, MDM in the MDM space, there’s a lot of [0:14:34.3] (Indiscernible) and noise that MDM is, you know largely a technology solution and platform, and I think right after the battle, when you hear a lot of that, you need to bow that noise down and start focusing on the business approach, the business support prime work and the business issues that need to be addressed within an MDM initiative.
So, a lot of that is you need to examine and agree on what that is and then the technology solutions can be better evaluated and fitted to a program need. So, a lot of it is to start [0:15:13.2] (Inaudible) the technology focus and get into the business focus.
I think that the other aspect is that there’s a lot of constant variables from beginning to end in the MDM initiative, so anywhere in that spectrum, you know whether it’s planning and scheduling or data migration, testing, process design or in a support or quality improvement, you are going to always have to be prepared to adjust the program Dial, to dial up and down, certain resources and priorities to deal with these variables.
So you really need to have your hands on the dial wheel. The MDM model needs to be flexible, reactive and proactive to succeed over time. So, that’s where the analogy with the dial really comes into play.
DYLAN: One of the chapters focuses on “Creating the Customer 360 degree view”. In this chapter you state that it’s a tenuous road to get there, requiring a solid data integration effort supported by an accurate hierarchy model and good BI.
Can you talk about this tenuous road and the sort of difficulties some of our members are likely to come up against when attempting to reach a true 360 degree view of their customers?
DALTON: Yeah, the 360 degree view, I mean the reason for the tenuous road is because, it requires fitness for use of the data as well as a timely distribution and availability of the data.
So when we are talking about fitness for use, we are talking about proper data integration, proper data quality and proper organization, because if you have data that’s not integrated, then there’s no complete view.
If your quality is low, then you cannot trust your view, and if the result is not organized, it’s going to be difficult for you to understand it, but if the data is integrated, organized and good quality it should be delivered on a timely manner.
So, we have the services person that’s on the phone with the customer, it needs to have the information readily available about that customer, should be able to properly respond to the present request.
The other challenge which we have on the 360 degree view…. So, MDM is concerned about the identity information so you are focused on the identity of the customer and plus it’s related information, but now we also should be able to get all the information that we need, you actually extend it and link all the information to your transaction information, should be able to understand which way your customer is going.
So, that’s what makes it so complex, but the thing is you gotta be able to collect all the data because on the systems in the past, they have been collecting a lot of information, but a lot of information does not mean it’s good information.
So you have to be able to collect information but at the same time make good usage of it, and make sure it’s connected to the right components to give you the view that you are looking for.
DYLAN: Although the book focuses on Customer MDM, you also talk about the concept and challenges of implementing an Enterprise MDM model across a multi-domain structure.
For those new to this, what exactly is the difference between a Customer MDM model and an Enterprise MDM model, what is a multi-domain structure?
MARK: Well, certainly a customer MDM model is going to focus primarily on the customer identity and customer relationship information.
Throughout the company, you are not related to… it may be termed differently depending on the functional area but, whether it’s a customer account, a partner, a member, a contact or prospect, those are going to all be the entities that are going to be considered in the customer MDM model, and the other relationship identity information related to them is the key of what’s being managed at a master data level.
Certainly, moving forward with MDM in a multi-domain structure, that presents a whole next level of program management challenge, because that the hard of any one MDM initiative is to really be the need to get the single version of truth and the system of record equation figured out.
If you are successful with that, getting MDM underway, the next big challenge is to figure out how you are going to get more domains spun up and orchestrated in a multi-domain program.
So, that raises a lot of immediate questions about what aspects of MDM planning and execution are repeatable, scalable and definitely unique within a multi-domain scenario.
That start to think by the focus of an MDM program office, it may also be called Enterprise Data Governance Program office, but this is really the core team that establishes the foundation to look forward with the multi-domain program and they are going to provide the cross domain program leadership, follows the standards, services… you know, research focus to help, facilitate and support a multi-domain structure.
So, in a multi-domain structure you may be looking at… you know, also trying to manage from an MDM perspective, your product data, your HR data, your financial data, any number of other domain areas that I think, typically come up in a multi- domain discussion.
You really need to be sure though that even though the each domain area is going to have fair amount of unique focus and objective to let do their domain, they need to be awarded and integrated with the multi-domain model in the program of this objectives.
I think (Indiscernible) can be not really, you know, you gotta run into a lot of potential common elements in redundancy. This is going to be a lot of common need across domains that quit cause… issues with redundancy and excess demand on IT or on budget or other aspects that need to support the MDM program.
So, this is what needs to be coordinated and that’s the role for program office. So, a lot of interest is in understanding the needs and the redundancy that’s going to be in the services they are going to appear across multi-domains and that not really is the responsibility of having a program office that needs to be spun up, I think and have that charter early on.
A problem though can be that the program office is too broad and normally controlling it’s, maybe over shooting its value and starts to provide, you know take away the authority of… you know, it’s too instructive and it’s taking away authority and empowerment from the domains themselves.
So, it’s important that the multi-domain program office, you can try to derive too much the homogeneous model, you know that kind of start’s to dilute the importance of the demand and it focus itself…
So, I think the multi-domain program is really… you know, it’s not a cookie cutter, follow the bouncing ball type of affair, it’s really a orchestration of a lot of unique programs that have common trend and a common Enterprise MDM [0:23:25.8] (Inaudible), you know with different domain specific objectives, the priority is that the program often seems to recognize and it will support itself.
It’s just that the higher level of challenge is trying to manage multiple programs… it’s something that is important in moving too , but I think a lot of additional planning placed ahead of that.