 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 discuss master data management, aligning data, process and governance sponsored today by Precisely. 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. For questions, we will be collecting them by the Q&A panel, 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 chat with us or with each other, we certainly encourage you to do so and just note that the chat defaults to send to just the panelists, but you may absolutely change that to network with everyone. And to open the chat in the Q&A panel, so you'll find those icons in the bottom middle of your screen to enable those features. And as always, we will send a follow-up within two business days, containing links to the slides, the recording of this session and additional information requested throughout the webinar. Now, let me turn it over to Carrie for a brief word from our sponsor, Precisely. Carrie, hello and welcome. Hello, Donna. Thank you. So I'm Carrie Young. I'm the VP and GM for the InnerWorks product at Precisely. And as Donna mentioned, I'm just going to give you a short overview of our product and talk a little bit about Precisely as well. So data has become the single most important corporate asset for driving strategic advantage. There is an exploding need for trusted data on which companies can build successful digital transformation. And as we all know, this need has significantly accelerated in the past 18 months. So according to IDC, CEOs are now leading the way to ensure that their organizations leverage data as a strategic asset. Massive investments in digital transformation projects are fueling huge investments in global data infrastructure. Over $200 billion just this year, according to Gartner. And as a result of the strategic importance of data, Forbes reports that 68 percent of the Fortune 1000 now have a CDO, which is up six times in just the past decade. So why MDM? Well, digital transformation initiatives are heavily dependent upon integrated, clean, accurate, contextualized, enriched data in order to deliver the maximum benefit to the organization. This is where MDM comes in. Companies who implement a successful MDM program across the enterprise are realizing multiple benefits, including faster time to value, increased efficiency, and ultimately happier customers, increased market share and higher revenues. An MDM solution should include these core capabilities in order to acquire, maintain, and share multiple domains of data across the systems that power a business. This includes features such as deduplication and golden record management, which makes it possible to normalize and standardize information from any number of systems of record, workflow and collaboration capabilities that streamline and improve operational business process around master data. The ability to organize and link a company's master data in an unlimited number of relationships and hierarchies across domains. And lastly, the solution should include an intuitive, dynamic role based UI and dashboards. So precisely, we understand that trusted data alone does not ensure business success in today's world. Business agility and speed are also critical. And the ultimate end game is not just better data, but also faster processes. The EnaWorks MDM includes the critical capabilities that I just described and has been designed to ingest or synchronize information with any source system and once ingested, validate the incoming data to make sure it meets a company's quality requirements. Once validated, the data can enter a workflow where it can be further enriched and then synchronized with any other business system. The EnaWorks MDM enables a foundation for managing multiple master data domains that can be augmented by any other types of data, including digital assets, application data, reference data to help people and companies master, people and companies master, manage and visualize their most important data assets in a single view. The EnaWorks MDM enables a foundation for managing multiple MDM domains on a single instance of the platform to help people and companies manage and visualize product, material, customer, supplier, location, financial and asset data across both physical and digital touch points. This enables companies to view and link master data across any domain in a single view and get the intelligence they need to make better business decisions, something we refer to as cross domain intelligence. This capability enables customers to go beyond just managing their master data and to get the intelligence they need in context of their channels, customers, suppliers and locations, enabling companies to drive better business results, not just better data. So next, I'm going to share a few examples of how EnaWorks customers are leveraging the EnaWorks platform. So the first company I'll talk about is Fender Musical Instruments. So you're all probably familiar with this iconic brand manufacturer and retailer of electric guitars and amplifiers. So prior to 2016, Fender primarily sold their products through distribution and big box retailers. In 2016, they decided that they also wanted to sell direct to the consumer and in order to do so, they identified multi-domain MDM as one of the key capabilities they required to make sure that they required to move forward on the strategy. They also wanted to use multi-domain MDM to master and manage something they refer to as the artist domain. In their world, artists are the famous musicians that play Fender guitars. The artist domain would contain not only the profile of these famous artists, but would also house references to videos of the artists, their songs, and then would link to the products that they use and play from that were located in the product domain in the MDM. So as you can see by the slide, Fender has realized a great deal of benefit from implementing multi-domain MDM, including faster new product introductions and increased revenues. So next, I'm going to talk about Thomson Reuters. So Thomson Reuters had several challenges around their data, their master data. Their data was inconsistent and was severely impacting customer satisfaction. Thomson Reuters planned to manage and master six different domains in their MDM, including customer, products, and employees, and they required a solution that could be used and deployed globally. So like Fender, Thomson Reuters has been reaping the benefits of multi-domain MDM on a single instance. They haven't shared yet the actual percentage improvements in data quality and customer satisfaction, but they have let us know that it's been significant. So for those of you who don't know about precisely, we are the global leader in data integrity software. Our software consists of a portfolio of products and services that deliver accurate, consistent, and enriched data, powering confident decisions. Today we have over 12,000 customers in about 100 countries, including 90 of the Fortune 100. Actually, I saw something yesterday. It's actually now 99 of the Fortune 100. This includes customers from all industries, including retail, manufacturing, post-sale and distribution, CPG, and many others. We are strategically aligned with some of the major names in technology, including Databricks, Snowflake, SAP, and Microsoft. Okay. So with that, I'm going to turn it back to Shannon. Shannon, back to you. Carrie, thank you so much for this great, for kicking us off. And thanks to Precisely for sponsoring today's webinar and helping to make these webinars happen. We really appreciate it. If you have questions for Carrie, or about Precisely, feel free to submit them in the Q&A section as he'll be joining us in the Q&A portion at the end of the webinar. Now let me introduce to this series speaker for this series, Donna Burbank. 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 is currently the managing director of Global Data Strategy Limited, where she assists organizations around the globe in driving value from their data. And with that, let me give the floor to Donna to begin her presentation. Hello and welcome. Hello. Thank you so much. Always a pleasure to join these webinars. Nice to see a good turnout and always a very vibrant chat, which is nice. As Shannon mentioned, this is a series. So many of you, and it's always nice to see some familiar names in the chat. They do join us sort of every month, which is nice. If this is your first time joining us, everything from the past webinars from this year and others is actually all online at the university, as well as our own website. We'll link to back to the university. So you can catch a replay if you missed anything in the past that might be interesting. And we hope you can join us coming up with some of the other ones. You can see a wide variety of topics coming up this year. So, but without further ado, to get to the topic hand today, which is master data management, which as Kerry alluded to is hotter and hotter. I mean, we're seeing a big part of our practice. I mean, it's always been a part of our practice, but even even more recently, because of the things that Kerry mentioned, digital transformation, you know, people wanting to just basically grow the business and those businesses are very varied. So that's always a fun part of the job that we'll talk about later of, you know, how varied master data can be. It isn't always just customer products, vendors, that sort of things in the value. And again, nice introduction from Kerry with some some big name brands that are really are getting value from this. It can be a lot of work. It can be complex. That shouldn't be daunting, though, because you can do do it in a phased approach and you can really get practical value. So that's what we're trying to do in all of the webinars here. If you've heard me speak before, but particularly today, MDM can sound scary. You might have heard, you know, reasons why MDM fails and all of that. Well, you can always focus on that. But I think more and more we're seeing more and more success. But what does make it complicated is is the topic of this webinar is that there's definitely a technology component, you know, tools like and it works and others, but there's also a people and process component. And as you've heard me say before, data is complicated, but people are even more complicated. And when you try to put three together, that's often why MDM can be challenging. And we'll talk about all of those aspects today. So again, if you've seen me present, you've seen this this framework and it's I keep showing it because it's helpful and it actually touched on some of the things of this webinar and things that Kerry mentioned as well as, you know, the first thing to do is always start with a why that the business strategy. How is data supporting that? So are we fender trying to sell more guitars? You know, are we a government agency trying to support our citizens? Are we a hospital trying to support our patients? You know, very different approach, depending on what you're trying to do. And then what kind of data do you have kind of going that bottom up? Is it all? And this is super important with MDM. And we'll talk about that later too of, you know, is everything nice and perfect in a database, a relational database that has open access and you can have APIs to publish back and all of that, probably not. There's probably a lot of things in documents and semi-structured or, you know, vendors who want to, you know, common thing we hear is we're the source of truth. No, no, we're still the source of truth. You know, I think everyone wants to be the source of truth. But therefore, a lot of vendor packages can be very, you know, close to the chest and not as friendly. I think one of the things, hopefully I can give you in these webinars, is a bunch of years of, you know, tried and true best practices of what worked and then sometimes things that didn't. And I think one of the most frustrating challenges I have in MDM is that limitation of the source systems and, you know, not every vendor is friendly to try to integrate with. Then you go sort of up the layers of integration. Again, when we talk about MDM, all of that is important. Whether it's real time, published, subscribed, whether it's for reporting only, et cetera, et cetera. So the point of this and why master another recent master data can be complicated is you'll see there's a box there called master data. And many of you who are data management professionals are sort of thinking of the DM box or of this framework, like, well, yeah, you can't do master data without data modeling, right? And you can't do master data without quality. Actually, that's a piece of master data and you're all right, right? And a lot of the tools, master data is a depth discipline. But again, as Carrie mentioned in the beginning, a lot of the tools have embedded functionality to do some things like data quality. Yet you could also have a data quality solution. So not to try to make it complicated, but that's also why we often recommend our practice kind of a phased approach. And the good news of that is that you might be doing a whole lot more master data management than you realize. Often, again, we've done a lot of these lately. We put a roadmap together for a client and we say, okay, this could be daunting. But the good news is you're already doing data quality here and you're already doing some modeling here. You can kind of put together the things from the kitchen and make a nice meal sometimes. But you can't do any of that without the data governance and collaboration. And any of us who are data architects or data modelers on the call love our terms or metadata managers, right? What do terms mean? Master data management is classic. And it's one of those that we're all right often when we talk about it. So often when a technical person talks about master data management, they might think of their tool and publish and subscribe model and all of that in the data quality. Other people might be talking about the business process or even the people. Many companies have a master data team. And when we talk about master data, they think of those human beings or they think of the process. And again, all of those are right. And the first or anything is we've gone into companies with either more than one master data management tool let that sink in or does a master data management team not talking to the architecture team that also has a master data tool. Again, coordination is difficult in any company, especially a large one. And that's also what makes master data challenging. So anyway, I don't want to spend the whole time on this one slide, but hopefully that's kind of a helpful background because we'll touch on a lot of these as we go through the rest of that presentation. So what is master data? I mentioned that we love our definitions as data management professionals. So I'll start with one. This is from the Gartner online IT library. I kind of used that one a lot. So master data is really the identifiers and attributes of the core entities of the enterprise. Now that can sound rather academic, but again, that's the challenge of master data management and all the technology sounds so highfalutin for lack of a better word, but it really is just the basic building blocks of your business, your customers, your prospects, your citizens, your patients, your students. Again, whatever type of organization you have. And then master data management, sort of by definition is the... I would never use this in a data model, that circular definition, but it's the management of master data. So again, it's a technology enabled discipline. I like this definition, but it's also that idea of business and IT working together to ensure the accuracy, stewardship, et cetera, of the enterprise official shared assets. I like that definition because it talked about both the business aspect. These are the core assets of the business that you're running or we're not profit or whatever. And then it's a combination of both tech and business. So the other thing I like about master data is it's very intuitive. So this does come from an early cave painting. I think they found in a rural France, no, I'm just kidding. But if you do go by, this is from one of my data books, that the idea of master data is fairly intuitive. If you were doing master data management for a caveman family, what would be important to them? Themself, the people, the animals, the process, the things they're capturing. And we also tend to be very visual people. So you'll see that's an early data model. So what do you draw on the walls? The things that are important to you, the people, the animals, the buildings, you learn a lot about a culture from what they're graffiti. So data modeling is organizational graffiti, if that makes sense. It is nice to kind of model out data in a way that is very clear. And you've heard me speak. You know, I love data modeling and it's a nice way to sum up a business. If you have a good conceptual or logical data model, you can very quickly understand what that business does. Here it's pretty clear we have cavemen hunting. It's missing a verb phrase on that, but cavemen hunt animals. Either no animals than they starve or more than one animal when they're sitting pretty. You can learn a lot from just two boxes and a few lines, which is really nice about master data because it should describe the organization. But what is it? What is master data? Again, when we often come in and talk to execs, that's kind of the basic question. I don't know what you're talking about, but when you try to give some earlier examples, they're like, oh yeah, I want to fix that. And when I find fun about my job, when I do fun on a good day, when I'm finding it fun, as it's always those kind of stories. When you come home and you're having dinner with the family or whatever, these stories that are so passionate about each company. And when you step back, it is almost funny because we're giving in, we're doing interviews and I'll talk about the one on the upper left. It was for a restaurant chain and we brought up something. Someone brought up the cheese slice and was like, don't talk about the cheese slice. What landmine did I step on? I never really thought slices of cheese were so emotional. They had a very good reason to be upset about this and we'll actually give an example of that later because of master data. So what is a restaurant do? They sell menus. They sell components of a menu and the supply chain that no pun intended feeds that menu is a big part of how they price, et cetera, et cetera. So long story short, then we'll talk about it later when they had the price on the menu for adding a slice of cheese to their sandwiches, it wasn't priced correctly. And because that was a really cool slice of cheese, it was blue cheese or something. I guess that doesn't come on slices, but you know what I mean? It wasn't priced correctly. It was very popular and actually they ended up losing a million US dollars across the year before it was caught just based on master data management. The fact that the basically core product really wasn't consistent across supply chain, across menu development or product development across the locations, et cetera, et cetera, et cetera. So this was multi-domain MDM but it came down to a slice of cheese. Similar one, we worked with a manufacturing company and they had a $2 million baby bottle. They were selling baby bottles they were actually selling through Amazon.com and if you work with them, they actually had fines for not getting your master data right if you have to rework the master data. And these were just based on some of the fines for trying to sell online. So again, product master, the one on the right always long story here, actually this was from, I can use the name on this one. It was the environment agency of England because they spoke with us a couple of years ago on diversity and their master data is the environment. And they started with data models. They were really happy with data models. They had a long heated discussion. It's five aim my time on whether a living organism could be sort of rationalized across things like cows, like fish, like whatever. And someone very cleverly said, well, we're collecting dead fish. How can that be a living organism? And I think I chimed in and said, well, that's just a flag, right? Live or dead. There's a living organism with the status of dead. But anyway, that was kind of a funny one. You don't always think of dead fish as a master data domain, but it was. You know, back to people the, you know, Carrie mentioned the party model. There's this value for the physical. I won't start my rant. I'm actually not a fan of that term because I think especially at the conceptual or business level, you kind of lose the whole point of are we talking about physicians kind of over the left or the employees that are working with those physicians or, you know, are they customers? Are they patients? They're all human beings, but they all in a business have different terms. So yes, at the physical level, you may abstract that to something like a party, but especially when we're talking about the business, I always start with the real words people use because you get a lot of information around that. Yeah, again, we work with the hospital change. Fairly important, which doctor is credentialed at which location? Those are two master or maybe reference data to do heart surgery. Kind of important that the early, you know, people's lives. We work with a big insurance company that will work with high net worth customers. And they did a lot of advanced analytics of, you know, does this person own how many properties across the globe? How many companies, you know, people like you and me with billions of dollars of net worth scattered around the globe. But once they did all that great analytics using open data and all of these sets, at their own data, they couldn't tell at a broad ranges of businesses, whether the Michael Jones is that high net worth customer or, you know, the student that just graduated and is in a lot of debt and they couldn't rationalize that against even their own customers. And that was a really big business issue because as you can imagine, the potential of both of those customers is very different. And in location, you've actually heard me say that many times in this overview, without even trying, right? The cheese slices were, we sold at a location. The doctors were credentialed for a location. The fish were living in a location. And that's always a big part of it, whether it's a market region, whether it's a physical location, catchment was actually a master data area for the environment agency. That was what they had maps and they kind of managed catchments of areas. We've also seen that we're working with a school and they have what they call the word, same word catchments of the different areas where students come from, sites, manufacturing sites, whether that's a manufacturing site or a sold to site or whatever. So location always comes into play. What's interesting about that, oops, sorry, I have it later is that, is that reference data or is that master data? It really depends on the use cases. So, but what I find fun again about my job, master data, consumer economic, these are all real world experiences of master data we've worked with. You're probably wondering about the cows, right? So one was literally when the election, the environment agency was one, they were counting cows across the landscape. And then how you did that was actually very complicated. And is a cow the same as a fish and master data? To them it was they're both living organisms that could be rationalized into a party model for animals, right? Speaking of cows, we worked with a retail company that was literally selling cow suits. I had to do that with a straight face, whether it was cow suit slash adult slash medium slash large, I mean, reference data around the sizes, but at the end of the day, they were selling cow suits. But that's master, that's product master. And I guess where I like this slide, A is just fun to step back and think what you do for a living. But the idea of product master is so varied. Some of it were, if you look at the one on the right, we worked for an automotive manufacturer. They also sold wholesale components. So is it the car that's the, is it the part? Is it the whole vehicle? Is it pieces of that? Carrie mentioned the beginning, fun example of our rock stars master data. Kind of they are, that's neat. Similarly up on the right, we had a company that trade marks of, maybe the trademarks of the brands of those rock stars over those products could be master data on and on and on. So you can see those classrooms, hospitals, lipstick was one, it was a product someone was selling. Anyway, on and on, I find it fun, but you can think of in your own business, if master data is new to you, just say a paragraph when someone says, what does your company do? You know, we manage student accounts across several campuses in several countries or whatever, as you already have campus, you have student, those are almost those nouns of the sentence when you describe your business is your master data or your reference data and we'll get into that. So why do we care about that? Probably obvious from some of the examples, but the classic one is this 360 view of customer. And I won't go in a full rant, but a minor one just to get the point across. The business value is the 360 view of the customer. And then I'll talk later about this. Master data is not the 360 view, it's sort of the one point view. The 360 view is often the analytics you can get from master data. Master data is why it's so important, but it's also fairly boring. It's the very boring, how do I know that this guy in the middle is Stefan Kraus and he's the dedupted version of Stefan Kraus and I have his right age and we'll get more into that. Once you get the Stefan Kraus in the middle is the actual customer at this age, et cetera, it's not his twin, not his dad, you can get all of that great analytics that he lives in Pontresina, I'm a ski company, right? And this guy could be my perfect customer, right? He lives in Pontresina, Switzerland. He's a ski instructor at a VIP member of our loyalty program. He also a Nordic skier. He won the Engadine ski marries, like all these great things. We also know how he likes to interact with us. He's young, he likes to go online on a cell phone, get a text about a latest ad and then buy the stuff. You'd think he's our classic case, but when you look at how much he's actually purchased, it was really only 500 euro for outdoor gear. He gets everything free, he's a ski instructor, he's good looking, he gets free gear, or he works at the resort. So maybe he's not our best customer, you'd think he is, but is he really the best customer? So analytics can do all the stuff around our friend Stefan, but what master data can do is, which Stefan Kraus is this? Is it Stefan Kraus who lives in St. Merritt's and skis every day, or is it Stefan Kraus the banker who lives in Zurich and skis maybe once a year, but is it really one of those high net worth customers? And he spends 3,500 euro just to go on his one trip, because when he goes, he works hard and he wants to have a good time. He's actually, you wouldn't think anything else about him. He likes a footballer or soccer, he doesn't want to sell phone, he wants physical mail, and he likes to buy it in a physical store with someone waiting on him and telling him the best skis to buy. He's 62, is there a relationship? Is that his son? Is that just a random name? That's the stuff that master data can help with, which Stefan Kraus are we talking to? And back to that real world example we had, this is fictitious, but of the insurance company we had, and they couldn't tell, are we talking about Stefan Kraus, the high net worth individual? Or Stefan Kraus, the ski instructor with a great life, but not a lot of money. That's really important when you're running a business, who do we sell to? Sell to this Stefan, he's gonna give you six times the results, right? So anyway, that's what master data can help with. It doesn't do the analytics, but it supports the analytics. And back to some of those business drivers that Kerry was talking about in the beginning, one of the real many reasons we're getting a lot more business from master data management, as people try to go digital, doing more digital transformation, you need master data to support that, but I don't know my products, my customers, it's hard to go online with that. Artificial intelligence or AI is another one. Wouldn't it be great to do predictive analytics of what Stefan's going to buy? But if I don't know what Stefan I have, or even what my product hierarchy is, you can't do all that cool AI. So we get a lot of business from people trying to do the sexy stuff, but I think master data is sexy for anyone who doesn't, but most people, they want to get to the end result, you can't get there without the master data, but master data isn't really an end of itself, it enables things. So on that note of what's master data, what's reference data, I found this type of graph helpful when I was first learning it, like it can get confusing. So it is different from data warehousing, it really is just getting those core hierarchies or master data elements. So if we're thinking back to our ski sales company or sporting goods company, Stefan Klaus bought some telemarked ski boots in 2017, has a certain price, a certain code, where the location, I also bought telemarked ski boots in Boulder, Colorado, where I'm from, different price, different skew, now is that right? Do you have different skews in the US versus Europe? That location is at the store you bought it in, is that where it was manufactured? Is that where I live or where I bought it? There's some metadata there, right? But the transactional data, the fact that Donna Burbank bought her ski boots at a different time and different place at a different price, that's your transactional data, that might live in a data warehouse. The master data is your, the fact that Stefan Klaus is the banker, not the skier, and he has a certain age, a certain customer ID, et cetera, et cetera, that Wendy, she is what she doesn't live in New York, she actually lives in California, but she was visiting New York to buy it, getting understanding who that is. Your other master data is the product. Again, is there a prior to hierarchy? Should I've had the same code for both ski boots? Is the same boot, different price? Is there a hierarchy, et cetera, et cetera? And then location, again, I'll talk more about this, but is location reference data? Is it master data? Yes and no. But some of your core, we call reference data, which is kind of like a little cousin of master data. You think of, it's not the perfect example, so bear with me, but in reference data, just think codes, often it's your lookup codes. Here it might be your location code, but again, even that can get complicated. Two letter acroity, two level letter. CO is Colorado, which is a state or a region. CH is Switzerland, which is the country. They're both two letters or two characters, but very different things. So that in itself could be complicated. Again, folks like me love that, fix figuring out that puzzle. Not interesting to everybody, the business just wants it right. I just wanna sell more stuff in Boulder, Colorado. I don't really care about the codes, but somebody needs to care, because that helps you clean up that data so you can do the analytics and the retail, online retail and things like that. So hopefully that little example is helpful to you. And again, I kind of referred to this a few times, so maybe it's anti-climactic, but I think this is important to realize that one person's master data is another person's reference data, and there is no perfect answer. Location is one. A location could be referenced data in that I just wanna know that I have certain state codes, whether AL is Alabama and CO is Colorado, et cetera, or am I someone like the Environment Agency, or I'm a map company, or I'm doing geolocations, catchments and regions might be master data to me. And there's plenty of examples of that. We're working with one company that does a lot of market research and things like, I don't know, I don't know, the flavor of a menu item actually is sort of master data for them. They're a whole business or flavor houses, in Switzerland and New York, they have whole companies that just look at flavors and flavor hierarchies. That's their business. So normally, in most people I have a menu and the flavor of the chocolate shake is chocolate. That's just an attribute of the product. Some people, that is the product itself. So again, you can have fun and get in these circular references and it's, you don't get overly academic about this, but it is interesting. They're sometimes managed different ways. Is it a first order area of your business and it's changing rapidly and you're kind of using it every day? That's probably your master data. Is it more of a lookup code or an attribute on something else? That's probably reference data. And I know that's kind of a hand-waving definition, but hopefully it's at least a high-level way to look at it. Okay, again, that was kind of the water, the how, the why. MDM, though, to get it right, as I mentioned, is at least three aspects of it. One is that data architecture. How do you get the system architecture to decentralize it, to distribute it? What is that data model for customer patient product, whatever? How do you do the match, merge, survivorship rules? All of that super important, super complicated whole tool sets to do that. And if you look at the lower right, this idea of the data governance is also master data. And we've been doing this a long time. I've probably seen examples of this outliers where maybe just one of these bubbles was enough to do master data. Maybe it's so automated, we can just do it all with architecture. In some cases, it's really a manual process and we do it through governance. In some cases, it's all about the business process. In general, it's some combination of these three. The governance is who is putting it in, right? Who's typing the data in? Who defines what the security levels for different customers are, or the business rules, or how we resolve conflicts, that's a big part of how you're on the business, the people part, that's your stewardship. But also business process alignment. We'll talk more about that. How data gets entered across that lifecycle of a customer or a patient or a student is really can be really challenging. It's not, and I'll talk more about this. It's like a data model that can seem really easy. We've got this model of customer and we've got 10 attribution you populate in a certain way. But think of, and I'll probably mention this again, but when we say someone owns patient information, well, what does that mean? When I go to the hospital, one person kind of checks in my name and my insurance, my address, then I go to the doctor and she gives me the diagnosis. Those are kind of different attributes on a model and I don't want the doctor handling my insurance information and I certainly don't want the person getting my insurance handling my diagnosis, right? So people or think of sales, right? Who handles the pre-sales is different than who ships to the customer and customer support, same customer, but people might own different parts of it or update different parts of it along the different areas of the journey. That's often where we see a lot of the problems. Good old fast and crud matrix. We'll talk about that later. Where is data created, read, updated and deleted across the business process is often where these problems or solutions exist. So to get it right, it's generally a pieces of all of that. We'll go through that. This could be a whole webinar. I won't go into this. I'm going to show you one example that again, it's just kind of stylized. Don't judge me, it's just an example, but there's several ways you can implement MDM. These are some classic ones. Generally in the real world, it's a combination of all of the above depending on, you might have one approach from reference data, one from master data and it might be some realism of, again, what we'd like to do and what the systems allow us to. So just quickly, registry is more of, I have it in the source systems. I use MDM just kind of the cross reference coexistence might be it still lives and breathes in the source systems, but we use MDM, our master data to kind of harmonize that across the systems. It could be that we use MDM as that single source and that is the place you enter all the information. And then there's the aspect of, are we using it operationally, which is literally in the live systems, you know, the system that's selling stuff on across the ski boots or are we doing reporting on it? And it could be both. Many companies start with analytics. I think that's a good approach. Before we try to boil the ocean and have, you know, it's the value, right? That Stefan Kralis came into the store and updated his email address different than the one he had online. Don't we want all the systems to sync so that we can send him an email and thank him for coming into the store? Seems really easy, but that's the complexity of that operational focus at a minimum. And sometimes it's an easier first step. Can we do a warehouse or some analytics on Stefan's buying patterns and things like that? And sometimes that's a nice first phase. You know, understand the master data, do some reporting on it. Once it's really being in use and we understand it, then starting, because once you start pushing back to source systems, you're making it real for good or bad. You know, I have the, we had a classic case. Actually, this was true. They actually had an MDM solution. But the problem was it made sense on paper. The first point of contact was the sales person. So have that be the email address it cascades through and it did cascade through all the systems. Problem was we've all done it. Well, I've done it. You go into the sales person, high end thing they want to sell. They say, what's your email address? I say, go away at leavemealone.com because I really don't want to hear from them until I'm ready. And that's went into the system. At this, again, it was a very high, they only sold a few each year to, you know, important customers. When it came time to ship the product, I now want you to know my email because you're going to send me the tracking number. That didn't happen because it lived from the one the sale. So had some really angry customers saying, I never got my notification because it still said, go away at leavemealone.com. And that was, again, seemed to make sense. But when you actually looked at the business process and the customer journey, it didn't. And that's what makes complicated with MDM. We is tempting to oversimplify it, but it's generally those weird little nuances that make it complicated. Okay, so if we are to simplify MDM and this is kind of a conglomeration of all those approaches. So bear with me, but just for kind of going through it. Generally, there's some sort of hub or database or storage thing that is your MDM. And that's what we call this golden record. That's knowing the correct name, address, buying patterns, whatever we choose for StefanCrops. You might have kind of, again, that little cousin reference data, which is maybe the, you know, the region code or the country codes for MDM. And then again, you have all these source systems that can either and or both publish. Again, if I'm, you know, a customer, I'm probably in your CRM and your sales and your finance and your marketing, all of those. So how do I get a common set across that? And then either you can use MDM to push back and harmonize across those source systems and also publish out to your data warehouse and your analytics and also have kind of these lookups for, you know, the classic, we've all done it. You go into, I don't know, you're dry clear. Hi, Donna, do you still live at 101 Main Street? No, I've moved. Okay, let's update that, that type of thing. Or yes, you've saved me a step. I don't have to keep telling you that kind of thing. So it could be a whole set of webinars on just this architecture, but again, just as an introduction, what makes this complicated and valuable is that each one of these source systems has its own data model, either proprietary or open or whatever, and they're all different in different formats. And you could spend, you know, months just trying to say what character set is first name across these systems and getting that right. But another part of this is getting that rationalization of what super set or subset of those source systems. So maybe I have, my name is in one and my email is in another and my address is in another or my address is in both, but which is the one that's right and how do I know? And that's again, a simple problem, but it's kind of complicated to solve and there's a lot of approaches for that. But at its minimum, one of the first steps of MDM is what fields do I want my MDM? And it's not everything. Again, this isn't analytics. I might want to know a thousand attributes for the analytics around Stefan, but his core master data, how do you, with the essence of Stefan is his first name, family name, address, state, country, email, that kind of thing. It's that kind of that core. When you, to get this golden record often, or that's the golden record is, you know, the right version of John Smith, Donna Burbank, Stefan Krauss, right? How do I know that that's the right one? A lot of ways to do that. You have matching rules, data stewardship, but that creates that one golden record that either you can report on and, or start to push back into the source system. So I go in and I register as John Smith. I talk to the sales rep. He's like, I hate being called John. Could you call me Jack? Now that someone knows that, can we cascade that across all the systems? Or I've moved. You've probably heard me rant about this before. I wish my insurance company had MDM because I've changed my address about 16 times and they still don't have that across all my systems. And I know why, but it's still frustrating. Another part of this, and again, it's a decision, it's different with every company. It's different with every type of mastery I did within a company and it can be a phased approach as you grow. So can you automate? Can I absolutely know that when I see John Smith, same address, same person, go with it, automate it, run? Maybe, maybe it's a marketing system. That's fine. I've got 40 million customers that's most efficient. Sometimes you need a human in the loop. We're working with a kind of a managed care company, really complex family situations and names. And don't get me started. I'm gonna talk to the parents. They like to have some nice, cutesy Johnny and Janie or twins. Same family, same address, same date of birth. In some cases, really clever, same gender, Janie and Jackie. And so MDM would be really hard to get that right. Do it. Is that a typo? Is Janie and Jackie both with the same address, same parents, same everything, they're the same kid, or are they twins with cutesy names? That's really where they need kind of some of the staff to look at that and go, yeah, I know Janie and Jackie, they're adorable. They come in every day, but a machine can't kind of do that. And for them, given that this is kind of a medical thing, you don't wanna amputate Janie's leg and not Jackie's or whatever, it's a horrible example. But these are actually human beings that are high touch and that makes sense. If we're just marketing to Janie and Jackie and sending them a flyer in the mail or email or whatever it is, maybe it's enough to know close enough to still get into the household, good. So again, no hard and fast rules, but you really need to understand your use case. And again, maybe even at the same company, maybe or organization, maybe for this patient data, you do wanna have a human in the loop for, but maybe location data that can be automated, right? So anyway, a lot of thought to go into that. And I've already kind of mentioned this, but worth saying, because I just know if I send the vendor on the call, but a lot of vendor, and you didn't do this, but a lot of vendors kind of mix analytic, and you're talking about MDM, they start talking about 360 view and all these great things you can do with the network analysis and social media. You can do that enabled by MDM, but that's not what MDM is. MDM is John Smith, John Smith. And I think vendors make the sexier version that I did too in the example, because that's the benefit of it, but you're not getting that when you buy MDM, you're getting this John Smith, live on 101 Main Street. And that's just a harder thing to sell. So I understand why people do it. You get any of the use case, but just especially if you're new to this, don't confill great what MDM is with data warehouse and analytics, and they're separate but related disciplines. Okay, so I talked a bit about the architecture aspect. Governance and business process is, I would argue, if not as even more important, this is a quote from Gartner that I like to quote, because actually one of this Gartner analyst actually works at an MDM tools list now, but even though tools are important, it's either the process or the governance that often helps things go wrong if they do go wrong. Often for success too, it also can help with the success to make it work. It's not always about failure. Again, this isn't a data governance webinar. We'll be having one on this series and others at Data Diversity, but generally there's some of the kind of standard DMBock type role, a business data owner, a data steward, a technical data steward that might manage your SAP system or something like that. And these all have very key roles within your master data process to help that thing. They might be the person checking to see the patient information. That might be your business data steward, right? And so they're really important players. Won't, I could go a whole webinar on this, but I just hear me out here because I've seen this go wrong. So simple to do, and I've just seen it go wrong, especially for my data architect, that says, oh, we have master data, we have customer master, we're gonna have an owner or a data steward or a business data owner for customer. And that's nice because it's clean and it seems really easy. And on the data model, you can circle it and say Jane owns customer or Jane owns patient. But I hope for my previous example, you realize that that's just too simplistic, like who owns customer, right? It's not that easy. So there's a process aspect of it, you know, back to patient, you know, who checks in the patient who manages the patient, who follows up with the patient, probably all different people, all really important. So there's a process, there's a system. You know, maybe it is, you know, SAP or PeopleSoft, et cetera. It could be organization of that, you know, maybe Europe, et cetera, are all kind of handling things different. So generally there's some sort of blended aspect. So don't go for some, don't avoid the complexity. I think it's Karen Lopez who's another speaker on these types of webinars. She said, you know, if you want your data to be simple, make the world simple and get back to me, right? It's just, that's what makes this stuff complex. It is, it's just a simple thing, like what the customer's address is, but because of the different systems, the different processes, the different data domains, the different orgs that touch that customer, are they in different, we're working with one customer now, one of our clients that has same customer, but different product lines. So are they built, you know, are they in our machines or in our parts or are in our, you know, client services, same customer in different regions, and they, because they're in different regions, they can't rationalize them. So it's generally a piece of all of the above. That said, you do have to touch each of those. I'm a bank fan of data models. Often that's where I start in one way, showing you my secrets, but if you're not even sure what your customer, I mean your reference and mastery data are, start with a data model and then start to think, you know, what are those key kind of operational components? I often color code them, customer, staff, product. Those are sort of your master data, departments, locations, maybe even position there, could be your reference data. It's a nice way to kind of stand an easy way to start to communicate that. Where things like financial transactions, that's that operational, that's the fact that Stefan bought the ski boots. That's not Stefan, it's the blue, right? So important to do, I just, I would say maybe a data architect or a master data architect owns customer, but generally the business side, pretty rare that only one person owns a domain. It happens, you know, but just be careful before you just jump right into that. A big piece of it generally is business process. And, you know, who, if you have your master data, they are customer vendor material. Where is that touched across the different business processes? Who touches it, when they touched it, how they touch it, is a super important part of master data management. And then when we talk about process, again, MDM is such a simple thing they can get really complicated quickly. What do we even mean by process? And not to talk in circles all the time, but there's data governance processes. How do I raise an issue when I know that John Smith's name is wrong and how do I resolve that? That's a process. There's data management processes. How do I get the right business rule design, et cetera. But generally when I'm talking about all of them are important with master data, when I'm talking about business process, it's more that maybe it's called workflow. You know, what's the process for manufacturing a part or what's the customer journey map of that customer journey from my example of, you know, going to the sales rep and giving the wrong email to when I buy the product and want it shipped to me and now I want to update my real email. Something simple like that can often really get to the heart of some master data issues. But there are, and that's why sometimes we start to talk in circles. Well, which process do you mean? The governance process, the data management process or the business process? Yes. But I would say start with dark blue. It's really that business process we need to align with. And when you do love the good old fashioned credit matrix, great tool with a terrible name. But again, understanding map out that process. What does the customer do? How does product go through the supply chain? And then where is it? Red updated, deleted, all of that. And again, often you get that aha moment of if you love to kind of mine for gold, MDM is for you. This one thing is wrong because of that one you in this process that so-and-so goes in and updates and we didn't realize that and we didn't accommodate for that. So it can be a, it's a great workshop exercise to get people in the old days, get people together in a room or you can do it online and just get the people who are actually using the data to let you know where and how they're using the data. That's often as important if not more so than the data architecture itself. The other part of it when we think about governance and I already touched on this but when you design governance, I'm always very careful of what the organizational structure is so you can align with that. But that's also really important when you say who owns a patient, a customer, a student, a product, an ingredient, et cetera. Probably a lot of people and I know a lot of people balk at committees but often you really need that cross functional perspective to really get that full view of all of those. Student from when they pay to when they go to class to when they go to counseling to when they go to sports all of that are different aspects of that same master data or your students. Do you really need these committees to get that cross functional view or at least a way for people to get together? But you need to line that with your core business. Often we do a good, you know, organizational model or capability model back to your good old enterprise architecture can really help flesh some of these out. And you've heard me say before too these can seem daunting. I would recommend do all of the things you should do a capability model, a process model, a data model, you know, all of that but starting out just workshop it, don't skip it because I've gotten one of our biggest success stories and we can't always replicate this. It was with the university doing a training and we were just doing a data modeling 101 as part of their data governance 101. And just with the sticky notes in a 30 minute what is data modeling? We got to the heart of one of their problems. That was probably the best we've ever done. Can't do that too often but it was just by modeling it out with the people in the class like, oh, that doesn't connect with that. That's the problem, right? So at least started at a high level you don't have to go to level of detail but don't skip these because that's generally when you do that's where MPM goes wrong. Quick case study, this is the cheese this is the cheese incident, sorry to end with that but why did they? So this was a fairly famous restaurant chain known for innovation in their menus. They brought us in, they didn't know what the problem was. Basically was a combination of master data management the product menu, which is their product governance, business process, good old credit matrices. We went and talked to all these people we even went to the chef in the kitchen and he was developing a menu with certain ingredients that didn't get passed on to the people publishing the menu to the people ordering the eggs or whatever the cheese and the supply chain to and we even went to the restaurant and tried to add that piece of cheese to the sandwich, right? And then you could see that the biggest problem with those arrows in between not only did they not have a good product hierarchy but they didn't have the connection between those points and we got all of those people together in kind of a product launch committee and got them looking at that data and it was a big success story. But again, how you count a slice of cheese isn't complicated, it's pretty basic but it's getting it all together with all those pieces that was hard. So I do want to give a little time for questions. So again, hopefully those examples helped they didn't ramble too much to make it uninteresting but again, MDM is all of the above architecture process and governance and when you get that right it really does have a positive impact on the business. So as Shannon goes through the questions just a reminder that if you want to join us next month to go more into that data governance and architecture stay tuned, we'll get into that blatant plug that we do this for living if you want help come find us with your MDM solution and then I will open it up to questions over to you, Shannon. Donna, thank you so much for another great presentation and just to answer the most commonly asked questions just a reminder, I will send a follow-up email by end of day Monday to all registrants with links to the slides and links to the recording of this session along with anything else requested including there was a question that came in Carrie while you're presenting to for your contact details or at least for precisely contact these tales so I'll make sure and get those included in the follow-up email as well if there's anything you want to pop into the chat to Carrie for contact details that would be awesome. Okay, yeah, we'll do. All right, so diving in here so when we say MDM model is it mostly a flat table in some of the cases in some MDM solutions? Why is that so? Good question and then I'll pass it over for Carrie's thoughts. That was hard for me to kind of process too there are definitely hierarchies in master data management think of me kind of a company and then the parent company a lot of that but what you might normalize in kind of your other models or dimensionalized, et cetera you're really trying you're trying to get that single version of here's my name and my email and if there's two emails you probably do want to flatten it out because again, you're kind of pushing back your API to other systems you've already kind of done that third normal form rationalization to get there so they tend to be a bit flat you might need to do the model more of a relational model or dimensional model to get to those answers but generally in the implementation it can be flat for that individual person but then there is often what they call different words for similar things a hierarchy management that might help you show like the parent company with the company itself but Carrie, did you want to add anything? Yeah, it's really situational I think in the inner work solution you are able to create essentially what we call virtual data models which are generally not very flat but then the inner work solution sort of takes care of through other means the normalization of the data exporting the data in the format that you need to get it into etc etc so in general we actually encourage customers to model the data in a way that makes sense from a business perspective and then let the MDM sort of worry about getting it normalized if you need it in a normalized fashion I love it Alright, so should the master data model be broken down into entity relationship model? I think there's kind of touching on a similar case I mean I would agree with Carrie I always would start there I think you get a lot of and I would always start with the business terms the real world business terms is it an account? Is it a customer? Are those different things? Really flesh that out because you're going to get a lot of details maybe in your MDM a lot of MDM solutions have either visual kind of data models or just more of your table level view and that's how they quote model similar to a database so whether the tools of course that are not or as Carrie mentioned you start, I agree you start always start with the data model and then maybe how you implement it might look a little different to kind of push back but yeah I think you definitely need that kind of graphical kind of good old-fashioned data model to start Carrie, thoughts on that? Yeah, no, I agree Thanks, that was perfect Alright, let's see if I can slip in one more question here so why should one catalog a data source for MDM? What is the benefit of having a source system catalog before the MDM solution is implemented? I think and I probably sort of touched on more that source system analysis is super important A, you sort of understand where you're collecting from your golden record you know so is address in 16 different places or is it in one nice clean system which is pretty rare and then as you do that matching which source takes precedence maybe it's by source maybe it's by rules and then it's really important when you if you choose to start pushing back and harmonizing back to the source systems you need to know a whole lot about those source systems the format, the data models you know did we rationalize it to a character and then that stores that as a number you know a lot lots of complexity there but that's a really big part of MDM Yeah for us it's interesting it's in I agree 100% in terms of the importance from a source and understanding the source but for us as well it's understanding the targets as well because you know it's one thing to understand you know where the data is coming from and normalizing and creating a good data model around that but also understanding where the data ends up needing to go as well Do you have the data model that supports the the destinations as well? Yeah I would agree and then where it makes it more complicated sometimes the sources are the targets and all combinations between those right so yeah I think really that source system analysis is super important I love it well that does bring us to the top of the hour thank you both so much for this great presentation and engagement thanks to you precisely for helping to make these webinars happen sponsoring this month's webinar and thanks to all of our attendees who are so engaged in everything we do I just love it I love all the conversation always going on you guys are just amazing thanks everybody hope to see you next month's webinar as well and thanks Donna thanks Carrie hope you all have a great day yeah thank you thank you everybody thank you