 Hello and welcome. My name is Shannon Kemp, and I'm the Chief Digital Officer for Data Diversity. We would like to thank you for joining the latest in the monthly Data Diversity webinar series, Architecture Strategies with Donna Burbank. Today, Donna will discuss master data management, aligning data processing governance sponsored today by Informatica and Simarkey. Just a couple points to get us started. Due to the large number of people that attend these sessions, you will be muted during the webinar. For questions, we will be collecting them by the Q&A panel. And if you'd like to chat with us or with each other, certainly encourage you to do so. And just to note, the chat defaults to send just the panelists, but you may have to change that to network with everyone. To open the chat or the Q&A panels, you can find those icons in the bottom of your screen to enable those features. And as always, we will send a follow-up email within the next two days, containing links to the slides and recording of the session and any additional information requested throughout the webinar. Now let me turn it over to Koi for a brief word from our first sponsor, Informatica. Koi. Hello and welcome. Oh, it is still muted, Koi. Holy cow. Sorry, I was, took forever to get off mute. Hi, everyone. Oh, no, Grace. You're on. You're live. You're good to go. All right. All right. So let me share my technical quick. Sorry about this. Perfect. Okay. Hey, everyone. Koi Wang here from Informatica. I run our community practice and our technical to market. More interestingly, I was one of the founders of Informatica's MDM back in 2000. And since then, we've been doing a lot of work and developing on our new MDM SaaS offering. And one of the key things from our SaaS offering really is we focused on using all the experience that we had on our on-prem offering to really create a new capability, a new set of products altogether. And so these are the key tenants that we really focused on when we were looking at SaaS. How do we make it simple? How do we make it quicker to implement? How do we drive through AI? What do we use for AI? And then certainly make it scalable for everybody to be able to leverage. I mean, we have huge companies that are using our MDM. And then the last one is how do we really look at it from an all-in-one capability, right? So if we take a look at really quickly here, what we mean by simple, being able to then configure the software in a much easier way. So changing the configuration experience so that you don't have to manage data individually or sorry, you don't have to configure separate products. You have the ability to leverage AI to be able to do much of the configuration. Making it quick, what do we mean by quick? We basically have the ability to go live very quickly. And so if you take a look at some of our current customers, we're talking about implementation times and in production in a matter of weeks. So, for example, Great Cliffs and Burton's, 14 weeks to go live. This is not just configuration, this is actual testing. This is actually in production. We have basically GE Digital and Uber going live in 16 weeks. They're actually getting usage and business to use the technology within that amount of time. And this is all really enabled through the AI-powered set of capabilities. What I mean by that is if you look at across the board, we have the ability to use AI around a matching. Using the AI to be able to do the mappings from source to target very quickly. We're able to identify which sources, potential sources that could feed into MDM and then certainly being able to integrate and push data downstream much, much quicker. And then finally, if you're talking about scalability, if you're talking about scalability, we basically have, we're looking at huge customers and for example, we have one of our customers, a big hotel chain that has 300 million records spanning across customer mastering, supplier mastering, reference mastering, location and really property to be able to provide the mastering capabilities across the organization. And then finally, this is all enabled through an all in one capability. So what I mean by that is across, if anybody's implemented MDM before, it's the ability to look across the board. So first part of mastering and solutioning is being able to connect to different systems and being able to improve the quality of the data through data quality, being able to master it through matching and management of hierarchies and then certainly then pushing it downward. So all these are now provided within our single platform. So overall, I mean, that's really what we're talking about for Informatica. So completely new capability and we're looking forward to talking to you. Thank you. Chloe, thank you so much. And if you have questions about Informatica, you may submit your questions in the Q&A section as he'll be joining us in the end of the webinar. And then let me turn it over to Steven for a brief word from our second sponsor, Marky. Steven, hello and welcome. Hey, Shannon, can you hear me? I can, you sound good. Looks good. Perfect. All right. Hey, everyone, I'm Steven. I'm the product marketing manager here at Smarky. Today, I want to tell you a little bit about our data platform and some of the insights that we've seen over the past couple of years with implementations and successes that we've done with MDM. So we actually ran a survey earlier this year with EMA Research from Real World MDM implementations about 100 different decision makers across all industries, sizes and vendors. And these are sort of the three interesting metrics and facts that we found. So and this might resonate and be relevant in sort of your journey, whether you are starting out your individual process or trying your first or second one. So we found that about over half of the companies have more than one MDM solution. So even with the notion of MDM being a single source of truth for organizations, the average is about two and a half MDM solutions per company. The main, you know, there's obviously a lot of challenges that they've had to overcome and identify, but the number one way that a lot of these companies figured to overcome these is actually vendor support and success that they're able to deliver. And, you know, the light and the rate of tunnel is that 94% of the companies who implemented MDM have reported some more significant improvements in most other metrics. So what does that actually mean? Right. So one of our key differentiators that we want to focus on is our successful outcomes, right? MDM is probably going to be one of the most important implementations that you'll have from a data and overall technological perspective and making sure it's actually successful, not just shelfware that you purchase is actually critical. And that's really what we found. So our focus is really on ensuring that, you know, the data that your data initiatives, especially with MDM, is actually successful. And you can see by some of the peer ratings that we have. And then we've really honed in on accelerating that value, the time to value to deploy your MDM's implementation and actually getting usage out of it. So usually we're able to see a fully functioning MDM solution about 12 weeks. And that really is central for our customer success organization, right? So we have dedicated customer success team that helps you meet your implementation goals. And not just your first one, right? But your next one and what other needs that you need to grow and use. And then clients really trust us to basically be their long term partner, right? So we have, you know, over probably a trillion different records, golden records that try and trust us to manage for, you know, the most important data in the long run. And we've recently started developing this acceleration kits that really help you from your end to end journey, right? Whether you're assessing this, is there a business case for this? How do I tell my boss and decision makers that this is actually, you know, something that we actually need to do and other sort of different kits to help you accelerate the time to value for deploying MDM? In terms of what we actually get, right? So we go to market rise data platform and we have three different modules. So the main one is our data management and then included within it is data intelligence and data integration. So you could start wherever you need to because every organization has different needs and starting points. But once you have mastered capabilities, you can expand and we'll debate the data platform or support wherever you need to grow and scale to. And then, yeah, hopefully we would love to see you and come talk to us so we can help you deliver the successful business outcomes for MDM that your company needs. All right, back to you, Shannon. Steven, thank you so much. And if you have questions for Steven about summer key, submit your questions to the Q&A. He'll also be joining us in the Q&A portion of the webinar at the end. Now let me introduce to you the speaker of the monthly series, Donna Burbank. Donna is a recognized industry and information management with over 20 years of experience helping organizations enrich business opportunities through data and information. She currently is the managing director of Data Strategy Limited, where she assists organizations around the globe in driving value on their data. And I'm so excited I just have to see Donna in person and in the price of the world. And with that, let me give the floor to Donna to get her presentation started. Oh, and welcome. Thank you so much, Shannon. Yes, it was good to see you. We're in good confidence in Orlando this week. And yeah, thanks for everyone who joined online. If this is your first time with us at Data Diversity or with this data architecture series, it is a series. And we have one every month. So one of the nice things about Data Diversity is they keep everything recorded for playback, I think, in perpetuity. And we've done this for several years now. So if any of the topics we did in January, February or are of interest to you, those are available for playback. Hopefully you'll join us for one of the other series throughout this year. And the question we always get is, is this available for playback? And yes, Shannon and her team send those out early next week. So you can catch this again if you missed anything or share it with a colleague. So hopefully you can see us again in one of these other webinars. And thanks for all some of the familiar faces or names I do see in the attendees. And I was able to see some folks in person this week in Orlando, which is nice. Nice when folks come up and say, hey, I've seen you online. It's nice to see you in person. So I appreciate that. So we are here to talk about master data management. We'll talk more about what that is. You may be new to this, which is a great part of this webinar. It really is one of the things in data management that is very intuitive to understand because it's the type of data that absolutely is at the core of the organization. That's what makes it master. In fact, some of our clients actually start to call it now core data because it is so core customers, products, vendors, students, patients. We'll get more into that. It can be complex. Now, I think both of the vendors that mentioned, it can be complex. It doesn't, the kind of the time to market doesn't have to be years and years and years. It should be ongoing for years and years and years because it should be driving your business, but you can get some value up front fairly quickly with some best practices that we'll talk through. And it can be very practical. So I think that's what I will be trying to cover in this webinar is that it can be overwhelming. It, you know, it could be surprisingly complicated too. You know, when I was early in my career, I said some of the naive things like how hard can it be to get a single view of customer. It's your customer. Well, anyone who's been doing that for a while, there's the complexities of human beings and how you can get that golden record. So we'll talk about both. It's not shouldn't you take your years, but it isn't nothing either. And so how you can break that down just a very practical steps to move along in the journey is what we'll try to get today in this webinar. So if you've joined these webinars before, you've seen the the framework that we show this is I work with a company called Global Data Strategy. And funny enough, we do data strategies globally and master data is a big part of a data strategy. And we'll talk about some of these today. Why we always show this framework is because everything is interconnected and without trying to add too much extra complexity, you know, I can do master data management, but I can't do master data management without understanding the strategy of the business. You know, what do we even mean by a customer? Are they retail customers? Are they companies? Are they, you know, there's so many different nuances and why are we mastering? Customers fairly obvious, but it was a prioritization of the different domains we're looking for. Do we have the right data governance and collaboration? We'll talk a lot about that in this session. You know, tools are tools are great and they're fine, but they're only a piece of the puzzle, right? Some MDM, you know, a lot of the issue is in the business process of the people actually defining the definitions or typing the data into the systems or using them every day as they're doing their day job. So aligning that with your master data as well as data quality, data architecture, how do you architecture, architecture master data, bottom up as well, you know, what sources are currently either feeding or consuming or touching your master data, right? It seems, you know, a misconception. And I actually did a master data workshop at EDW early this week. And it was, you know, we had a day to do half a day to do it. So we had a lot more discussion, but that is one of the misconceptions that, yes, we want a single version of the truth. It doesn't mean that we're forcing everybody to change what they're doing and put everything in one big database that they type their customers into, not at all, right? So, but how do you integrate master data to get that golden record in the different data sources that people are using as part of their day job and then have the metadata around it and the integration and the security and the privacy and all of that, right? So master data management more than any of these absolutely does not live in a vacuum and it probably touches every piece of this framework because it is so core to the business, right? So we'll cut some of these today. So what is master data? I am a full disclosure, very proud data management, data architecture professional, and we love ourselves some good definitions. So I know this is a data diversity and data type webinar, and there's the Damon DM vlog, but I'm often a fan of Gartner's kind of online dictionary, and they've got some good definitions. And I like the ones they use for master data and then master data management. In fact, they are using that phrase. It's the consistent and uniform identifiers of this core entities, right? Customers, prospects, citizens, etc. You can read that that's a great way to really sum that up. It's the core set of identifiers and attributes that describe the business, really, and then master data. It could be self master data management. It could be self defining. It's the management of master data, but I like their definition as well. Is technology enabled, right? Eventually you need some sort of tool and technology, but it's really, I think, often the harder part is that business and IT working together, that could be a challenge to ensure that uniformity, accuracy and stewardship, the semantic consistency, that's metadata, that's glossary, that's data models and all of that, right? To really get that accountability around the official set of master data assets. And I like both of those together because it provides a solid business driven definition, but it also touches on a lot of the complexity that makes master data complicated. Right? If it were just one big single table of things that IT could type in, that wouldn't make it complicated. But because it touches the business everywhere, that's what makes it complicated. And that's why it's so multifaceted. So what is master data? This is actually a photo from an early cave dwelling. I think it was in France. I'm obviously kidding. But this is from one of my data modeling books, but it gets to the point of when you do look at a cave dwelling, one of the types of things they wrote on the walls, they had their animals, which is maybe their product, right? The things they consume, they had the people, those are their employees. They had pictures of the buildings they lived in and things. So right, those are the core. That was their business, hunting and gathering, right? And those were their employees and products really, right there. And so I fold this closure and we fold webinars this year on it. I'm a fan of data modeling. One is because it brings simplicity to complexity and it's visual. And I think a lot of us are very visual creatures, right? We draw on cave dwellings. Why did we do that? I don't know. We just do it as creatures. We love cartoons. We like to see things in a graphical way and we love simplicity. How do we take the complexity of a business and draw out those core domains or things that drive the business? And that's master, generally, that's master data. And we'll talk more about that. So what is master data? And I gave some examples that I'm going to give a lot of examples. I try to do that in all of my webinars because I hopefully the value that I bring is that we do this for living and I'm old and I've done a lot of these. So what I find fun about my job when I'm having a good day is just the diversity of types of things that are master data. We always talk about customer and product because those are sort of easy. But I thought it might be interesting to just give some examples of different things that are master data and maybe more importantly, some of the business impact, right? I often joke, I go across, we do a lot of strategy. We come in and we ask some of the issues and opportunities and pain points. And generally, there's that one anecdotal story that almost instills fear across the organ. You just know you hit a nerve just by asking it. And we worked in one company. It was a restaurant chain. We were talking and I noticed whenever they brought up cheese, people would be like, oh, my gosh, not that we're not going to talk about the cheese, not the cheese incident was sort of comical from the outside. I thought I was in some sort of odd movies. What's the cheese incident and how can, you know, like a bad horror movie, the cheese, you get a picture of the music coming in. I'm like, what on earth is up with this cheese slice? So I, you know, this was a restaurant and they like to customize their menu a lot when that was one of their benefits. But we'll actually bring this back at the end to kind of wrap up the webinars, the full story. They, you know, when you think of supply chain or the kitchen that kind of came up with this innovative cheese slice, I think this was Swiss cheese, right? In this picture, you know, normally you had the regular old American cheese slice and that costs 50 cents, but they, you know, and then if you wanted to buy it on your point of sale, it was a dollar, but this particular cheese slice cost a lot more of that. It was very popular because it was really cool to have Swiss cheese on your on your sandwich or hamburger, right? But every time someone upgraded to this cheese slice, they were actually costing the company money, so they actually over the year lost a million dollars before they cost it instead of the campaign was successful. They ended up losing money on it. And when you think of what is master data, not only was master data their menu items, but it's the really those core ingredients for them because it was a very customizable menu, cheese and, you know, hamburgers. And that really was their master data, right? On a similar, not to break up all the negatives, but one that caused some pain points, we worked with a baby bottle manufacturer and they're kind of a listed in fear was the two million dollar baby bottle. And what was up with this, they had very, very popular product. Well loved around the globe, brand recognition, but and they were trying to do a whole lot more online sales. They were selling through Amazon, but their master data was so manual and so inconsistent. If you've worked with Amazon, they have a particular format you must use their master data is pretty, pretty strong actually, but this company kept sending a master data in the wrong format and kept getting fines. And before it was still worth it to sell off Amazon, but they had over two million dollars in fines just for having poorly formatted master data. So that was, you know, these are very concrete things, right? Probably my favorite one and maybe the most odd in terms of, you know, when we're talking about master data management webinar, we usually don't list dead fish as a master data domain. But we did do a project with the UK Environment Agency. In fact, they spoke with us at diversity on our one of these series a couple of years ago. It's still recorded if you wish to catch it. But what they do for a living is track. Well, well, they do several things, but they track things in the environment, which a lot of them are living organisms, which could be cows. Yes, that's a job to go around and count cows across the countryside. Some of it was amoeba, you know, things in the water. Some of it was fish and then we sort of had, you know, this the quote business users were scientists who are basically saying, when we consolidate specimens and what we capture and is basically an organism and organism, we had a bit of a joke. I felt like so do I was in a Monty Python skit of, you know, it's a living organism. What if we have a dead living organism? And we decided that, you know, a dead fish was a living organism with a status of dead, in case you care. But that's probably unique, but they actually used it for open data sets for people who are doing their own scientific research, you know, citizen scientists, it helped people getting their fishing license online. So it was very practical, but it seemed rather theoretical in terms of, you know, something as philosophical as what is a living organism. But they were able to consolidate a lot of their research together by stepping back, and that was their master data, right? The one on the left, we worked with a hospital, you know, which doctor is credentialed to do heart surgery? Kind of important. I hope they get that one right. If it's my heart we're working on, probably similar with patient. I hope it's the right Donna Burbank and they don't amputate my leg instead of do heart surgery because I didn't know who I was, right? So super beneficial or even what is a credential, right? And what credentials linked to what locations of which hospitals? And, you know, the one of the funny stories here, we did crack that down and only certain credentialed people could go into certain locations and the president of the hospital tried to get into the heart surgery wing and wasn't allowed because he wasn't credentialed. And that didn't go over. Well, we changed the business rule there. But again, these were the core business rules driving the operation of a hospital. The one in the middle, we did work with a insurance company that insured people like you and me, high net worth customers that, you know, had your ski chalet and Aspen in your apartment in Paris and had some Renoir paintings that you wanted to insure. And they actually were doing some really exciting kind of advanced analytics and AI and looking across the all of the data sets across the internet to really understand all of the what kind of businesses did their high net worth individuals own and some really important things that are going to tie into how they might insure the assets of this customer. But when they brought it in house, their own master data wasn't good. They didn't know when we said Michael Jones, but they weren't names like Michael Jones, their names we all know and probably can't say on a webinar, but, you know, was Michael Jones the ultra high net worth movie star customer or was Michael Jones the thing of the courier who's, you know, delivering your documents on his bike. And it isn't quite yet a net worth customer. Pretty important when you're trying to insure that customer and I'm sure the high net worth Michael Jones is not going to be happy if he's been misidentified, right? So that was a great example of all the great things we hear about and all the exciting things you can do with data AI and sharing learning advanced analytics, predictive analytics. But if you're not, I know this is almost trite to this audience, but if you don't have those core building blocks, which is your master data, you can't do all the cool things with it because you're going to make predictions off the wrong Michael Jones, right? The one on the right, I'll bring back kind of bring back the environment agency again, location is always one that somewhere, and I guess I'll bring in the hospital, right for the for the environment agency. Their whole business was creating maps in addition to the, you know, the organisms, they also created the different castments and reasons and published some of the maps in the UK for the environment. So for them, location or a catchment or a region was a first order master data. I would say when we think of location, the hospital, their hospitals, their different locations and campuses were first order master data, but sometimes, you know, markets or regions, they might be reference data and not to get too academic, but one person's master data might be someone else's reference data and we'll talk more about that a little bit later. Sometimes they're just kind of look up fields, right? So I could go on all day because as I said, I love this stuff, but it's been fun to me over my career and I will not go through each one of these. We will get a little bit meatier, but hopefully these help because sometimes it just seems so abstract. These are all things that in different clients that have worked with over the years have been master data. So we went through some of these already. One of my favorite ones was adult cow suits. Yes, that's product master. But we had a few laughs of is it adult suit, large female? Is it male, large, cow suit, blue? Anyway, but that's product master, but there were some interesting products. Classroom in the middle is a classroom, a virtual classroom. Is it a physical classroom? Is it the curricula in a classroom that makes it a classroom? Oh, I mean, sometimes you sound like you're being very philosophical with some of these conversations, but it was core to that educational institution of how they defined a classroom and it was core to what they did, which is education. So that was their core master data. The one right next to it, a well, if you've worked in oil and gas, a well or a location of a well or all the sites across the life cycle of a well. Super important. The upper right, that trademark we worked with an intellectual property office were intellectual property and patents. That was their master data, right? So that's pretty interesting and different. The one below it was components of car manufacturing and all the different components that might have been a component in another company, but it was first order master data for them or maybe the trucks themselves that are put together. Right. A lot of this up, you know, some of the I'll look at that apple spice one up next to the cow cow with the environment. You see that was there. I was there master day with living organism, but something like apple or apple spice that could be a first order ingredient in the company. We work with a flavor company where flavors were master data. We had a very, again, seemingly philosophical question, but it came out that chocolate doesn't have a flavor of chocolate. Chocolate is chocolate. Ice cream can have a flavor of chocolate, but ice cream, you know, but that was core to their business, right? If that were not core to the business, we wouldn't have had that conversation, but it absolutely drove when you're designing flavors for chocolate companies or for ice cream companies, something as philosophical as what is chocolate or what is cinnamon spice? Is it a flavor? Is it a brand? Et cetera, et cetera. So I find that super interesting and you should too, because these are all the different types of companies you can imagine. And they may not all be mastered at flavors. A great example, probably in ninety nine percent of the companies, it's an attribute of product, right? I might have a product with a flavor at this particular company. It was their master data, right? Flavors were what they sold. And so, you know, you never know, you have to understand business and it could be really sort of fun. OK, so we talk a lot about customer. So I'll bring in an example of customer and some of the benefits and risks and components of understanding master data management. So here's my favorite stuff on Kraus. He's 31 years old. He lives in Switzerland. He lives the life I wish I could right now. He lives in Pontorzina, Switzerland, which is near St. Maritz. He is a ski instructor at St. Maritz. Super athletic guy. He finished the Angusine, you know, to cross the ski marathon as a top finisher. He's like Mr. Outdoors, right? But if he's also kind of hip, he loves, he buys everything online. He loves to get a deal through a text message. But if you look at how much he actually purchased, it was about 500 euro and 20, but way back in 25th, 15, this is a little dated, right? So probably good for your cover of the magazine. Maybe not your your best customer. That's actually not a lot. He gets all his gear free because he's a ski instructor. They give him free, free gear, right? So then we have another step on Kraus that lives in Zurich, Switzerland, also named Step on Kraus. He's 62. He's a banker. And, you know, his sport is watching European football on television. He's kind of more old, traditional, old fast. And he wants if you're going to send me a mailer, I want it physical mail. I like to physically go to the store and I only travel once a year because I work a lot and I travel, but I'm going to buy the best gear on the planet for that one week and I'm going to spend $3,500 on my gear. So he's probably your better targeted customer, right? I want to make a distinction because I think and I'm not I'm not slamming any of the vendors on this call, but a lot of the vendors I think do or you're just the industry, the industry in general does, I think, mix these two. We always talk about the 360 view of customer with MDM. 360 view is the analytics. The MDM is the one degree view. Who's Stefan Kraus? I can't do the 360 view if I'm trying to understand, you know, purchasing patterns of some person who just bought 3,500 euro of gear in one day in the store. Is that father? Is that son? Are they two people that happen to have the same name in Switzerland and both buy outdoor gear? I don't know. That's really where MDM Master Data Management comes into play. What is a single view of customer and some of these key relationships? Is there a household thing? Is this a household? Is this a family relationship of father, son, unrelated people? How do we identify these two individuals and set them apart? So again, these these these webinars are supposed to be a little educational. So hopefully this helps this type of picture helped me when I was first learning all of this, the difference between transactional data and core master data and a little bit of reference data, which is I consider kind of the little cousin of master data, very similar, related and often done together. So if this were the store log of purchases from this outdoor store, I see that Stefan Kraus, I assume, bought a telemark ski boot for 250 euro, either in St. Rick's, Switzerland, or he lives in, you know, again, there's some metadata around here. He is that the day he purchased, is that his birthday, is that what we could assume maybe he bought this product on and again, I can go a whole webinar on metadata, is that January 1st or February 2nd or February 1st? What's the date, format, all of that? But we could just assume these are purchase records that Stefan Kraus bought a telemark ski boot, 250 euro, Donna Burbank bought the same telemark ski boot, $150 in Boulder, Colorado. You'll see there's a different product code. Is that right? Is that a mistake? There's different prices. Is that because Donna got a better deal or because we have different pricing in Europe and the US, et cetera, et cetera. Stefan Kraus now bought a North Face down jacket in Zurich. Well, is that which Stefan Kraus is that? Right? So the transactions are in how many products did we purchase by year? Kind of your data warehousing, the list of all the transactions. The master data is Stefan Kraus, Donna Burbank, Wendy, who Joe Smith, right? Are there two Stefan Krauses in this customer list or one? We don't know. We just know that a Stefan Kraus either bought a product in St. Meritz or bought a product in Zurich. It could have been Stefan Traveller. Well, we don't know. So how do you know all the attributes of customer product is another one? Do we know that this is the same telemark ski boot with a different product code? Is it a completely different product that they sell in Europe? What is the standard pricing and location that may be master data here? Are these the locations of the stores? Maybe we make that as an assumption or that the location of the customer based on their credit card information. But we could assume if this were the stores of our outdoor store, that could be our master data. But maybe you've got some reference data codes. Why is that important? I mean, reference data is kind of the unsung hero, right? A gosh, two letter character fields. How boring is that? But we can see right here, Boulder, Colorado is a two letter code. That's a state code, St. Meritz switch one. That's also a two character code that begins with a C, but that's a country code. So what are these other countries of the states? Right. So that type of thing is really helpful with the cousin of master data, which is your reference data. But hopefully that helps make sense of the difference between those. And it's hard to do a good if you're reporting on tell me all product sales by customer, you don't have a good list of customers and a good list of products, it's going to be difficult. So that is where these two fits together a little beyond this course. But if you are a data warehousing person and you've heard this idea of a conformed dimension, which is, can we get a consistent, conformed view of products and customers so we can report on products? You know, sold by customer, which products across the globe? If we want to have a simple report like that, you need good customer master, good product master and good location master. So hopefully that helps. Moving along in this example, I kind of mentioned this before, but that what is master data and what is reference data? Again, depending on the use case, you know, in this case, if this location of the store, that's truly master data, some of the reference data, you know, maybe the lookup fields, those would be reference data. But again, it could be, you know, some of the, I don't know, the departments or regions or something within the company. Maybe those are reference data, right? Something to think about in some of it is how, how core is this for the operation of the business? Does it change over time? Or again, I know it's simplistic, but if you think of it, it's just kind of a reference lookup list. And that's kind of the easiest way to see, is it reference data or master data? So I get this a lot and it's tempting. And I'm going to do a slight Donna rant here, right? So can't we just simplify these things? We do all this, you know, we have customers, employers and supplier contacts and patients and providers and similar, they're all just people, right? So can't we just save a lot of time and just have person as what we're mastering? We can master if I'm, I'm, I'm this outdoor company. I'm going to master employees and customers all in one and even my suppliers, right? I mean, they're all people. So I'm just going to create a people master or, or maybe my customers are B to B. I sell the companies and my suppliers are companies and my partners are companies and my subsidiaries are companies and gosh, Don and Bradstreet have a list of companies, so can't we just master company? And let's just call it legal entity or party and can't party just generally be the type of company we work with. Isn't that easier? And then to that, I facetiously say, well, then we can just create a thing and just have this one big table of stuff because all stuff has fields in it and we just put like thing one and thing two and field one and field two and just put all stuff in it, right? And I'm being slightly facetious, but I do think it's important because I see too much of this because when you start thinking of the business process and the governance, you'll see why this breaks down. So let's go through an example. What could possibly go wrong? Why can't we just have customer and employee master? It's the same effort, the same thing treated the same way. Well, what if this were kind of a pharmacy, right? And the pharmacist basically says to the person trying to get his prescription. Great, before you get your prescription, I'll just need your salary, your social security number and your higher date before I fill your prescription. He's like, what? That's a bizarre thing. Well, sure, as soon as I can see the list of medications you've been taking, right, and that's maybe a bizarre example. But you can see why would you know the start date in the social security, maybe the social, but definitely not the salary of someone getting a prescription and the vice versa. You shouldn't know your prescriptions necessarily that your employees are on. They're absolutely different use cases, right? And the journey, if we talk about the customer journey versus the employee journey, the security, one is hip or protected, one is not. If I'm just my higher date is not a hip or protected thing, right? So it isn't just the fields. You could always say, well, OK, Donna, but in that big person table, some have social security number, I mean, some have salary and some don't. You just hide the field, I guess, and maybe way down at the physical level. If some things are, you know, could be shared. But to me, that's not the hard part of master data management. It's truly understanding the governance, the usage and the business process around it. We will cover some of the data management aspects. But again, that's often not the really tricky part of master data management. So let's talk a little bit more about that. So master data management has at least but the three common ones are the kind of three legged stool of data architecture, data governance and your business processes. And you need to look at all of those to be successful. So, you know, a lot of what we heard from some of the tools in the beginning are absolutely important. We'll talk about that, your data architecture, your hierarchies within your customers and your vendors and your match merge survivorship rules, how you integrate. Absolutely critical. If that's not right, you're not going to be successful. And the accountability of who owns the salary, who can see the salary of an employee. When do we define the salary, who can change the salary? What are the business rules around salary and, you know, how do we, if there's a conflict on matching up two employees that are both named John Smith and born on the same day, who resolves that? Absolutely. If that's not right, you're not going to have success. Understanding the business process and the customer journey and how these businesses processes map to data are super, super important. I'll tell one quick story here that it isn't always this easy, but we work with the big aerospace company and we do a lot of workshops. And our, our org, it's a great way to kind of flesh out a lot of these details, hear different voices, because often again, it's not the data that's as hard as getting the people in process. And this seemed like a simple thing. It was payment terms for your vendors. The payment terms, the vendor have 30 days to pay or 90 days to pay. Kind of important when you're trying to predict your revenue come in for finance, that's hugely important. And it was always wrong. It kept getting changed and it was updated and they were having problems with their finance and it was a big deal. So we watched through the process of how suppliers were onboarded. And in that process, we saw that contracts folks in the beginning set the payment terms 30 days and then later when sales was negotiating the contract, they changed it to 90 days for whatever reason in that case. And I know that's an extreme. Those two parties saw that and the people downstream said, oh, I didn't know that was already set. I won't do that anymore. And it was set one place in the beginning from the contracts in the beginning and it solved the problem. Again, that wasn't a data management problem. That was a bit of a governance and a bit of a process. And that solved the problem. They didn't even need a tool for I'm a fan of MDM tools, but they didn't need a tool for that. That was people talking together and understanding what in your business process caused things to go wrong. Right. So that was kind of an extreme example to prove a point that was all done through people in process to fix the issue. So back to back to Gartner. That's the it's a bit dated now, but it still holds. This was something from one of their studies of that while the tech and the data is important. What often makes data and master data not go well or what what can help it go well if it goes right is understanding that complexity around business process and governance and the reasons often MDM does fail is not aligned with their business process or mismanaging governance and not really understanding who owns it, who sets these rules, you know, are there a lot of these rules are going to be different. It's not something I can set. You really need to understand the business and have the business set the rules for IT to implement in the tool in the right way. So why why do we say that? So because again, master data is your core data and the more core it is, the more it's going to be used across all of the different areas of if this is customers, vendors and materials across order to cash, source to pay, record to report, right? It's going to be used either been being produced by or consumed or both across all areas of the business, right? So the same data is going to be touched across the board. So customer, because it's so important, it's going to be touched all the way across the org. So one way to think of it is the who, the who, what and when of how this data is touched and managed across the board, process models are a really nice way to show this and manage this. This is kind of a slightly customized BPMN or business process modeling notation. But or just a workflow, you're probably familiar with this, that these horizontal areas are your swim lanes and these are the kind of the actors in the process. So in this case, this is actually a slightly anonymized version of the cheese incident, right? Product development or in this case, the kitchen development created the product and all the different pieces. And then it went to supply chain for costing and pricing and accounting. And then it went to marketing for market testing and then naming the product and moving on, they said a different market price, but that didn't align with supply chains price. Is that a different price? One's theoretical price and one's actual price. Is it the same price, but they coordinate better? You know, same thing with we had one customer code name. They had a code name and product development before it became the real name and it got out early and before it was properly to market. All these are master data management processes. And I'll talk about this in a minute. But your data stewards or your data owners are these folks, development, supply chain, accounting. They're the ones that know who sets price. Is it both people setting price? How do marketing supply chain work together to talk about price? That's a business decision, not necessarily an IT one, but you'll see the data that's kind of touched along the way. So one of my favorite tools with the worst name is a good old fast and crud matrix. Where is data created, read, updated and deleted? Absolutely critical when we're talking about master data, because again, it's master, it's core because of its cornice, is that a word? It's used by everyone, right? So a product skew, maybe it's created by development and read by these other folks. I hope that's automated for them, right? But product name, maybe development creates a name and then marketing updates it, has that been seen? You'd think that is so simple. Where we've worked in the past year and a half with three and a half to four, depending on how you define their problem. Major companies you've heard of in the market that have this problem, that they update the name, right? Because getting a name right in the market takes some time. You do some testing, but they may have made a test case and they go to market. Some of the materials still have the wrong name. Something as simple as the name of your product is critical and it still goes wrong. So how do I set the process for your master data? Make sure when I change the product name, that's synced. We all agree that it's synced across the board. Actually, all of these, I think it's been a whole effort for mastery of the weight of the product, the price of the product. It seems so simple, but because it's used across the board and these are so critical to product, absolutely critical to management. So that's why these business process models and these credit matrices fit really nicely together. So when I receive the order, what day, this kind of cartoony example, I think goes well, like in a workshop, I can say, OK, this is where it goes. And this is where I even sticky note it. You know, here's where I put the name and here's where I put the price. And again, that that aerospace company, that's how they solve the problem. They saw that their sticky notes weren't allowing and they solved it, right? But then to take it to the next level, something like this credit matrix gives it a little and you probably have dozens of attributes. This is a nice way to kind of make it really clear of, you know, when I receive the order, I'm creating the customer name and the order name and the account number and I'm just reading the product from something else, right? So you can kind of see where here, here are two groups are updating, you know, the same account number or three several groups, right? So you can kind of see those conflicts. It also ties really nicely into governance because these people in the swim lanes are your data stewards. These are the people in the field updating, creating and deleting. And it should have an input into who can read this data, who can see it, who sets the price, right? With that with that aerospace company, who sets the payment terms for a vendor, right? Those are business decisions. They are not tech decisions. They can be enabled by tech. But that's hopefully these are kind of ringing some bells of why without understanding business process and the journey beyond the scope of this webinar. But we also sometimes do, you know, customer journey maps from the customer perspective, who hasn't had that horrible customer service of, you know, I changed my address online and I'm still getting my my bills sent to the wrong address and or, you know, I called to update my credit card address and I'm still getting, you know, and we all know in data management, it's probably because it went to the ERP system and didn't update the, you know, the mailing system that sends out your your ads or whatever, right? But that from a consumer perspective, that's pretty darn annoying. So how do you map that out? Or we've done this a lot with universities, the student journeys, you know, what or patient journey, right? How does the data get collected from the customers or patients or students or citizens experience, right? So these are really, really helpful in this different ways to do it. You know, not this could be a whole webinar and data governance roles, but here are some that are fairly commonly defined of the owners are going to set those high level rules. You know, can who can see social security number or, you know, social insurance number in Canada or whatever, right? How who can see what or what are the high level rules or what? How do we prioritize our domains? Your business data stewards are going to be a little more in the weeds. They're probably in the systems and understanding what drop down fields should be or some of the more detailed business rules that are probably still approved and vetted by the owner, but these folks are little in the weeds. When a technical data steward, maybe they understand the CRM system. So if we're trying to set business rules in your CRM or ERP or whatever, hopefully that's a combination of your business and technical data stewards, because the tech should support the business, right? Just a quick sample. Again, tons of good material and data diversity here and elsewhere about governance, but hopefully that kind of fits that together that these folks in your swim lanes are probably your stewards doing the work. So that leads me to quickly, because I know I want to get to some of the questions, but there are many ways to do governance and stewardship, right? You can do it by process that the process owners, who does billing and pricing? Those of you are going to be your stewards or not a fan, but by systems. Maybe those are your technical data stewards, right? I'm the technical data steward for my CRM or my billing. Data domain, this is going to be another Donorant seems like this is the right one to pick. I'm going to have a domain owner for customer or for product. Hold that thought. I hopefully will tell you why I feel very strongly that's not a great method or org section, Centric. Is it finance, marketing? Is it North American marketing and Europe marketing? Is it all of that or some companies like to do more of a capability centric model because org charts change, capabilities don't. Whatever you call finance, it's still finance or I could call HR, you know, people management this year and maybe it's talent management next year, but it's still the capability of managing people, right? Why I don't like data domain center will go more into a hopefully you've seen in some of those process models. Great, who owns customer? Is it billing that owns customer sales that owns customer marketing that owns customer that probably all love to raise their hand and be like me, but they all have different perspectives on what does how I bill the customer is very different than how I market to the customer. So they all should have a voice, which again, why generally in some sort of governance structure, this cross functional representation, if I'm looking at customer, for example, I hope sales marketing product development legal, what I can what I can legally do with different data privacy laws, et cetera, et cetera, et cetera, should all have a voice and to the people who say that's going to slow things down, well, if you don't do it, it's going to be work. You're going to be clearing things up and you can make some again, extreme example of a workshop solve the problem with payment terms, but it often doesn't take much longer than that if the right people are in the room and they understand the downstream effects that at least give us some visibility. It's also nice if you are on the technical side and you can you can chant from the rooftops all day of you can't change this field or you can't own this field because somebody else uses it downstream, but when people collectively hear it together and see from the other person's point of view, how these different fields are used, it just generally becomes more productive because they're doing it as a team. So that's why I feel you shouldn't have one owner from for customer, for product, et cetera. That said, from an architecture perspective, you absolutely should create these domains and maybe there's a data architect or a master data team managing things like customer or product. It is a big deal, but it's because it's such a big deal. That's why you can't have one owner, right? So conceptual data models, full disclosure, I love data models. Often this is the roadmap for your org. What I love about a conceptual data model in one page, you really describe the org of we have products, customer suppliers and patients, you know, et cetera, et cetera. In one page, we often even just color coded, you know, maybe blue is your master data, beige is your reference data and white is your transaction data. I mean, it's a really I've had customers kind of prior. You can't do all of your master data domains at once. So if our master data domain for staff, customers and products, what are we working on when and are their interrelationships between customers and staffs and staff and product? Absolutely. So it helps kind of put that on context. And then from there, absolutely, you need to understand the critical data elements or the detail around customer. And this is a whole, it's a bit of an art and science. You shouldn't have 100, but you should have more than one, right? Of all the attributes around customer, first name, gender, date of birth, et cetera. So there are different ways to implement a master data. Again, some of the misconceptions are often that it has to be one big central system. You could do registry where it's still stored in the source system and you just have pointers to it coexistence. I think I often like this when it's kind of more mature that, yes, you're still entering customers in the CRM and your ERP and that's how, but your MDM, the sort of a coordinator across it, you could do a centralized where everything's in the MDM and pushes out or and or often this analytical focus where you consolidate MDM for kind of data warehouse reporting can be kind of a helpful way to start because operational master data is absolutely valuable and life changing for a company. That's where you update your address once and everybody gets the correct address. You can also imagine if that's done incorrectly with the wrong address, what the downside is. So that's why sometimes it's nice to do analytical as a first step. Make sure we're all right. Worst case a report is wrong that we can correct, but it's not going to affect your operational systems. And then when that's confident, do it with your operational. So the idea is that you do have master data in your different source systems. MDM can be this golden record, can feed your warehouse, feed your reporting and then publish and subscribe. And you have these different data quality. Sometimes you need human in a loop with your data validation. Is this the right patient that I'm doing surgery on? Even if my match rules are absolutely confident, I probably still want someone to look at that one. I'm going to amputate a leg. Pretty important, whereas maybe for a marketing campaign, 90 percent probability is good enough that it's the same person, right? So the idea is that your model, you have these names, etc. across all of your different systems, first name, last name, date of birth, etc. And then MDM, you can think of it either as a super set or subset, right? Super set in that not every system maybe has all the attributes you want, but a subset isn't everything you ever want to report on. It's that core, identifiable, you know, golden information about, say, for example, a customer in this case, right? So the idea of these these tools are we can create these matching because you don't want to go through your billions of customers and say, yep, I think that's John Smith. I mean, that's a perfect thing for a tool to do with the business rules that your data stewards set, right? So how do I know that this is the right John Smith? Is it by first name, last name, first name, last name, date of birth? That's kind of the art and the science of how you do those matching. And then from which systems do you create that golden record? Do I take the name from one system and there's some art and science to all of that, right? So that is like the tool that is probably like, wait a minute, that's our core thing. And then there's a lot to this. But at its most simplest, it can be complicated. But what are the rules and what are the priorities and how do I survive this golden record is really a lot of the oomph that the automating this can give as long as the business people are setting these rules. One more slight rant, if you didn't get it before. MDM is not reporting your analytics. It enables it, right? So I've created that one view of Stefan Krauss or John Smith. That's going to be a dimension in my warehouse. Then I can report on customers by region because both of those are master data. I could do a graph pattern to see what other people buy similar products and do all this great, but you can't do that if the nodes of the graph are not right, right? Or you can feed your data like and do some social media, sentiment analysis, but you have the right in customers, right? So it is the one degree view that enables the 360 degree view, if that makes sense. One quick example, I kind of gave this across the way, but this was this was the cheese incident, right? This company just knew they were losing money. They didn't exactly know what it was to solve. And we did a lot of interviews. We talked to the kitchens, we talked to the menu, we talked to supply chain, we went to the restaurant and saw the point of sale. They had some governance, they had some process issues, but at its core it was using master data management to create that single view of the menu and the ingredients. We had the buy in of marketing, of supply chain, of sale. Everybody was bought in and they had to solve it together, right? And that's where the business process and the governance came in. So the solution was master data, how we came to the solution and how we solve that was combining that master data with the process and the governance around it of who own price, right? And who own the ingredients on a menu and things like that. So with that, in fact, one of the first comments I was, you know, love this topic is really relevant. It is the more things like AI, the more analysts we want to do, you're going to need good master data for good master data. You need not only architecture, but also process and governance and getting this right, there's a bit of work, but it's absolutely exponential. That's going to have a positive impact on your pricing and your sales and your efficiency, right? So I hope you can join us for next month where we'll talk a little bit more than architecture and governance collaboration. We do this for a living. So full disclosure, if you need help with any of this, we're happy to help. My email is in the second slide and with that I will send it over to Shannon for Q and A. And I thank you so much as always for a meeting presentation. I'm going to dive right into the questions here. Do you when it comes to MDM, how is that accomplished when your system is fed by other data sources? Do you as your manager, do you manage it manually or bring it in a third party to help manage all of the data? Well, I hope I kind of got to that a little bit with that. I'm not sure when that came in. I think it came in early. But that picture I have where, of course, I can't move my own slides again. That is the crux, right? Is that by definition your MDM is going to be across systems, whether they're external, sometimes they're external, you have less control or even internal, you're going to both publish and subscribe from them. So get the information from and push out. And then there's different ways you can do that. And some of them are in evolution, but absolutely understanding what sources where the data comes from, the quality of data within those and what you need to augment that to me is a huge part of the crux of MDM. So hopefully that the remainder of these slides helped with that question. Perfect, Koya or Stephen, anything you want to add? Yeah, I think it depends on the level of the maturity of the organization. If you kind of have a smaller company, then most likely you won't have a governance process and then you have to look at potentially getting some advice from some services companies. Whereas if you have a large company, most of the time there is a governance council, there is potential stewards within or within departments that you want to combine and then you create a governance team out of that. So it does vary. I would push back on that a little, even though there's not a huge, huge governance organization, there's going to be SMEs and I would never outsource your business rules to a third party. I just because that's core, they should be asking the folks running. There might have been some other companies, but yeah, it's more of advice on how to get started, not necessarily outsourcing the whole governance process. So it's just if you don't have a know where to start, then some of these folks would say, OK, this is how you get started. These are the people that need need to pull in. And then certainly these are the kind of things that you need to look at. Like Don, you were talking about the business processes, right? Absolutely, yeah. Stephen, anything you want to add? I think I think they will answer this question. I don't need to add. OK, now we're coming closer and I'm going to slip in one super quick. Just the elevator. Everybody, do you think the biggest implementation or impediment to MDA implementation and usage is that companies are typically organized by function and not business process? I don't think so. I think that's just a truth, right? I mean, sometimes when I gave and I'll give the other folks a chance to answer to, but when I showed those governance models, sometimes it's both like maybe the data ownership is at the function level, finance, marketing, but marketing has a lot of different processes, lead, gen and and market research and things like that. So maybe at that point, some of the process, but you can get started. And again, a lot of this can seem big, but you can start with just a few functions and move out. But I don't think that's an impediment. I think it's just a fact and you just want to be flexible of how you do your ownership and stewardship within that. But curious what the other guys think. Well, actually, that's one of the reasons MDM was created in the first place, because we have silos of data and everybody felt that they were special until they got together and like, oh my God, we have a data problem. And so MDM really was developed to fix that and create the cross section across them. But the important thing, though, is that you have to keep those stakeholders involved the whole way so that they don't think that it's developed for someone else. Absolutely agree. Perfect. Well, that brings us right to the top of the hour. Thank you all so much. Thank you to Inframarkey for sponsoring and helping to make today's webinar happen. Thanks to Donna, as always. And thanks to our community for being so great and having such a great engagement and great questions. Just to answer the most commonly, just a reminder, I will send a follow-up email by end of day Monday with links to the slides and links to the recording. Hope you all have a great day. Thank you so much. Thank you. Thanks. Bye. Thanks, y'all.