 Hello and welcome. My name is Shannon Kemp and I'm the Chief Digital Manager for Data Diversity. We want to thank you for joining the latest in the Monthly Webinar Series, Data Architecture Strategies with Donna Burbank. Today, Donna will talk about master data management, aligning data, process and governance. Just a couple of points to get us started due to the large number of people that attend these sessions. You will be muted during the webinar and we very much encourage you to chat with us and with each other throughout the webinar. To do so, just click the chat icon in the bottom middle of your screen to activate that feature. For questions, we will be clicking them via the Q&A section in the bottom right-hand corner or if you'd like to tweet, we encourage you to share highlights or questions via Twitter using hashtag, DA Strategies. And if you'd like to continue the networking and conversation after the webinar and to learn more about Donna, just go to community.dativersity.net. And as always, we will send a follow-up email within two business days containing links to the recording of this session and additional information requested throughout the webinar. And just a note, Monday is a U.S. holiday so the follow-up for this email or for this webinar will go out on Tuesday. Now let me introduce our speaker for today, Donna Burbank. Now Donna is a recognized industry expert in information management with over 20 years of experience helping organizations enrich their business opportunities through data and information. She currently is the Managing Director of Global Data Strategy Limited where she assists organizations around the globe in driving value from their data. She has worked with dozens of Fortune 500 companies worldwide in the Americas, Europe, Asia and Africa and speaks regularly at industry conferences. And with that, let me give the floor to Donna to get today's webinar started. Hello and welcome. Thank you, Shannon. Always a pleasure to be on these webinars. And for those of you who are not aware, as Shannon mentioned, that this is a monthly series. As Shannon also mentioned is often one of the most common questions. Will this be available later for replay or will the slides be available? Yes, to both. And if you missed any of the other topics from other months, they are all on demand on the Data Diversity website as well as Data Global Data Strategy has a link to them as well. And you can see any of the other topics that you may have missed or may be interested in. We also have upcoming in June enterprise architecture versus data architecture. We'll be talking about some of those topics on this presentation, things like process modeling and capability modeling and some of that. So we'll go deeper on that next month. But today's topic, and Shannon told me this was one of the more popular ones this year. And I'm not surprised because master data is hot. Again, like a lot of the technologies we talk about, I've been around for a while, but like with everything in data is seeing a massive resurgence. And I was telling Shannon before kind of a pre break of I think like 60 or 70% of our current clients are doing some sort of master data initiative. So, you know, one of the benefits of master data is that it does give you that clean, consistent data asset for things around customer or product or supplier or patient or student or, you know, the list goes on and I'm sure you have a list in your organization. Getting that right and we'll go into more detail is a challenge. And, you know, like any technology that's popular, whether it's data warehousing or data lakes or, you know, do they work and are there problems? Yes, of course. I think with master data, are they successful also? Yes, right. I think master data is particularly complicated. And again, you can say this about a lot of technologies, but it in particular is that sweet spot balance between not only the technology to get master data right, but also the people and the process and the governance around that. And I'll talk a lot more about that of how you get those three to work. And each MDM implementation has a different percentage of the balance, you know, some governance is much more about process and governance. Some is much more about technology and automated matching and things like that. So we'll go through that in more detail in this presentation. So before we jump ahead to that, sorry, so MDM, as you've seen this slide with me before as well, is really part of a wider strategy. And I always look holistically at all of it at every implementation of anything, because everything is interrelated. So part of master data management is data quality and quality data. Part is the architecture around data governance. Some of it's the pure master data itself. Data governance is a big part of that, as well as business goals and drivers. Sometimes the hardest part of getting master data right is knowing what to master. Sometimes it's obvious customers often a popular one, but that's not the only thing you could master. It could be location. I mean, when we come into a client and do an assessment, that's often what we think of strongly of what is the ordering of that. And sometimes it's not intuitive. One group I was working with, they were doing a customer centricity effort. And it was all about the voice of the customer and the view of the customer. You would think the first piece of master data they mastered was customer, but it wasn't. It was actually some of their supply chain and material, because their biggest customer issue was getting their products delivered on time. So give that some thought. It isn't always the obvious one. It might be something that's related. Not that they didn't master customer later, but that actually wasn't their first thing to master. So if we want to go back to core definitions, what is master data? If we're in data management, we're fans of definitions and getting metadata right. So I took this from Gartner. It really is that consistent set of identifiers and attributes around the core entities of the enterprise. So I mentioned that. Here's some other ones. Prospect, citizen, supplier, sites. And we'll talk more about that. What do we mean by those identifiers and attributes? That's a big part of getting master data right, really knowing what pieces to master. And then master data management, and maybe that's self-explanatory, but that's the management around the master data, right? So they are related. And again, that's almost the point of this presentation, is that you can't do master data in a vacuum. It really is about the processes around it, the management around it, and the governance around it as well. Just some points of fact. If we're all data people, we like data points. So a couple years old now, but still relevant, and the numbers are probably even higher. We had done, with Dataversity and Myself, a survey of some of the major trends in data architecture. And over 65% of respondents were pursuing some sort of MDM strategy, which I found was interesting. Again, might even be higher now. That was about a year old, but I'm seeing a lot of it. What I think was also interesting was when we went a little deeper into that and asked, what's your level of maturity? Are you just starting or have you been around it for a while? A lot of people were just starting. Again, master data has been around for a long time, but I think as people are trying to get that voice of the customer, or a lot of the kind of sexier technologies, digital marketing and advanced analytics and artificial intelligence, all of that requires good data. And really, master data is of a core of good data. It's kind of the unsexy cousin of some of those sexier technologies. It's the engine that really makes everything work. And nothing more and more companies are starting to realize that. As you'll see here that either people were in their initial stages, they're just beginning in a few, or actually a few, a larger level of maturity. But you're not alone if you're just starting. And I'm assuming if you're joining this webinar, you may very well just kind of be in the early stages. So as I just alluded to, sort of the nirvana of this is sort of getting that if we talk about customer master data, and again, that's not the only thing to master, it's often the easiest one to relate to, is this idea of the mythical three, the 60 view of customer, right? How do we know our customers or our patients or our students or our members, right? So, and this is a fictitious example, you know, if we have our Stefan Kraus and I'm a, I'm an outdoor sporting goods company, for example, and I sell retail. Well, I have this member and I know he's 31. I know some certain things about him. I know that he purchased some of our products, you know, back in 2015, he purchased about 500 euro worth of products. He's a ski instructor at St. Merritt. So you'd think he'd be our perfect customer, right? He lives out in Pontresing the Switzerland and he's actually the top finisher in the Engadine ski marathon. If you've ever done it, it's awesome, one of the prettiest ones in the world. I love it. Anyway, and he's been our member of our loyalty program. You'd think he's the greatest customer we have. You know, he actually interacts with our online store. He actually, though, doesn't spend a whole lot of money with this. I mean, 500 euro is nice, but that's like a pair of skis, if that, right? Because he's actually, he's such a good skier and he's a good looking guy that he actually gets a lot of sponsors. So he doesn't really, he's actually, he'd be great poster child for a company, but he's really not our best customer. All right. And if you're in retail, you think about a lot of these things. What, what information do we know are core things about purchasing, but also what would we like to know? Can we get external data like he won a ski race? Can he perhaps be our sponsor in the next ski race? Right? Who knows? But if we look through our data, there's Stefan Kraus, age 31. There's also another Stefan Kraus and he lives in Zurich and he's 62 and he's a banker, a little overweight, kind of an older guy. He actually, you know, really likes football or soccer in the U.S. He doesn't really get outdoors very much. He goes once a year, he goes hiking, takes a plane to get there and spends a lot of money when he goes. He's like, I'm a banker and I make a lot of money when I'm on vacation. I want the best gear. I actually had a friend like this who's a doctor and he went to, I think it was North Face and he, he wanted the most expensive jackets they had. And they were sort of saying, oh, do you go rock climbing, mountain climbing? He's like, I'm going to walk my dog and I want to be the warmest I can be. And I have no qualms about it. I make a lot of money and I want the best jacket I could. So if you look at this gentleman, he only goes hiking once a year but he spent, you know, 3,500 euro on his trip. So he ironically is your better customer, right? But if you look at it, they're both named Stefan Krauss. One happens to be 62. One happens to be 31. One lives out in Pontresina. One lives in Zurich. Very different customers, right? So I want to be clear and I'll get much more detail on this. So when we talk about this 360 view, that's not master data. And I think there's a lot of confusion about it. It could be, but a lot of this analytics you want to do, what are their purchasing patterns? What are their best stuff you can do once you have master data, right? So you could very much get this wrong and you could email the wrong Stefan Krauss. In fact, this older guy, he doesn't want email. I don't even know how to use my phone. I want all my mail, physical mail, coming to my office and my secretary opens it and tells me what's important, right? Very, very different customers. They happen to have the same name. And some of you might be shaking and nodding your head and I've worked with many customers that this has been sort of embarrassing, you know, John Smith. There's a lot of them. Is it John Smith, the billionaire? John Smith, the person that went bankrupt? Do you know? Or is it Jay Smith? And it's really his sister, Jane. And we didn't get that right. People are complicated and they're kind of the hardest thing to master. So just more kind of definitional because hopefully this is an educational webinar. Another, maybe not a common misconception because I think people are getting this more and more, but the difference between transaction data and master data. So master data are really your nouns. You have a lot of transactions around these retail transactions that Stefan Krauss go back to him. He's a telemark skier and he bought a ski boot with a certain code, a certain price, at a certain time and same rates. I'm also a skier. I bought the same ski boot and I bowled in Boulder, Colorado where I live and et cetera, et cetera. So you know, all the codes, all the prices, those transactions themselves are not master data. I almost think those, the verbs, if you think of that of when did Stefan buy something, how much did he buy, et cetera, et cetera. The master data is the fact that your customer is Stefan Krauss. Those are really your nouns. You could say that your product, the fact that you have a Scarpa telemark ski boot, is the same, but if you look, those are those product codes are different. Do we want them to be different product codes? One's in Europe and one's in the U.S. And is that by design or is that a mistake if someone typed in the wrong number? Is our pricing correct across all the regions, et cetera, et cetera. So that's sort of the difference as we go through between, I'm sorry, someone keeps moving my slides. That's sort of the difference between transaction and master. So here's another slide that sort of shows that, that your master data is going to be your core things like customer. So Stefan bought three products. There's still only one Stefan, right? So trying to get that or is there an S Krauss or that Donna Burbank is another customer and Wendy Hu and John Smith, et cetera, et cetera. The other master data would be your product. We have similar product codes, price codes, et cetera. Location could be one and we in this industry can often get very nerdy about definitions and semantics and we should because that's what people pay us to do, but I think that would be our worst enemy. But it's a valid question. Sometimes we argue what's reference data and what's master data. So location might be a classic one. If I'm trying to master all of my locations where I sell products, that might be master data. It might be all my stores. That might be my master data. For someone else, that might be reference data. Probably things like the country codes could be reference data and probably here that's important because CO is a state code that's Colorado, CH is the country code and that's Switzerland. So getting that kind of, again, that's where master data can be kind of the unsung, boring hero is that getting country codes right and whether it's CH or CO is maybe not the most exciting part of one's job, but you can't do all of the sexy stuff like the science and advanced analytics if you don't have that right. Are we talking about customer? Are we talking about countries or are we talking about states? They're very different things. Are we talking about locations where this person lives or where they bought the jacket? That could be very different if you think of our Stefan that lives in Zurich. He bought the jacket in Mallorca, right, but he lives in Zurich and what location are we talking about? So again, why master data is kind of the sweet spot of a lot of different things in master data management because you have to get all of that right to really get your master data right. This is sort of you're the black diamond ski trail of data management when you're getting master data right. Yet the benefit is huge and it's worth it. So if we go back to this slide I've been sneaking at you here and again. This to me is sort of a very high level architecture of kind of master data 101. So yes, there's a lot of ways one could implement master data and I'm not getting deep into that today, whether it's hub and spoke or more federated model. This is almost your classic way to have kind of a centralized view. I wouldn't knock it though because when you really look through that, it's often a very helpful way to get that single view or what we call the golden record. So part of the issue, as you probably keenly aware, you probably have, if we go back to the customer example, you have customer in a lot of different systems. You might have a customer data in your CRM or your customer relationship management, your store systems, your online stores, your in-store sales, those people that have purchased things are probably also in your finance system. Marketing is sending things out to your customer list, right? You have online sales, you know, in addition to in-store sales. Supply chain is shipping things to those people, as I mentioned. Remember that customer that kind of either were doing customer mastering but started with supply chain. So all of these systems sort of above all have their view of what customer looks like. And those little data model pictures I have are sort of the complexity there is that they all have their own way to store customer information and part of the biggest challenge is getting a single common data model. As you know, I'm a fan of data modeling. The other thing and this may be the case but most often isn't. So, you know, especially some of the tool vendors, every almost to a person, even the most friendly tool vendors, when we start to talk about MDM, yes, but I'm the golden record, you know. Like, well, I'm the Queen of England. I think everybody wants to say, well, I have the view of customer. Well, everyone has their view and that's part of the challenge is with anything with data management. You own customer data when you're talking about in-store sales if you're the in-store sales system. I own customer data if I'm the CRM system and try to do customer release management. I may interface with the other. So that, again, is why often master data can be as much as a political challenge as a technical one. I think often where there's the most misconception partly by the vendors or because that's what it was purchased to do with CRM. You might say, yeah, I have CRM. Do I really need master data? Well, yes. Unless you really, truly only have one system that is CRM and all very single one of your customers is in there and that's fine. Generally, there's other systems and generally, as with any of these systems, those particular systems were purchased to do a thing, you know, to network with your customers or to send out email campaigns or to buy things, you know, have people buy things from you and they weren't really designed to get that golden view of customers to push out. So that's kind of the first step of just getting all of your sources together, understanding ownership around those sources, understanding the data models and how data is stored across those systems. Kind of as we go through, then the idea is how do we get that subset of attributes into my MDM? So maybe I have a thousand attributes about my customer. If you think back to, you know, the two Stephans, you know, what their income is and what their age is, but maybe just to master it to get that one view of an individual, maybe it's just 10 attributes. They're named, you know, and often you want to start small with that subset of master data. If we could just get the name, address and telephone number and email of this person, that's what's going to help me uniquely identify them. So in a way, and in the slide, we kind of have kind of two options. It's either the superset or the subset of the above systems. Maybe only email is in, the name and email is in the CRM, but the name and income lives in your marketing, and that's what you want to master. You kind of have to have that master data to get that superset. That said, if you took the superset of all these systems, it could be a thousand. So you really, and that's often a workshop and kind of activity, talking to all your data owners and data stewards and governments, what really is that golden record that we absolutely need to get right, that we want to cascade back to the other systems. And so that is an effort in of itself of just what to master. And it's an evolution, like anything. You don't have to master everything you're ever possibly going to master all at once, but it is something to consider in your design. So as we sort of go through, part of how you can do some of this matching is what's often called matching rules. And this is where, I mean, none of this is brain surgery, right? In the perfect world, we would just know that Donna Burbank, Donna Burbank, but again, people in particular, I used the customer example, on purpose because they're often the A, I have a lot of value in the organization, but people are messy. A product code is a product code. It can be hard to master, but it's a little simpler than people who have, who change names, who live in different ad, who don't, maybe don't want to have the single view of them and put in fake email addresses and all the above. People are complicated. So there's a lot of ways you can generate these, what we call matching rules, to how do you know that it's the golden record? You have 17 different systems. Anyone who's out there in the real world is probably looking at my, what are they, six systems and scoffing. If we only had six, you probably have a lot more. Now then that's part of the identification of what do we even store together. So there's some magic and some science between how we do this matching. So for us data geeks out there in a perfect world, everyone will be born with a unique customer identifier, you know, kind of tattooed to their forehead. And we would know that there's one Donna Burbank that is different than the Donna Burbank that lives in Kansas and then one that was in New York City, right? So, you know, my name is not an unique way to identify me. So in some systems, if you are one of the lucky companies that has a unique customer ID that is absolutely correct everywhere and cascade across all systems, that makes master data a bit easier, right? And sometimes there's multiple kind of versions of that reality. Might be true in some cases, but generally, you know, as with everything, there's always exceptions and often there's several unique identifiers for a customer. I had one company that had, I think, I think the record I've seen was like 17 unique identifiers from different systems and I kind of stored them all. Kind of like how many standards you have for the same term, right? So often what you do, and this is sort of, you know, data modeling 101 for you data modeling fans out there, you have your kind of, you know, your unique key that you've generated, you know, your target key and then you have your natural key. So often especially when you're doing master data, you want to kind of have these ideas of what would be a realistic way to match someone. If I know that Donna Burbank has a certain birthday, is that going to get me the unique Donna Burbank who's talking to you right now? Maybe. How many Donna Burbanks were burned on my birthday? Probably not too many, but probably more than one. And what if you use my social security number and my date of birth? Do we even have that? What if it's my first name last name? Etc. Etc. And probably depending on the system, they're probably depending on your data quality. There's more than one check, but and there's also a lot of performance and indexing and, you know, reasons why you don't want to match on everything about the person. And that's kind of that, that again, the art and science of what are those keys that I can be certain that it's the same person without going insane and matching on every attribute I could possibly know about them, right? And making sure the data quality. So, you know, email the classic one. Who else there wants to give all of the vendors you've worked with your correct email? You know, Fred? Who puts dumb at dumb.com, right? Until you realize you actually have to put it in to get something and then you put your real email. So there might be two emails when you first put dumb at dumb.com and then my correct email and all of that, right? So there's this human nature and all of this as well. One of the things can help with this, because even if I legitimately are trying, and again, I'm working with a couple of customers and this can be a frustration to a couple of clients and their customers. I told you this information. I actually logged into your loyalty program and I told you everything, my interests and my hobbies, and then I went to buy something and you didn't know. Well, we know why in data management. Those systems in the back end didn't talk to each other. So, you know, as sometimes they do, you want to make sure it's right. So it isn't always malice. But one way you can sort of help with that is this idea of fuzzy matching. And there's different algorithms that can do that. You know, sometimes is, you know, it could be a data quality. Is J Smith and John Smith the same person? Is Street or Street or ST or underscore, et cetera, et cetera. So how can you create some of these kind of matching rules and matching algorithms? And then again, it's a continuum. So how do I, if it's over 90% of certainty, can I just automatically match it? Do I want a person to validate it? And then depending on the business case, maybe it's a marketing campaign and I'd like to know that Tim and Timothy aren't the same, are the same person who aren't. But worst case, Tim doesn't get a marketing email or he gets two, might be embarrassing, might be awkward, but it might be a little different if you're talking about patients and beds on a heart surgery, you know, floor. And I really don't want to operate in the wrong Tim Smith. So again, this is something mastered. Again, part of the complexity is you getting that right level of comfort. And it's also over time, it can change. And this is where I think it ties nicely into my kind of next piece of this is the idea of human in the loop. So often you can, you don't want a human every single time there's a match to have to go and have some poor intern come in and clean up all the Jay Smith versus John Smith. That might be a fine first effort, but a long term that's probably not ideal. But in some cases you may absolutely want a human to be in the loop. And maybe the heart surgery is a great case before we check this or a new, actually I'm working with a hospital and before they onboard any provider, you know, a doctor, they can do all the matching. But there's a person actually in the certification team that makes sure that John Smith, the doctor is really the John Smith with the doctor that has the right certification to do surgery on your child, right? So yet you hope there is a human loop for some of these. But also as you sort of train that algorithm or get your algorithm right to do that fuzzy matching, you may have a higher percentage of data stewardship validation in the beginning to say, okay, I think this is John Smith. And you know, is it the right match to say that street is the same as ST probably, but let's check it for a while in Iran. So again, this is a dynamic thing. But this is also where it ties into governance of who are those right people to do the validation. Do we need a human in the loop? Maybe I'm a massive online retail store. I certainly, every time I want to buy something on Amazon, don't want to have to send that to a person to make sure it's the right person before they buy something. Again, very different than somebody going to do surgery on your child. Yes, I want someone to take a look. So again, this is sort of the gray area when you're doing master data management and you want to get that right. The other thing I've seen kind of go either right or wrong, depending, we'll talk more about governance and stewardship, but getting that right person. I've seen the right person. And when we talk about stewardship, often stewards are already in the organization and they're named not found. When we implement data governance, who's that person that knows everything about our customer, about our suppliers, or has all our product codes memorized in their head? You probably know who the data stewards in the organization are. They're often the right person to do kind of that match checking. Or maybe not. Maybe it's the receptionist at the front desk who actually knows everyone by name and knows that that's John Smith or Jay Smith and their twin brothers. They probably know everything about your customer. Maybe they're the best person to do that. I've also seen it in the wrong end where, oh, I'm going to have the data owner do it because they're responsible for it. And one poor customer and MDM didn't go well and MDM failed not because the technology is not going to do anything, but they had senior level VP's going through doing all this matching for several hours a day as part of their migration. And the idea was, well, yeah, they own the data. They're vested in it, but really bad use of the VP's time and sort of killed the project because if they thought, well, if this is MDM, sign me off. So again, that's kind of the softer side of getting some of this right. And give some thought to that human loop. And a lot of the MDM tools out there, I'm not specifically talking about tools. I try to avoid that. But each of these pieces of the functionality, when you do look at an MDM tool, think of the relative need and cost and benefit for all of that. It is a good data stewardship interface, really important to you for an MDM tool. And or what about that footing matching? Is that going to be the harder thing that I need the computer to do it? How about the interfaces between all these systems? Is that what the most important thing is? Because there's plenty of good MDM tools at various level of prices. It really is what matches for your business process and your business case. And we'll talk more about that as we go. So as we sort of get the data right in that MDM hub, or what I'm going to call it, kind of a nirvana is what makes it different from reporting. And we'll talk about that a lot. These MDM records, these golden records should be active records and the ideal. And there's several things in place that we've already talked about. You have to make sure the source system will accept this. You'll have to make sure they have an API or something you can read that the data model is right. The data quality is good. They have the right steward, all that. But once that is in place and things work, you know, it seems so banal and boring to someone not in IT. You're in the system and John Smith comes in to check in for his doctor's appointment and you say, oh, John Smith, you still live on Main Street. And yes, okay, we're done. And they don't have to fill out yet a new form. That really is the MDM. I guess the example I give a lot, the only place I have any credibility in this planet is with the airlines because I'm a consultant and I live on a plane. But my particular airline, we all love to hit the airlines, but they actually get this rather good. I was, this last year, I was trying to book a flight online from Denver to London. For some reason, I couldn't book online. So I called kind of a, you know, I fly a lot number and they knew my phone number and they said, oh, Ms. Burbank, are you calling about the flight you're trying to book from Denver to London? Yes, I am. And it wasn't creepy. You have to think of the creep. But they knew I would hope they would know me. I'm a prime member. I fly every week. You're trying to probably match the flight you took last month in the same time frame. Is that right? Yes, they knew all that. So I didn't have to call the number and explain who I was and all my pass codes. And they just had that right. That really is that they had an excellent MDM system behind it. And of course, that's the first thing I thought because I'm a data person, not, oh, great, I have my flight booked. I'm like, good master data airline. But that really is that nice customer service. I'm working with another nonprofit. And what they're trying, you know, they work with a lot of constituents that are either getting mental health services or education services, and they're all at different sites. And what they don't want to have is, you know, you've been giving this person counseling for six years and they go to a different site and like, what's your name? That's just not good customer service, right? So trying to get that single point of entry that you know the right thing about the person. Again, you don't want to be creepy and think of privacy concerns and GDPR and all that, of course. But if you can technologically integrate that, that really is sort of the nirvana we're heading towards. And so, but that is, I think I previously said that, you know, MDM is not reporting. And I think the beauty of MDM is that it is interact. It's a published and subscribed model that you can both push and pull the data across all the systems. So it isn't a point to point integration. It's all from that same hub. That said, a great usage, especially the first step of MDM is for better reporting. And so if we want to just think of traditional data warehousing, and you have your sort of facts and dimensions, and you have your conformed dimension, which is your customer table and your mastering customer, what a great way to feed that dimension to make sure you're reporting off an accurate list of customers. So that is, you know, in many instances that really is another nirvana of can I even get, I don't necessarily need it real time in the applications. I just want that clean list. I mean, it isn't either or some companies I work with are sort of doing data warehousing first instead of a test to kind of look at the quality of the data and all that. But you can use MDM just for better reporting because again, it's that sort of the unsung hero of getting the data right before you use it for anything. So I think one of the reasons why MDM again, is so popular because it's the precursor to any other stuff you want to do. You need a clean list of products and customers and locations to do a warehouse of tell me product sales by customer by location, right? It should be obvious, but as we know, it's not so easy to get that and that's where MDM comes in. As well as reference data, I say it's kind of a little red cousin down here of, you know, your product codes might, I mean your location codes might be your reference data. So I kind of put them together, probably less governed in not as many processes around your reference data as with your master, but it is also important. I don't want to forget that. So just to continue my rant on that MDM is not reporting. I think, again, I consult for living. A high percentage of my customers are actually doing MDM right now. And I think the biggest misconception that we often, not necessarily with the technical team, but particularly with business users, is really separating the fact that MDM isn't just your reports and it's not the same as reporting, but certainly it can feed it. So I already mentioned that idea of your golden records and just continuing with customer can feed your warehouse. I want customers by region by, you know, product that can definitely feed that. But just think of else and we think of 360 view of customer. And I think that's where we'll, well, once you build MDM, you have that, right? No, no, no, no, no. And that's where it can be offset. We just know that there's one John Smith. And seriously, you took your six months to know there's one John Smith and you roll your eyes and say, believe me, you should have seen how complicated it was. So, and that can sometimes be anticlimactic because you're just getting the data right. But then if you do want to say graph, if you've heard my previous webinars, you know, I'm a fan of graph, right? And I want to see relationships of social network analysis. This, you know, think of your Amazon.com bought this. Do you like this? Because other customers bought that. Well, that's graph, right? And you can do a lot with graph family patterns and purchasing patterns and set up, sell, cross sell, a lot of that. So a great way, once you have the golden record to feed into this, or your data lake, right? You might think as MDM sort of the opposite of a data lake, it could be. But if you have a single view of customer and you have some of your data scientists trying to do social media sentiment analysis or weather pattern analysis by customer, I mean, you still need a good list of customer. I think I don't want to speak for the data scientists on the call. But if I had a clean list of customers, yes, I will use it. I mean, why not? So it doesn't mean that just because you're also also linking unstructured data, I mean, unstructured data or real time streaming data, one of my customers did a master data management. And they were doing kind of real time biometric data for it wasn't Fitbit, but you know, that type of product, sort of a Fitbit product of heart rate and things like that. Well, that was on a data lake, but you had to link it to my heart rate, not your heart rate, right? So you still need master data. I mean, all of this, you still need master data. So one of my other clients was doing sort of web scraping on their high net worth individuals and whether they own companies and whether they have been sued and you know, a lot of really advanced web scraping across a lot of different sources. And they did awesome analytics, but it came down to when they tried to match that with their customer list, their customer list wasn't robust enough. And they had to start an MDM project around their customer. So again, rant over for this moment, but MDM is not reporting is not analytics is not graph, it's not social media segment analysis, but it certainly helps that they sort of, you know, you can't do one well without the others. So the other sort of piece of that of governance as I mentioned before is governance in business process. And I like this quote reference from Gartner. They did a report a while back and they said some of the top reasons for failure of a data warehouse were failure to align with business process and not having the right governance. So again, that has nothing to do with the technology and whether it's a hub and spoke or a federated model or what your matching rules and your algorithms are super important. That's often not why master data fails. It's often that hate user term soft skills, right? But those are critically important with MDM. And I'll go into a little more detail around that. So how I see it, successful MDM is this kind of sweet spot, you know, integration between data architecture, which we've just talked a lot about data governance and stewardship, which we've sort of hit on and then business process alignment, which we have not talked so much about in this call, but we'll talk more now. And I think something to step back and think of when you do your particular integration and every integration with master data is different. It's not that just that you store different product attributes or customer attributes or supplier attributes, it's just that your company is different. Each company has a different percentage of what's important. So in some cases, and I'll give one case study on that, it's business process alignment. How is your master data entered or changed across your business process alignment, especially a couple of engineering companies I'm working with, their master data was really more of a business process engineering and it was integrating the touch points of data. I mean, they're a very process oriented company. So we added that into process. Some companies are much more about the stewardship and ownership of it and the people side of it. I mean, one of my companies, I did not use a tool at all. It was a 100% manual process around master data. They were doing at least this part of the organization was doing mastering legal entities and they had to call that has up and they want to speak to the person. They had to make sure that they hadn't gone bankrupt. There's a lot of human in the loop intervention and there was so much human in the loop intervention, a tool wouldn't have helped them. It really was a person to person thing. So don't force a tool where you need it. In other cases, it very much is a much a technical problem. I have millions of customers and I don't want a person looking through every J Smith versus John Smith. I want to interpret it another way. Generally, it's sort of some sort of semi equal balance between these three. So as we move on, business process is a huge part and I think often partly because business process and data people often live in a different part of the organization, which they should not. It's often the one that's maybe forgotten if one is forgotten of how does the data get entered. So can we create a big fan, if you've heard my presentation before, taking a lot of the industry standard templates with things like enterprise architecture. This is a BPMN-ish model and then I customize it to make it work. So yes, I've been on the BPMN process notation board. I get it, but if there's a little picture of a person or a piece of paper that shows that it's a manual process, put it in. It's all about communication. And I've found that often this is where you get some huge aha moments. So let's think, how does data get in? How does master data get into the system? I had one implementation. We were almost ready to get all the processes mapped from all the different sources. We did, we'll talk later, about CRUD matrices of all the systems and almost before we went. They said, you know, that's nice. We don't really enter it into that system though. We have this piece of paper everyone. You know, our jaws dropped. Well, you didn't ask me about paper when we did the system mapping. It's not a system, but yeah, that's actually what we use. So put the pieces of paper in. If really, when you think of when you go to the doctor, I know in the U.S., often we still get a little flip chart with a piece of paper you're filling with pen and paper. That's where you're getting the master data about patients, right? About me. So put that in. And we really understand where all your touch points of data, again, often where MDM fails is either you forgot a system or you didn't talk to the people and get the right attributes of how they're using that data. Often there's conflicts. Again, no, I'm the master data, right? So, you know, well, let's talk that through. Maybe you're master in classic one and I still get some pushback of, well, you have to have one owner for customer or one owner. Well, think of patient. A perfect example. I want the person that I'm checking in to the doctor's office to maybe know my insurance records and things like that, my name, but I hope my doctor is the steward for my heart rate and my diagnosis. I don't want the lady in the front desk being the owner of that, right? So, nobody owns any of these systems. So you really have to give that some thought. Crud matrix, best tool ever with the worst name. I did have one of my customers. We started to call it the drug matrix. So it wasn't, I'm not that much better, but at least it doesn't mean crud. But this, as we get more detail, you've identified your system. Let's give that some thought of where is this data created? And then a lot of thought, where is it updated? So, yeah, well, I had my right name when I went to the doctor's office and then I went somewhere else and I was busy. So I just put D Burbank and I did. I thought they'd figure that out later, but maybe you didn't and you overwrote my Donna with D later. Give that a lot of thought. If there's two creates or there's more than one update, how do you get that golden record? If you could pick a golden record that you know is always right, please do. Otherwise, you might have to get into that fuzzy matching and things like that, which are fun to do. But if they're not needed, you don't always want to have to do them. So again, this is one of those old school, these have been around for what, 20, 30 years, right? But they still work, right? So even if you're doing AI, a good old crud matrix could still help you get the data right. And so this, I know it's a busy dense slide, kind of known for that, sorry. I mean, you try to be in my brain. But I think if you have time, you want to print out these slides that will be available after the session. It's kind of a good reference because the other thing that makes MDM super valuable, but also rather complicated, is that it involves a lot of different people in the business. So at the first level is really that enterprise business side, right? So first of all, what are we even prioritizing? What do we master? Give that a lot of thoughts, especially master it can be hard. Make sure you have that right case that everyone understands the value and you pick the right domain. Something that can help with that is a conceptual data model. I'm a fan. We have products, we have customers, we have invoices. What's the right thing to master? Then map that to either the data process, which I mentioned sort of back here. You could do a process model. Another thing I'm seeing more and more of, and you may roll your eyes at me, but is this idea of a customer journey map? Which I see is just sort of a modern hipster version of the process model, right? What is the journey of my customer? What is the journey of my member? And let's draw it out. Whatever you call it, however you do it, if you do it in a workshop or you do it in an EA diagramming session, whatever it is, build one, because you often get a lot of insight into how does the customer, first thing I do when I come to a company, how do your customer day to get in? Go to the website, try to become a member. What fields are entered? Do you even know? And it's not just customer journey. We talk that a lot. I had one company, the logistics journey. What is the journey of the product that goes through our system and how does it touch point? And these are all business-level things. You don't even need IT in the room. Helpful to have IT, but these are business decisions. What are my different subject areas, domains? How do I prioritize by geography? Do I start in one country? Do I just start in the US and then do Europe? Or do I want to do it globally? I would say design globally, implement locally. So I should have a model that I don't want to just start in Ireland and do a model for Ireland. And I try to get Switzerland in and they have different attributes and oops, I found out too late. So yes, model it holistically, but you might want to roll out by region. And then sort of where sort of tech and business start to get together is this idea of things like logical data models. Okay, what attributes do we need? How do they format it? What are the business rules around these? What are the detailed business processes? How do we get the data stewards right? So on the right here is the different roles that might be involved. Then it's not just one. It could be the process steward, the data steward, the regional, how we do business process. So that's how you enter customers in Latin America, but that's not how we do it in Asia. So yeah, not one per business process fits all. And then we get down to the technical level, which is super important, but probably just as the tech team of how do we profile the data? See, if we're going to match on email address, do we have email addresses? I know that seems obvious, but you know, when we're down the weeds, we sometimes forget to even check that and almost all these examples I'm giving because we've done. I'm old. What are the data quality? Can we augment? Maybe we don't have good addresses. Can we buy them and match them? Postal service of your country probably has some of that. Then how do we integrate the data? Is there an API to the systems? Are they going to play nice to the even import data? Is it going to be batch? How are things upgraded? And then even just the platform, are we going to buy a tool? I recommend it if you're going to do a lot of this complex stuff. What tool do we buy? Does it meet our needs? Who's going to administer that tool? Is it the DBA? Who has rights for all that? So again, getting all these rights can be the sweet spot. Just one example before I let you go and open up the questions. I thought this was a good example because this was one where it didn't start. And I often find this of if we go back to that previous example I had showed in the beginning of the session that I like to show a lot, but it fits. The company will bring me in and say, we need to do governance. Well, really, yes, governance is super important. I'm a fan, but you need master data to govern and you don't have master data. Or people could say, really, I need someone to fix our warehouse or fix our reports. Our customer reports are terrible. That reporting team just is not good. And we look through, well, it's not the reports, it's the quality. And the quality is bad because you don't have mastered it. So they're all related, which is why we look at them holistically. And this particular customer was a good example of that because they did ask us to come in and do some data warehousing and some governance. And they were restaurant chain and they knew that there were just some problems in the field. We did a lot of interviews. We actually went to the kitchens and we talked to the chefs. And the chef, he didn't quite have a hat like that, but he looked like a chef. And he was in the kitchen and he had his, basically, it was a data flow diagram of all the ingredients he has and how he stores them. And he can't, he's putting them on note cards. And then where does that data flow to? So he had only data diagrams but data flow. We went to marketing. They were awesome people and they actually had it on a board and they just brought everyone in who would listen. It was basically the data flow of how you have the data for their recipe items. And it goes to the printer. Like they said, our printer knows more about our product than we do. And they had to get another data flow diagram. And so often a misconception is, though the business doesn't get data, I bet you they do. They're using data every day. And they understood very clearly some of those products. So as we went through, we realized the problem was they didn't have master data about their recipes or their menu items. We talked to the supply chain. Well, part of it is, are we costing those menu items right? Because we, you know, how much is the cost of a dozen eggs in Canada versus the U.S. Now then they actually had a business process issue back to the point of sale. And we went to the point of sale and, you know, you could order, they had specialty items and I think they had a blue cheese hamburger. And you could add, you know, you can add whatever. And they could add blue cheese to a regular hamburger and not pay more. And that was a dollar extra. And they lost a million dollars and there's just quarter because they didn't have the, from the chef's menu item to what was on the menu to how much it cost in supply chain to what was in the POS didn't match. I mean, that is just a core product master data issue. They didn't have the right master data on a slice of cheese, right? But it cost them a million dollars. So that was a way we sold up their CEO basically told that story. It was more of a business process than anything else. Yes, they had an MDM tool. Yes, we did the architecture, but really what we spent a lot of time doing was mapping out the business process. And then if you've heard my presentations, you know, I'm a big fan of how you sell this and how we literally showed pictures like this. And we had a picture and we sold up. I mean, this CEO was busy and she had other things to do and she was not wanting to talk about master data and reference. So we had a picture of a hamburger, had the picture of the cheese, and we showed all of the reasons why and the complexity of getting that right. She got it in a minute because we're talking her language and, you know, they funded the MDM tool as well as governance and everything around it because we told that story. And then we lived the story. I literally went to the kitchen and talked to the chef. So you can do that yourself. And I highly recommend it. And how they implemented MDM. Again, they had a tool, but they actually had a product launch committee. And this turned into the sort of their data governance committee is that before you launched any products, and I sat in on one of these, was fascinating. Someone could say you can't launch because, you know, you hadn't thought of the design of the restaurant that you want to add blue cheese to that. It takes someone three minutes to walk the rest of the kitchen to get the cheese and you need to deliver it to the table in this time. Nope, we can't launch. I mean, anything, things you don't even think of. No, the color of that menu clashes with Christmas themes that we're having at that time, whatever. Anyone could stop it. So we added data into that committee and people were actually able to say, we can't launch this product because the metadata isn't right. Which you might, again, wag your head and say, well, that's not true data governance. And I might say, well, it's even better because it actually was actionable. And you could have a metadata issue stop the launch of our product because the data wasn't right, which was pretty darn part of how powerful. So again, it was a master data project. And we did master data, but the bigger win was around processing governance and kind of fitting into the corporate culture. So I characteristically spoke fast, I know, and did a lot of dense slides. But in summary, MDM is hot. It's hot for a lot of great reasons. It's also super valuable, whether it's customer, product, supplier, employee. It's one we always forget. But you know, people are important if they work for you. And to get that right is that that suite makes an architecture process and governance. But do spend the right time on all of those to get it right because you will see the benefit. Just as Shannon opens it up for questions, you can type in the Q&A. If you are around in June and want to talk about enterprise architecture and architecture, we will be talking about that next month. So, Shannon, are there any good questions we want to kind of cover? Lots of good coming in. Yeah. And as Donna mentioned, if you have questions, feel free to submit them in the bottom right hand corner of your screen in the Q&A section. And just to answer the most commonly asked questions, just a reminder, I will send a follow up email for this webinar again, because we have a U.S. holiday on Monday. It will be by the end of the day Tuesday for this webinar with links to the slides and links to the recording and anything else requested throughout. So, diving in here, Donna, how realistic is it to consider our social security number as part of most companies' master data? Excellent question. So, there's so many nuances to that. So, one, I'll steal a quote from one of my customers the other day because that's highly sensitive information. And I think his quote was, sensitive information is like nuclear waste. If you don't have to store it, you don't want to. And so, I would first think, and this age of data breaches and security and privacy, do you really need to be storing social security number? I would just start with that. I would recommend not, if you don't have to. I would rather you didn't have my social security number. And for those not in the U.S., your social insurance or whatever, it's the government unique identifier, which you can get a lot from. You can get loans, you can get credit ratings from, et cetera. That said, there's also just, were there not that sensitivity, is that a good unique identifier? I think at one of Shannon's UW conferences, the Social Security Administration did actually speak. And they are the first to say that there is not a unique identifier. There's people with this, not many, but there are people with the same social security number. So, for that reason, it's not a great unique identifier. Not everybody has one who may be your customer. So, I would sort of recommend against it have some either a surrogate key, if you can, because you definitely don't want it to be your key. And probably, even if there were none of that other sensitivity, you want some other match, because the social security number, you don't have one, and it may not be unique. So, if you can do sort of name and address and other things, that might be better. Love it. So, should we design the data model for any master data before selecting tool and technology? Isn't it mandatory? Yes. Sorry, I guess we're excited. Not mandatory. You don't have to. I think, and I've done a few of these. And if you know me, of course we had a data model. I think it does several things. I would add to that do the data model of your source systems. It may, it'll help you. This is the data we want to populate. This is the data it's coming from. I would even add, before you look at the tools, your credit matrix and your system analysis, because it helps you vet the tools of how you're going to get the data in and out. You need an API integration that is batch enough. Some of the MDM vendors have automated integration with some of the bigger ones like Salesforce and things like that. So, that helps your negotiation. I think, and I hate to make generalizations, but I'll make one be very cautious when people say, oh, buy our tool because we already have patient master data or we already have customer and we've done it. And will they have not done it? They may have 80% of it, but your company is unique. So, you think they have a very educated conversation of these are the attributes. Maybe they have 80%. How do I customize these six attributes? You would get some of your hierarchy. I have a ragged hierarchy from my reporting structure. How do you implement that? Not whether any MDM tool worth its weight. It has some sort of modeling, but it's the how and the subtleties of what it integrates with. So, you'll just have a much better conversation. I would also say, do your stewards, all that design, do first. Who are your stewards and how do they want to interact with the system? All of that. The more you know, the better negotiating you're going to have and the better tool you're going to pick. Love it. And there is a fantastic question here asking if you can go to the second to the last slide with your contact information again. And of course, I will include that with the follow-up email as well. Love that. Awesome. That is the company. And then if you care my actual emails here, pretty risky. I'm actually giving my email on a public thing. But go ahead. But don't try to tell me something. Sure. What else? Do you agree that business processes need to be solidified and defined prior to implementing MDM? Addressing data quality should begin with looking at business processes that generate it. I think we should get the prize of who in this call can answer me for me, given what you've heard. Probably yes. Yes. Give them my last answer. I think it's super. I would say before any tool map out all the things. Again, people get nervous by saying you have to do fully detailed process model before I even look at no, no, no, no. I mean, so much of this you can get in a whiteboard in the afternoon and they get the details later as you need it. But yes, what are the business processes? And just devil's advocate, do you even need a tool or is the tool going to help you fix or do you, you know, I have one client I'm working with. They're two years in. They know they needed metadata day one. They're saving their money wisely because the first thing they're doing, they have everything mapped out. They're cleaning up the data quality. They're getting the stewardship in place. They're doing everything else. And then when they buy that tool, they're going to run because they did all that prep work. And so it doesn't mean you're not going to get there. You want to just get there and don't buy the tool first and then figure out everything else. Like, that's probably the icing on your cake because the hard stuff is not the tool. The hard stuff is what you put in the tool. Yeah, I would say. And then you're not paying for licensing costs as you're getting all that together, right? Indeed. So there's a myth that silos can get around MDM since it happened for a few years. Is MDM not really that important? There's a myth that silos can get around MDM. Is that without the question? Correct. Oh, of course, they could get around it, which is why you want to start with that business process and the governance and the architecture modeling. So it could be several reasons. It's a silo because we forgot to talk to them. And we didn't know they had a system where they're doing it on paper. We didn't talk. It could be a silo because we didn't have the right people involved or we didn't look at the business process. That could be it. Or to put on my nefarious hat, it could be a silo because people really want to build a silo and they don't want to play nicely. And maybe that's why you need governance first. Is that, yes, you're going to be held accountable. And if really we've just spent X thousands dollars on MDM system and you think you're going to be clever and buy it off, buy or build your own, you're not helping yourself. And hopefully people will realize that as we go through the process. But be there's some ramifications of governance helps with it because it helps enforce. This is the customer master. I don't know why someone wouldn't want to use a nice clean list. So that's a better way to do it. People see the value. And yes, please. And usually we get that. But governance can help be the stick if you don't have the carrot. Why do you think MDM has three surface to such a hot topic again? I think partly, and I touched on this briefly in the beginning, I think because data is a hot topic. And again, people don't necessarily start with, oh, I'd love a like clean, you know, duplicated list of clean data attributes. I'd be very few business people that would start with that nerdy type of a question. But as soon as they want to do anything with customer data or product data or patient data, they see the need for it. So I think because people are now, I have several clients that actually wanted to do artificial intelligence, machine learning and advanced analytics. And the first thing they had to do them DM, because you can't do advanced analytics on bad, you know, on customer sentiment, if you don't know your customers. So I think that's why it's because, A, there's just more interest. And I will give them maybe it's partly the diversity or whatever main people listening to, you know, what they've learned is that I think the level of maturity, I talked to a lot of business people even see level. And I think the level of knowledge around data is higher than when I first started in business. I think people get it a bit more of the SSC and the need. So I would give it to that as well, people are maturing a bit in the industry. All right, lots of comments going on in the chat section. If you have any additional questions, feel free to submit them in the bottom right hand corner of your screen. But Donna, another fantastic presentation. Thank you as always. I'm excited to have the June webinar as well. If you want to throw that back up there, we can take a look at that. And again, if you want to continue the conversation and continue the chat after the webinar, you can go to community.dativersity.net. You can also learn a lot more about Donna there as well and connect with each other. Donna, again, thank you so much for this great presentation. Really appreciate it. Thanks to the attendees for being so engaged in everything we do. Just love it. Hope to see you all next month and hope everybody has a great day. Donna, thank you so much. Thank you. Thanks. Enjoy the rest of your day. Bye.