MDM & Data Governance: Better Together

Join Nicola Askham, The Data Governance Coach, as she discusses the relationship between Data Governance (DG) and MDM, how they benefit each other, and how to get maximum value from both. Specifically, you will learn:

  • Why: It’s not one or the other; MDM and DG are better together
  • What: Prioritize your MDM and DG efforts by knowing where to focus and what to prioritize for quick wins
  • How: Know how much DG you really need and when; before, during, and after your MDM implementation

Video Transcript:

It’s really great to be able to to join you for this webinar, because, I’m sure that, you know, everybody listening in is aware of the importance of managing your data properly. Otherwise, you probably wouldn’t have joined us in the first place.

And since you’ve joined this prophecy webinar, it’s quite likely that you’re interested in multi data management as well.

But, given the title that we publicize this webinar under, I’m hoping that you also have an interest in data governance. Now, as as kind of we probably alluded to in the, introduction saying I’ve been doing this for seventeen years, it’s it’s something I’ve been passionate about for many years now. And I’ve been on a mission, in recent years to help organizations get real value from their data by treating it and managing it as an asset. And during all the time I’ve been doing data governance, I’ve been involved in quite a number of master data projects.

And, yeah, let’s be honest about this. In the early days, it was with varying degrees of success. Now that was probably down to a number of different things, including perhaps my inexperience.

But I think it was probably more likely to be my inability to articulate properly why master data projects need data governance.

And I think that many people suffer from this, and it’s often because they don’t fully understand what data governance is. So before we dive into why you need both together, I think it’s probably important and would be sensible to look at what data governance is first. Now being a bit of a data governance geek, I do love a good definition, and this is the one that I currently use.

So you can see, I’d say it’s proactively managing your data to support your business, achieve its strategy and vision. Now if you Google online, you can find loads of definitions, that will tell you more what data governance is. But as you can see here, I like to focus on the outcome. If you tell people that you’re going to implement a framework of roles and responsibilities and, processes to manage and improve the quality of your data, most people are gonna look at you and go, that sounds like a lot of work. I’m not sure I need to do this.

So I have found over the years that telling people the what of data governance is less useful than telling them the why. But if you tell them, you know, your business clearly has a corporate strategy and you’re probably implementing master data management to help achieve part of that strategy and vision. So therefore, using this kind of definition, we can explain that data governance is a good part of that.

So that’s all very well, and I bet you’re saying, yeah, that’s great, but how do we describe what it really is? Well, yeah. I think that you implement data governance by putting in place a data governance framework.

And, you know, I feel quite strongly it’s made of three things. Now this is just my personal view and this is a slide from the training that I I use, where I say that a data governance framework is made up of three things. A policy, and this is the thing at very high level which mandates doing data governance in your organization. This is the policy which sets out what you’re going to do in your company to manage your data properly.

We have some processes to follow because if we don’t have documented and agreed processes, the chances are we’re all gonna do things in an inconsistent manner. And I might do something for the best of reasons, but I might cause you a problem because I’ve changed the data and I didn’t consult you. So we need some processes. And then finally, we need roles and responsibilities.

Now, lots of people go, oh, well, you know, we don’t really need roles and responsibilities. If we’ve said we need to do this and we’ve said this is how to do it, why do we need to call out the roles and responsibilities?

But I’m sure that every person listening to this webinar has been to the same kind of meetings that I’ve been to. And we all agree violently that something needs to be done, we all agree on the action, and then we all go away, thinking that somebody else is gonna do the action. And we come back to the next meeting, and Reid says to me, did you do that, Nithla? And I go, no. I thought you were doing it. And then we look at the other people in the room, and we suddenly realize that everybody agreed that it need to be done, but but everybody thought it was somebody else’s job to do it. So it’s absolutely critical when you’re doing data governance that you have some clear defined roles and responsibilities, because that way, everybody knows what they have to do in order for us to proactively manage our data.

So now that we understand what a data governance framework is, now I do appreciate this is a very, you know, whistle through of a framework. I’ve just done two days of training on data governance, but, this gives you a flavor which is good enough for the topic we want to cover today. But we need to look at the other topic that we’re needing to cover, which is master data. Now this one, I think is, you know, not easy.

Everybody talks about master data management and expects you to know it, and even somebody on my training course today said he had spent hours trying to research exactly what master data management was because he didn’t fully understand it. And I think it’s a common problem. And and again, you know, we’ve got a limited time on this webinar, so I can just tell you a few things, but just to give you a pointer is, you know, we need to find out what our master data is. So master data is, you know, the single source of data that is critical for our business.

And we’re not talking about all of our data. We’re talking about the data that perhaps, you know, key business processes need, data that is used by multiple processes, multiple systems. So it’s moving around your organization.

And it’s really important that we master this data in one way so that we have a single view of customers or, you know, perhaps we have a a proper inventory of our products, that kind of thing. So once we’ve identified what the master data is for our organization, what is really, really important, then it’s it’s kind of easy to say that master data management just refers to the processes that control and manage that data to ensure that we have consistent data, that it’s shared correctly, and it’s used in the right way.

So I’ve heard a lot of people call master data management as a single version of the truth or a golden source, a golden master, whatever terminology works for you. But this is about creating records that we all know and trust and allow us to do whatever it is our organization does properly and efficiently without making mistakes or costing money.

So the question is, you know, but why do we need data governance and, master data at the same time? Because, you know, hopefully, my vague definition of data governance makes you think, yeah, that that sounds like we we might need it. But the master data management, once people got their heads around it, they tend to go, yeah, we need that. And they’re quite happy they need that far more than they need data governance.

But why do you need data governance? Because data governance is gonna put some controls around your master data management.

So that might sound like a bad thing and it might sound like something that’s gonna make your master data project take longer. But I would say, consider this, your business is run by humans.

And sooner or later, without any controls in place, someone is gonna decide that they’re gonna use one of your builds in your master data solution slightly different than perhaps it’s ever been used before. And perhaps that’s fine to begin with because probably nobody else uses that field and they don’t need to tell anybody. But over time, this kind of activity starts to cause problems.

Things go wrong really, really slowly and users start finding that, things are falling apart. Now the best way I’ve got to to describe this is, you know, people understand what data governance is, but they couldn’t get their head around what I was just trying to explain to you. So it’s really important that we understand the relationship with them. And years ago, somebody asked me what an analogy was and I couldn’t think of one. And I came up with one in the end, and it’s, on this slide here. So if we imagined that, you know, our master data solution was a human body, I think it would be much easier for us to get our head around the, situation.

Because if we’re talking about ourselves personally, we know that if we lived on a diet, you know, comprising solely the things you see on the right, junk food, soda, you know, fizzy drinks, sweets, candy, we know that sooner or later, we’re gonna get tired, we’re gonna get run down, we’re gonna get ill, and we’re not going to work and function as we’re supposed to. But on the other hand, if we eat loads of fresh fruit and veg and healthy produce, we’re probably going to be in really good shape and be able to to do all sorts of things and and be very productive and efficient.

So you really should consider your MDM solution to be like your body.

You can’t put rubbish data in your MDM solution and expect the MDM solution to magically solve it for you. So, hopefully, I’ve convinced you that, you need to be putting good quality data into your MDM solution.

So but I bet there’s always someone, and I’m sure there’s somebody nodding here who’s going, yeah, but can’t I do MDM without data governance? You know, I’m sure it’s being done. And I’ll say, yeah. You can do MDM without data governance, but it is very unlikely to be successful or to be successful for any reasonable period of time.

Now, you may be like me, I’ve been to so many conferences and things over the years where somebody stood on the stage and they said, you need data governance to be successful with master data management, but they haven’t really backed that up with facts and information and they haven’t explained why you need to do this. So I’m gonna try and address that for you on the next slide. So master data management without data governance. Well, in my experience, you typically get one of three scenarios.

So firstly, it seems like the data migration goes well. You know, in such kind of MDM projects, you know, perhaps the people on the project have worked really hard to ensure that data was cleansed before it was migrated.

But what you might find is that they haven’t always done this in the right way or they didn’t correctly agree the right matching rules for when the incoming data came in, so it didn’t necessarily go in the right fields.

Or sometimes there’s some great work upfront.

You know, so it all looks good, and your implementation is it’s perhaps hailed as a success success initially.

But if you don’t implement data governance and haven’t made anybody responsible for the ongoing maintenance of that data, then over time, the quality of your data is going to slowly start to deteriorate. So we come back to what I mentioned just before I showed you the human body slide. You know, we start making mistakes. We start using our data slightly differently. And, you know, all of a sudden, the MDM solution is now full of rubbish data, which, you know, people in your business are using to make some key business decisions. So they now might be making the wrong decisions, providing poor service, causing extra costs.

So I I’ve actually seen, you know, far too many organizations spend millions, literally millions, putting in place a multi data solution and they’ve got to the stage where all that upfront effort was wasted because, you know, over time it deteriorates and they’re not much better off than they were before they put in place their master data solution with people not trusting their data.

So that all sounds very well. You know, we had a good migration, we had a little bit of, a honeymoon period where everything was going well. But more often than not, the data migration fails before you even get the data into your MDM solution.

So you never even get your successful go live.

And in this situation, it’s quite often the case that the project didn’t speak to business users to confirm that data was mapped correctly, or perhaps they spoke to the wrong business users, or perhaps they didn’t correctly understand what that data was, or perhaps how good the quality of that data needed to be to support your business processes.

And even worse than that, I’ve even spoken to external systems integrators who’ve been working at my clients who tell me they don’t need to speak to the business users as they’ve migrated data from that type of system before. Now, you know, perhaps I would imagine a world where that might work if every company used every system exactly the same way as each other.

But how likely do you think that is in practice?

I can tell you, you know, it really isn’t a good scenario, and all too often, the existing data from your source systems or your legacy systems isn’t good enough quality to go into the new system in the first place.

And if you haven’t done that analysis and understanding and you haven’t done the data cleansing that you needed to do in the source systems before the migration, you can have all sorts of problems.

And I know of many failed migrations including a massive embarrassing rollback of a major MDM program the weekend before it was due to go live. Because on the test migration, there were too many issues with the data quality to fix that they couldn’t actually go through with the migration.

And these projects are not cheap. Do you want to be the one to go and tell your sponsors that you got it wrong because you didn’t do data governance?

Now, the third scenario, if you think that was bad, the third scenario is even worse.

In this one, the rubbish data is actually kind of forced into your shiny new system. So almost like short shoehorned, if you will. In in one project that I was told about, the project decided that there wasn’t enough time or budget to fix the underlying problems with the source data.

So I, you know, I’ve been told many times, oh, and it’s not the business can fix it when it’s in the new system.

And once I was even told that they had to switch off the relational integrity in the new MDM solution before they loaded the data because the old data would break the database as it was loaded otherwise. So, you know, how crazy is that? Before you’ve even gone live, your shiny new system can’t work as designed.

It’s just, you know, it is as though you’ve shoehorned your rubbish old data into your master data solution in the hope that it’ll be okay in the end, it’s like you cross your fingers and go, I’m sure it’ll be okay.

Instead, you really should be using this as an opportunity to match and merge your data and manage and improve the quality of it.

You know, you shouldn’t be just getting all your old data and shove it as hard as you can until it actually does load into your new system. Because what you’ve got there is no better than your ARM systems and it’s possibly even worse because you may have caused even more problems when you put that data in the system.

And I can tell you from experience, your users won’t get all excited and say, Wow, you did a great job with this new system, you made my life easier. Because to be honest, you probably made their life harder.

And instead of getting excited about it, they’re just gonna complain right away about this shiny new solution, And sooner or later, you know what users are like, they’re gonna start doing their own workarounds, they’ll start creating their own access databases and Excel spreadsheets to manage their processes. And you could actually end up in a worse position than if you’d lived with your rubbish old legacy systems that you had beforehand.

So I get that this slide is probably been a bit doom and gloom, but I really wanted to reinforce the message of what can go wrong if you don’t do data governance for an MDM project. But hopefully, I’ve convinced you that you really should do data governance. But, you know, what happens when you get off this webinar and you go and talk to your project or program manager?

Because, you know, let’s be honest. They’re probably not gonna say, oh, we should do data governance just because some strange data governance lady called Dick called Nicola says we have to.

Kind of thing they’re gonna say to you is gonna be something along the lines of this.

Yes, well, it’s all very well, but if we include data governance, this project’s gonna take longer and we can’t miss the agreed timescales.

So I can see why they might think that, but there’s ever chance it won’t take longer. Because if you get the right people involved from the business, give them the right responsibilities about data from early on in your project, you’re actually gonna save a lot of time in the long run. You’re not gonna have to keep going pillar to post to try and find which business users understand this data. And it might even speed up your project by preventing the kind of issues we discussed on the previous slide.

So if that, you know, wasn’t the only challenge you’re gonna get, the next thing, once you’ve counted that one, they’re likely to say is, well, you know, we’re gonna need more people if we’re implementing data governance at the same time as doing our master data project.

And I can’t disagree with that. I can’t give you an answer to tell them. So yes, possibly you may need more people. But it’s actually more likely it’s gonna be just a change in the stakeholders that you’ve got involved in the project because you’ll be be identifying the right data owners who can approve data definitions and data quality rules rather than just getting input from, you know, business users who obviously have some valuable input into your project, but they might not know or agree with the higher level holistic overview of data in your organization. They might not understand the consequences and the impact of agreeing one definition over another.

So if we have data governance and we have data owners in place, we know we are getting the right people and we can speed things up like that. So the third thing that you’re likely to get told is that it’s gonna cause higher costs.

And, you know, I can’t lie, yes, maybe, if you don’t already have any data governance in place in your organization, you don’t have a data governance manager or a data quality manager that you can evolve in your project, then possibly you do need a bit of extra support to implement it as part of your master data solution.

But, again, it should mean that your project runs more smoothly and is more successful in the long run, which, you know, actually should decrease costs in the long run. So a little bit of upfront investment in getting data governance right really increases the success of your project and therefore should in the long run reduce your costs.

Now, in it, I can’t give you every answer to every challenge that somebody’s gonna give you, but hopefully that’s given you some ideas.

But what I would kind of say is, you know, I’ve done all the challenges, I’ve done all the downside of not doing data governance, but let’s look at some of the the good side. What really what benefits do you get? What happens if you do master data with data governance?

So you’ll see the following kind of things. You’ll see your business being involved in agreeing the data. So what data really does need to go into the solution before you do it? They’ll agree which fields should be mapped and matched to each other. They’ll agree definitions.

Once they’ve done all that, they’ll be helping you agree the data quality that needs is needed from that data. They can help you work out how to measure that, and they’ll actually be responsible for improving the data, not the project.

Although the project may need to help, let’s be honest about that. And, you know, thirdly, what else would I expect? If you put data governance in place as part of your MDM solution, I really do expect your data migration to be successful.

I can’t promise you there won’t be any unexpected data quality issues or some little niggles when you’re doing some testing or some dress rehearsal migrations.

But I can guarantee it’s gonna be a lot more successful and a lot less issues than if you didn’t have data governance. And any issues that you find, We put a data governance framework in place. We can use that to get the right people involved with fixing those issues correctly.

So, you know, that sounds to me, although data governance and MDM really are better together.

And, you know, when Reid suggested that as the title for the webinar when we discussed the topic, I thought that’s fantastic. I wish I’d thought of that before. Because, really, instead of just standing at conferences like so many people saying, you must do data governance if you’re doing MDM, I think saying MDM and data governance better together just sums it up is such a wonderful way of describing it. So I hope that those few slides have convinced you, but let’s be honest, you may well be sitting here listening to me thinking, well, yeah, that’s great, Nicola, but I’ve already started my MDM project. When am I supposed to start data governance?

So this is a very good question.

And I expect many of you have heard of the question, when’s the best time to plant an oak tree? And the answer to that question, if you haven’t heard this before, is two hundred years ago.

But the second best time is today. And I think it’s to be honest, it’s the same for data governance.

Ideally, when’s the best time to start data governance for MDM? Before you started your MDM program.

But if you didn’t, the second best time to start data governance for your MDM project is now.

It wouldn’t be fair of me to just say that and leave you, you know, understanding intrinsically what to do because, data governance can very easily become a big unwieldy initiative that has the potential to derail or delay your MDM project if it’s not handled properly, but it shouldn’t do that.

I’m always an advocate of being pragmatic when you’re implementing data governance, and it’s no different with master data management.

You need to focus on doing data governance, just those things that are necessary at this stage for the success of your data govern of your MDM program.

Sorry. Just don’t try to do everything at once. You can always add more detail, more processes, and roll it out to other parts of your organization in the future. But really don’t try to do everything at once. Just do the data governance you need to do for your MDM program.

So you’re probably saying, yes, okay, so where do I start?

Now I think these things you can see on the slide now are the best place to start. I think you need to identify the data domains that are in scope. So when we talked about master data early on in this presentation, I said, you know, it could be things like customer, supplier, employees, suppliers.

Are you gonna use all of those things, or are you actually just doing an MDM installation for a customer or perhaps just for product? So identify which data domains are in scope.

That’s really, really important. I think you need to agree who is going to support data governance and master data management in a BAU setting. We’re not talking about the project here. We’re talking about what happens when your MDM solution is implemented and the project team wipe their hands a bit and walk away going, well, that was a success. We have an MDM solution in place. We need either a data governance team or a master data team that is going to support that, and they’re gonna be the people that are going to support data governance during the project as well.

They can then help you identify data owners for each of the data domains that’s in scope of your project. And let’s be honest, some of those domains are bigger than others. It depends on your your organization and what you do. So, for you, you might be a very customer facing organization and customer might be the only domain in scope, but actually, because of what you do, you have a vast amount of customer data. And you might find that you cannot agree one person to be the data owner for customer data because you have so much, and it is used so differently by different organizations within your, company.

So perhaps in that instance, you need to, you know, break down your data domain into subsets, subdomains.

But you just need to work out who are the data owners for the data that’s in the scope of your MDM solution, and then you can work with them and the people that they nominate to be data stewards to come up with definitions and data quality rules that are gonna be fundamental to you putting the right data into your MDM solution.

And, you know, remember, reinforcing what I’ve just said, this is not something that I expect the MDM project team has to work out on their own. They shouldn’t be having to worry about data governance as part of the project on their own. They need to be working in conjunction with a data governance or master data team to do all of this.

Now I promise you this is a short list, but if you’ve not done data governance before, you might be thinking, oh gosh, that sounds a lot. Does it all have to be done at the same time?

And I can tell you, no, it doesn’t all have to be done at the same time. There is a a program and an order in which it’s useful to do this. So I thought it might be helpful if I broke this down with the kind of activities you need to do, but by when they need to be done, which is the slide you can see now. Now I think I’ve I’ve done my best to keep this simple as possible because that’s what I like to do with all things data governance. Why complicate it and make it harder than it needs to be?

So before we’re doing an MDM program, if we have the luxury, we should be designing our data governance framework and identifying our data owners. Then we’re in a really great position when we decide to, start doing MDM. But don’t panic. If you already have master data in place, this is just the first thing you do in doing data governance.

In the data governance clinic I ran today, actually, one of the the questions that we discussed at length was, I’ve got an MDM solution. It’s been approved and implemented.

Are you telling me that I need to kind of tear it down and start again? And I came, like, no. No. Absolutely not. But you need to put in data governance to make sure it doesn’t deteriorate and go wrong. So you just follow these steps, but, you know, this is the ideal timing of it.

I would I would just say work with what you’ve got. Don’t not do data governance because you already have an MDM solution. Make sure you put it in now to make sure you protect and maintain the policy of data in it going forward.

Once you’re doing the project, you’re gonna be needing to, agree definitions for the data that’s gonna go in it and agree the data quality rules, which we covered on the previous slide. But these things should ideally happen during the project because they’re gonna be key inputs into deciding what data goes into the MDM solution and what data cleansing needs to be done ahead of it.

Now let’s kind of fast forward to this place where we’re living happily ever after. We successfully implemented our MDM solution, but we mustn’t forget about our data governance then. And what we’ve got to start doing then is, managing any issues that come up. So we need to have a data quality issue resolution process so that users can tell us that something’s gone wrong, that there’s poor quality data or something or data’s missing. And we need to have a very simple, easy, process that people can follow to let the the data governance team know so they can liaise with the data owners to get those fixed.

Now when you know, several slides ago now, I said one of the things that goes wrong is people just start using fields slightly differently. Well, if we have data governance in place, that’s called amending a definition because we actually have a definition now and we know what’s supposed to be in that field.

But it isn’t beyond comprehension that in the future, your business may change and somebody may want to amend a definition.

But instead of them just going, I’m probably the only one using this. I’ll just change this. If we have data governance in place, we have a proper process so that users can say, I want to change the definition for this field. I want this to be allowable, value in it as well.

But instead of people going, oh, yeah. You know, I know Reid. Nice chat. He’s asked me nicely.

I’ll just change that. What we actually say is, great. We’ll go to the data owner. We’ll help the data owner do some impact assessment, and we’ll agree with all the consumers of that data that that that change is okay.

So all these things are done. Now that sounds like a big onerous process, but it needn’t be. But it just protects the quality of the data in your MDM solution.

And then afterwards, I wouldn’t tell you to sit on your laurels. If your MDM solution is the only, data governance you have in place in your organization, I would just use that as your first phase, and I would look to extend your data governance framework over everything else. And if you have done this reasonably well and protected the quality of the data in your MDM solution, By this stage, people will be shouting about what a good job you’ve done and, you know, the opposite of everything I was saying with the challenges. People won’t be saying it’s a rubbish data in there.

There we go. This is great. It is so much easier to do our processes now. We have less customer complaints.

We have less costs or rework.

And you should, if you’ve done this well, have actually people coming up to you. And I’ve had this before going, this is really great. How can I get the kind of benefits that, you know, you’ve given Fred over there? And I can kinda say, well, okay, you you’re not doing master data, but I can come and help you put data governance over your data warehouse or your other source systems.

And this could just start the ball rolling to help you manage and improve data across the whole of your organization.

So that brings us to the end of, the kind of, prepared slides for you. But I’m really aware that we’ve rattled through quite a lot of ideas in a short period of time. But, you know, Reid’s already said we’ll be sharing the recording. But don’t worry if you feel that you’ve missed anything because there’s a free checklist on my website that details everything you need to do to deliver data governance for an MDM initiative, and you can download that for free by following the, link on the screen there.

And I think that brings us to the end. So, hopefully, you’ve been putting in your questions as we’ve been going along. If you haven’t, now is a good time to put them in there. And, yeah, we do have some time, don’t we, Reid, to answer, questions that people have submitted?

Yeah. We do. My gosh. I don’t know that we’re gonna have enough time, but but have been kind of sifting through this as the questions have been coming in. So, I’ll start off with one of the questions. So, Nicola, can you speak to the benefits of data governance with MBM even if there is no change to systems?

Oh, so it presumably, they’re talking, about not physically moving the data.

So, and and that does happen. That is one of the the the many different, MDM architectures you can do. I would say the benefits are still going to be the same because even if you’re not physically moving data, there is a danger that you take the wrong data or, you know, you’re directed to the wrong data on source systems. And I would also, yeah, I’m I’m ever the optimist. Hopefully, that’s come across in this. I’m I’m always positive about things, but I I think, let’s be realistic, Who could say hand on heart that all their data in their source systems was good quality?

So I would say that, yes, you’d get the same benefits. You would get improved data quality. You’d get better matching results from your MBM, and you should get better data. So you your processes should work better.

Yeah.

Yeah. That’s an interesting topic.

Kind of on the same systems tools kind of question.

Here’s a great question. What is the minimum data governance maturity model required to start with a better MDM implementation?

A minimum?

Given what I’ve just been saying, I think, you know, it would be really lovely if we’d been doing data governance a bit and, you know, most of of the, maturity models that I’ve ever seen for data governance usually have five, and there’s normally an unaware at the bottom, which clearly we don’t really wanna start there. And then there’s, you know, initial where we’re just becoming aware of what data governance is. And the middle one’s normally proactive. And I would say hand on heart, most of the organizations I’ve ever worked for get to proactive, and that is good enough for all the data governance needs.

So from that point of view, proactive would probably be an ideal place to be. You’re already proactively managing your data from a data governance point of view before you start MDM, but I think, you know, practically, that’s unlikely to happen. And it’s just not gonna go down well if you’ve just started a project to do an MDM solution or something in your organization has decided that they want to do MDM, and you say, hold on, we need to do data governance. Because to get to that proactive level, you’re if you’re starting from nothing, you’re probably talking even if you’re doing it just on the data that’s gonna be in your MDM solution, you could be talking eighteen months to two years before you could say that you were on proactive, and that’s me being very optimistic.

So I would say start with what you’ve got. Don’t let it stop you doing MDM if that’s what you need to do.

One of one of the people on my training course today was actually doing MDM because there’s an edict, that’s come from their, parent company that says they have to be a digital company within two years and MDM is a key part of that, but they weren’t doing data governance till last month. So they really don’t have time to do two years doing data governance, right, now we’ll start doing MDM.

There are huge penalties if they don’t get MDM in place in two years, So they need to be doing it at the same time. So I think you can start, don’t stay on the unaware stage very long, Move to the initial stage and start becoming aware of data governance and start doing the kind of things we’ve covered in this webinar to to move along at the same time.

Yes. Great. So here’s a great question. At what level do you pitch the data owner owners, senior level?

So I like to say that data owners need to be very senior.

But let let’s be a little bit sensible about this. If you go and ask your finance director to own finance data and you’re a small company, they might say yes and you might be able to access to them and get them to do things. If you’re a large global organization, the chances of your finance director agreeing, even if you can get to talk to him in the first place, to be a data owner and the fact that he would have time to do it is unlikely.

So I would go as senior as is possible, to make decisions. So I say to be a good data owner or a suitable data owner, the person, quite apart from having to care and know about that data, has to be a senior enough to have the budget, authority, and resources to make decisions and changes to that data if necessary.

Yes. Yeah. The higher you go, the the the higher the chance of success.

Yes.

What are some best practices for enforcing governance SLAs?

So yeah. An SLA. I I don’t really put SLAs in place for data governance.

And the reason for this is that data governance as a whole takes a long time. Where I would consider doing it is on a master data solution, so that was convenient given the topic of the webinar.

And I would put SLAs on, things that affect the running of the MDM. So perhaps the resolution times for issues arising on it, turnaround times for agreeing amendments to definitions, or any other changes to any fields, adding new fields, deleting fields. You want those to be done within an SLA.

But the general, the general implementation of data governance takes a really long time, and, it’s more of a culture change than anything else that SLAs don’t work on that. They tend to work on the the more detailed processes, particularly around MDM.

Got it. Nikola, what is the difference between data stewardship and governance?

Oh, that is a good question. So I think that the trouble with, working in data governance is, one, it doesn’t sound very exciting even though I think it is.

The other thing is it’s probably the least mature of all the data management disciplines. And if you Google all these terms, it is so easy to get confused.

Now I think, this is my view, that data stewardship is part of data governance.

So, and the same, you know, I’ve I’ve been asked the same question earlier today on is data ownership differently different than data governance? So I would say data governance, covers both of those things. So you remember the triangle slide I shared earlier, the three key component parts of a framework, one of which is roles and responsibilities.

I think the data ownership and the data stewardship fall under that. They’re part of the roles and responsibilities, and they are key parts of data governance. So they are kind of just one part of data governance.

Yes. You can’t do without it. Right?

Excellent.

Interesting question here. Can you give me they asked for the top three mistakes, but mistakes companies make when starting to get a governance strategy.

Oh, top mistakes. Well, actually, I can cheat and say if you go to my website, there’s a free report that I think has the top nine in there. But I would say, when they’re starting a data governance, top mistakes include, doing it from IT.

It could definitely be a business, initiative about the business worrying about their data and wanting to manage it.

Now this is like gonna if anybody goes and gets my report, they’re gonna say, am I remembering them all? But, I would say others include, misalignment with your corporate strategy.

And I’ve seen that cause MDM failures as well, whereas somebody in IT said we need a new customer system, why don’t we put an MDM solution in?

Because that’ll be good. But they haven’t really consulted the business or explained the business what is needed. But whatever you do with your data, whether it’s MDM or data governance, you need to be doing it in a way that’s aligned to your corporate strategy.

Because if you’re not, you’re going to lose the interest and support of your business.

Because you’re gonna be going and asking them to define data, to to work with you, to define rules.

And if that isn’t aligned to what that senior person is being tasked with to drive the corporate strategy forwards, they’re just not gonna give you the time and they’re not gonna help you.

I think, you know, in the early days of doing data governance, I probably made every mistake that’s in that report. That’s the reason I now tell people, and I love training people now because I say, you don’t have to make mistakes. I did, I can fast track you, say just don’t bother doing that. But I think it’s human nature to say, what can I fix fast and quickly and easily?

So it’s the quick wins or the low hanging fruit that consultants love to talk about. And yeah, I definitely look for some of them for my clients because it helps them. But in the early days, I would definitely go, oh, that looks easy to fix. Let’s put data governance over that.

And people would go, yeah, but that’s not it doesn’t help us, it’s not helping us move towards our corporate strategy, delivering our corporate objectives. And I wouldn’t get the support and the buy in from the business I needed. So that’s a really big one and one that I used to I missed the first few times I did data governance, and and it was a big reason why it didn’t go so well the first few times.

Yeah. But there’s there’s a whole report on that. There’s loads that you can go and read on that on my website.

So so you mentioned quick wins. Right? And quick wins are important to showing value and impact, especially when they’re aligned to a corporate strategy, which is the whole point of doing data data governance is to support the business and the strategy, to deliver, you know, a high to to deliver trusted a trusted foundation of data to the business. So what are a couple examples of quick wins with data governance?

So they can be in all sorts of, places.

I would say you quite often find, manual processes or workarounds that are being done because the data wasn’t good enough or wasn’t available in the right way. That’s where I often find some quick wins is, you know, people didn’t they they haven’t questioned it, it’s just what they’ve done. They’ve perhaps been trained to do that work around when they started the job.

So that’s one of the reasons I like to do the data quality issue resolution process that I mentioned earlier. I like to bet fairly early on when I’m doing data governance because that gives people a chance to tell you what challenges they’re having with data, and you can then use that to identify some quick wins. So, one that comes to mind, in one organization I did, I briefed a number of teams that we were rolling out this data quality issue resolution process. And And at the end of it, somebody came up to me and said, I didn’t like to stay in front of the team because I’m really junior and I might have misunderstood it.

But if I have to spend two weeks every quarter cleansing and fixing the data in a spreadsheet before we put it in our model, is that a data quality issue? And I went, yeah. It sounds like it. And I said, why do you have to do and he said, well, if I didn’t, if we loaded it into the model, it would break the model.

And I went, right. Okay. Yeah. That’s definitely a data quality issue. What’s wrong with the spreadsheet? He went, well, it’s got duplicates in it. It comes in a different format every quarter, and we have to keep changing it.

And, you know, I said to them, so yeah. Yeah. So but why are you using this process? Have you not spoken to people who give you that spreadsheet? And he went, no. I’ve been on the team eighteen months, and when I joined, I was told what the first thing you do at the beginning of every quarter is fix this spreadsheet. It’s just the process.

And this guy, although he was junior on the team, was actually a student actuary, very well paid, very clever chap who should not have been doing that. So if you start working out the salary for a student actuary for, you know, eight weeks every year, we were paying him to just move around data on a spreadsheet.

Mhmm.

So that those kind of things are really good quick wins that you find.

And the other things I find is look at where people are having to do rework. So look at go to the team that does your customer complaints and try and have a work with them, look at the complaints, and try and find out which of these complaints are coming up because of poor quality data. Because if you can find some of them you can fix quickly, then, you know, that helps you. You you kind of you’re not upsetting your customers. You might not have be having to pay, compensation to them, and you won’t have the rework of correcting it every time somebody complains.

So, yeah, all sorts of ways of finding quick wins, and I I there’s loads I could tell you, but we we will run out of time if I carry on.

So I’ve got two more questions. So one of them was, you know, measuring the success of data governance. What are some KPIs?

Yes. So that is, it is a difficult one. And if anybody has really good ideas, please tell me. Every time I go to a conference where people says they’re gonna do measuring the value of data governance, The trouble with data governance is you will deliver benefits, but you don’t necessarily know what they’re going to be and where they’re gonna be until you’ve done it, which makes it so hard.

You know, it’s a really hard sale to say to somebody, let me duplicate governance because I’ll stop things going wrong, but I don’t know which things yet. And so, you know, KPIs are really, really hard. So I tend to do KPIs to, monitor the progress of implementing data governance rather than the value that you’re getting from it. So I will kind of measure how many data owners we’ve identified or briefed, how many, data items we’ve got, definitions in the glossary for, how many data quality reports we’ve now got in place.

But they’re they’re measuring progress on your implementation and not on your actual value. So that’s another reason I like my data quality issue resolution process because those are thing they are physical things that have gone wrong and that you can fix by having data governance in place, and therefore I tend to report them not in the format of KPIs, but I tend to shout about everything I’ve done. So if you say thirty thousand by fixing some loophole or problem, then shout about it, put it in your reports, make sure everybody knows about it, because to have regular KPIs is not easy because you can’t even say money saved this quarter because it might be time you save rather than money or it might be you save the company from reputational damage.

It’s it’s a really, really tricky one, and I wish there was an easy answer for it. It would make my life a lot easier.

Yeah. No. It makes sense. Last question.

Can you share some information on the roles and responsibilities of data owners and stewards, assuming there’s a difference between the two?

So, in in a few minutes, not a complete thing, but I would say, generally, your data owners are the very senior people who are accountable for the quality of one or more sets of data. And that will include making sure it’s defined, that it has data quality rules, that we understand what that data is, where it is.

Now if we make them a senior, as we discussed, just a few minutes ago, the chances are that they don’t understand the detail of the data, and therefore, they will need to nominate one or more data stewards to help them.

And the the data stewards they nominate will be, usually people in their direct line who are subject matter experts in that data. So an example I often use when I talk to new clients is, you know, let’s say, you know, everybody tends to agree that the finance director or his deputy probably owns finance data at your organization, that’s an easy one to sell.

Finance departments are usually made up of multiple different teams, each with different areas of expertise.

So what I often find is the finance director goes, yeah, I’m the finance, data owner, but I’m telling you the five people that head up each of my five teams to be my data stewards because they’re gonna do the doing for me.

So when we talk about all the kind of things we’ve been talking about today, we’re talking about definitions. I’d expect the data steward to actually draft the definition and give it to the data owner to approve. The same with data quality rules.

If we have a data quality report that shows that something’s not being met, I expect it actually to go to the data steward to action and just the data owner to be keeping some oversight on that and making sure it’s actioned. And the same with data quality issues, I usually write a process that says that once notified of an issue, the data governance team will notify the data owner so that they can investigate the cause of the issue.

In practice, I will probably email the data steward because I know that they know the information, but I will keep the data owner copied in because they’re the one that they’re on the hook. They’re they’re gonna be accountable for making sure this is is fixed, but I know that they don’t have the time or necessarily the knowledge to do it themselves. So the the real difference between the two roles is just delegation, and everybody know can only delegate responsibility, not accountability.

So the data owners are accountable for the data, but the data stewards doing the work for them.

Yeah. Pretty straightforward.

Alright. Well, I think we’re gonna wrap it up.

Nicola, what a great presentation today. You know, we had such a high attendance rate even through up to this point of the webinar, so that tells me, you’re an excellent speaker and the topic is very relevant and important to many. So, we certainly thank you for your insights and your thoughtful recommendations today.

Any last words before we sign off?

No. Thank you for asking me. I would love the opportunity to help more people do data governance. So this has been great fun. Thank you.

You’re welcome. Well, thank you everybody for attending, and we hope you have a great rest of your day. Take care.

LET'S DO THIS!

Complete the form below to request your spot at Profisee’s happy hour and dinner at Il Mulino in the Swan Hotel on Tuesday, March 21 at 6:30pm.

REGISTER BELOW

MDM vs. MDS graphic
The Profisee website uses cookies to help ensure you have the best experience possible.  Learn more