 And here we go. Hello and welcome. My name is Shannon Kemp and I'm the chief digital manager of Data Diversity. We would like to thank you for doing the latest installment of the monthly Data Diversity webinar series advanced analytics with William McKnight. Today, William will be discussing new analytic uses of master data management in the enterprise. 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 section or if you'd like to tweet, we encourage you to share our questions via Twitter using hashtag ADV analytics. And if you'd like to chat with us or with each other, we certainly encourage you to do so. Just click the chat icon in the bottom middle for that feature. And just to note the zoom chat defaults to send to just the panelists, but you may absolutely change that to chat with everyone. As always, we will send a follow up email within two business days containing links to the slides, the recording of the session and any additional information requested throughout the webinar. Now let me introduce to our speaker for the series William McKnight. William has advised many of the world's best known organizations, his strategies form the information management plan for leading companies in numerous industries. He's a prolific author and a popular keynote speaker and trainer. He has performed dozens of benchmarks on leading database data lake streaming and data integration products. William is a leading global influencer and data warehousing and master data management, and he leads the night consulting group, which has twice placed on the Incorporated 5000 list. And with that, I will give the floor to William to get today's webinar started hello and welcome. Hello Shannon hello everybody. The FedEx guy just rang my doorbell and my dogs just started barking so hopefully that's team down I was about 20 seconds ago. It is these days. But anyway, I'm really excited to be bringing you this subject matter about master data management in the enterprise and how it can be used maybe differently than how you're using it today. Of course, there's been a lot of discussion over the years about you got your operational and BM and you got analytical and BM but I think analytical and BM has been given the short shrift here and has not really found its way inside of enterprises and I actually spoke to several and BM vendors for this presentation I asked for case studies and things like this because I wanted to bring you the leading edge and not just what I was experiencing in my practice but really not a lot of them contributed. I mean, they gave me case studies and so on they turned me to some of their clients and so on and it was great but that's not the content that I wanted to bring you I wanted to bring you more about my thoughts about where it could go where it has gone. Not that much but where it's going to go in the future, and where you should start thinking about bringing master data management now let me start off with how I think about master data management is it's not a project and sense of it has certainly there's expenses associated to it but there's no direct revenue associated to MDM and I want that in regards to a project I want to finite conclusion and something of high value to the enterprise. Frequently that's money. Now, MDM is great data, although I think it could be doing a lot more within our enterprises and I think too often we make that I kind of called the deal with the devil, put that in quotes, where we we build it for a first use. And we have a hard time breaking it off and and making it useful to other parts of the enterprise so I want to talk about that today just generally kind of where MDM is, and where it can be going I want to get it to our AI applications. Because I think that it has tremendous value there I want to get it out to the edge in our IoT and edge computing environment so that's a big part of where we're going today. This is my obligatory credentials slide I guess somebody thought I was in a good list here. Appreciate that. Enterprise data is right now maybe you've heard me say this before, but Enterprise data is ready when it is all of these things. And this is data, not just master data this is data period. We talk about the data in the enterprise we talk about building it for a given application so on. I'm particularly keen on those structures though that have a lot of leverage within the enterprise so I talk a lot about data warehousing and big data hubs that are really data lakes and I talk about master data management and other forms of data hubs, as opposed to application specific types of structures. And when you put it in these leverageable platforms, it really needs to be all of these things, not just in the, you know, quote unquote data warehouse because what is the data warehouse for example. It's a database where you have data, and hopefully share that data, which really is what makes it data warehouse it's not specifically that you call it a data warehouse if it doesn't meet some criteria. So this applies to that implies to MDM and what we're talking about here today. We want it in a leverageable platform if it's not in a scalable platform that's able to go where it needs to go. Maybe, you know, maybe it can but we're not funding it enough. So that's another form of leverage. This is in an appropriate platform for its profile and usage. And I'm going to make a big, big point today about how MDM beta has its unique characteristics, and that we have today anyway. We have platforms out there for different unique characteristics of data within the enterprise. Certainly data lake is that, for example, is that another end of the spectrum to master data management data. The data lake data is unstructured. It's, it's big. It's, it's happening all the time. MDM is a little more static, smaller, more high quality data. Right. So we wouldn't think that we would master master data in a data lake, for example, hopefully, we might want to put it there. High non-functionals, availability, performance, scalability, stability, durability, and it's secure today. So we can't build it without great high non-functionals. I won't spend a lot of time on that, but there are some markers that you want to have for your MDM program. Data is captured at the most granular level. Okay. I mean, it might be summarized. Sure. Absolutely. Because those summaries are what, you know, we can really make some action about, right? So, you know, lifetime purchases, that's a summary. And that is something that, you know, we can act on, we can classify customers by, for example, and so on. But how do you get there? You get there by somewhere, maybe an MDM, maybe not, probably not actually capturing all the transactions. It depends what you mean by transaction. I mean, I have clients that have customers that might do one or two transactions in a lifetime with them because they're really high fee government types of, you know, purchases. So that actually might be considered master data. Data is at a data quality standard, as defined by data governance. So data governance, I'm really looking at you a lot here today, because I think that it's been set aside too much from actual, how shall I say, actual fire, I guess, within the organization, and allowed her to roam a little bit more than it probably should. Not everywhere, of course, but I want it to be involved in MDM. I want to, I want to see the manifestation of its efforts at capturing rules and defining stewards and business meaning. I want to see the manifestation of that happen somewhere and MDM to me is the logical place for that. And here's a strong quote, I think, projects are a series of subject area master. Yeah. I mean, think about all the projects that you could do within your organization if you had all your subject areas, areas, mastered, according to these bullets. And let's, well, let's really think about it. Here are some bullets of actual applications, modern applications, things that are happening inside of organizations, hopefully you can kind of find your way and in one of these bullets here today but the list goes on and on really. And on the right side, I have some enterprise subject areas, obviously not a finite list, everyone's going to be different. Customer and product are, you know, whatever that means to you are two of the biggest subject areas obviously for master data management, but master data management is an approach to things. It's a database that can store all kinds of subject areas. So once you get good at this approach to things, and what you start doing some of what I'm talking about here today incorporating those analytical attributes, you want to keep going. And you want to keep going through all of these enterprise subject areas. Now I think I have actually just listed good subject areas for master data management and not subject areas like transactions that would probably not fit. But MDM data fits a profiles, not all your transactions it's not, we don't suddenly go from a few gigabytes of master data to oh let's throw transactions in there and now it's terabytes now you have a different platform. We want that platform profile that fits small high quality data whatever small means to you and some organizations, you're going to have upwards of a terabyte maybe of true master data. That seems like a lot. Alright master data is not an option. Yeah, it's not an option, which applications are you working on today is your organization working on today that don't need master data. I would say virtually none of them that none I can think of, they all need it they're going to get it one way or the other. And the quote I tried to put together here for you is you'll need master data, but without a discrete focus on it, you will not get it well. Hopefully you get what I'm trying to say there which is, yeah, you, your applications are going to drag along some master data manager, it's going to get custom from somewhere. They're going to get product from somewhere might as well be you might as well be great master data might as well be data provided as a service from a great place within the organization and appropriate place according to the previous slide. So you could have an application focus, which is a focus on an applications master data needs first now I'm getting a little bit here into some prioritization of master data effort. Now I don't know if I've convinced you that you need master data yet or not but once you get there, you're going to need to prioritize your efforts. It is going is going to be a work effort to get to second 30 center applications. And sometimes, sometimes that means that we stop, we stop at the first application of that master data, because we didn't build it with this thought in mind, we didn't build it Oh, yeah, well we built a customer for CRM but we didn't build it for supply chain, we didn't build it for fraud detection, we didn't build it for marketing. And so it's kind of hard to leverage it at that point so I want us to get past that. I want us to know that if we're building master data for an application that we're building it for the enterprise build to scale enterprise focus. This is obviously a preferred approach focuses on a subject area first. I like it when a client will say we have separate budget for master data. Now take some hard work for that client to get to that point. Not everybody's there and not everybody's there that's actually working on MDM efforts. Okay, you know we'll work around that but it's great to have a discrete budget and focus for master data, something that is interesting to all applications. There is a higher chance of creating new organizational possibilities when you do it this way. There is the danger of build it and they will come anytime you're abstracted from applications. There is that danger so I don't like that danger I would prefer there to be an application subscriber subscriber to MDM, not just provider of data, because that application any good to be providing data to central MDM they don't feel good about that they do feel good if they're getting great master data from you and they don't have to do with themselves. Now, there is a there is a bit of a lag here, you might be built you might build out a great master data management hub but there might be six months before the rest of the organization finally decides okay I'll get my master data from there, because the concepts take a while to change, just know if you're in that, if you're in that six month period that it will end if you stick to it. Either the initial focus needs a secondary focus on the other either initial okay let me say right, either initial focus needs a secondary focus on the other in other words, if you start with an enterprise focus, you have to have an application focus like I just mentioned, but if you start with an application focus, you have to have that enterprise focus as well or you won't get it past the first application. So that's the MDM leadership challenge and hopefully by making you aware of that, it helps you to overcome. So there's my statement again, I guess it's worth saying again you'll need master data, but without a discrete focus on it you will not get it well do it with data specialist. This is data modeling. This is data integration. This is data quality. These are things that data warehouse professionals for example, have been doing for quite a while so they make some natural transitions into MDM although there is some danger in that. Use a tool. Yeah, use a tool. Now there are times, there have been times when I've looked at a client situation in a consulting environment I said, you're just not ready for MDM yet. All you need to do here is blah, blah, blah. But, but let's let's let's kick off MDM in the correct way, because you know it's not going to meet your timeframe but let's kick it off in the correct way so that we can transition what you're doing now to MDM, and we can ramp that up for all future efforts. There's never a time I haven't encountered an enterprise where I say, no MDM here. And by the way, if you're if you're saying MDM your these days you're, you're saying a tool now. You might say well what if we get the wrong tool yeah, you could be, you could be have bought yourself a problem there if you get the wrong tool for you. There are different kinds of tools this isn't the tool comparison presentation, but yeah you'll want to walk that line a little bit. It's operational and it's real time yeah operational. MDM should be operational MDM should be real time data, it just should be built that way. Let the hub, which is the database right create the analytical and the empowering elements I like to say empowering. But I'm referring to analytical elements. And so if you need analytical elements in your environment anywhere. Why not MDM. So we like to create it in MDM. Of course I you know I encounter a lot of clients that don't have enough analytical attributes anywhere within their organization. So maybe they have it someplace but it's in some jailhouse CRM system where it's never going to come out and by the way the way that the way the analytical attributes were created there, kind of fishy. So, you know, we want to do it right so if we're doing an MDM project. We want to do the analytical attributes with that as well and I'll develop that as we go along here make it a discrete project with a lot of touch points with applications, maybe a weekly touch base between the MDM project and the project that's going to be a subscriber, and that becomes practically daily when you get really into it. Focus on the total cost of ownership first for justification you want to justify MDM, as I have dozens of times, I would say 90% of the time I end up with a, it's a total cost of ownership play. In other words, it's going to cost you less you're going to do this anyway, like I said before, you're going to do this anyway but you might as well do it once you're right, build it to scale, create that data as a service, and you de risk. You can do scope applications by doing that, and you can get things to market a lot quicker which obviously brings some ROI with it as well. Build it to scale doesn't take much longer to consider all known requirements. I wonder, I want to interview when I'm building customer for example customer MDM, I want to interview all the, you know, potential stakeholders of that subject area, the ones I'm building for to be subscribers now, and the ones that will be subscribers later next year, two years from now three years from now, and I just know I mean we just know right, think about, you know who's going to need this down the line. What are their requirements now you're not going to get them all, you're not going to get them all you're going to get, you're going to get some maybe nothing out of some of them but you've planted the seat, and that's really important. That's not what you can to get all known requirements all known requirements, not the unknown. I'm not saying hold out for months and months and quarters and quarters, until you get all requirements forever by the way at the end of that cycle. They've changed the real decision points in MDM we're going to come around road mapping around these things the roadmap is a big decision point. Yeah, who's going to sponsor. It just comes down to when you're ready when this when the potential sponsor is ready. Reaching back and making the big question. It's kind of like when you asked people out on dates when you did that or now as you're doing that right you eventually you have to bring the question out right so will you sponsor me will you sponsor this project will you sponsor customer will you sponsor product will you will you sponsor it. So yeah you want to get there. There's a, there's a, I always say that there's a timeframe once you kind of begun that process to win. It's time to move on and find a different potential sponsor if somebody's not stepping out. You've got to have a lot of patience around that to the subject area, which subject area goes first, which comes next. There's no prescribed. It must be this way it must customer first or product first it depends on a few different things. And I'm going to get to that in a minute. So we'll, I'll help you, I'll help you prioritize I'll help you roadmap your MDM help you think about it. Don't forget road mapping around publishers or workflow don't forget third party date. Okay. Third party data. That's a huge source of master data. Most of that I mean, most of that is master data. It's just profile information about customers products, etc, etc geographies. Currencies what have you. I know I'm kind of delving into reference data levels of master data but you know that's still master data. So don't forget about that third party data and that it is master data and the MDM hub the MDM program should encompass most of that data as well. The subscribers. These are the important customers, if you will have the MDM hub the AI applications now that you're all building right. The applications that you're converting from whatever they do now to AI. Yeah, those. Those are subscribers, we're road mapping around their timelines as well this is a bit of an art it's a bit of a science as well. Don't forget about Carmen common artifacts like the data warehouse, the data lake and operational hubs and databases and so on. The data warehouse needs MDM data, the data lake needs MDM data. Now, very common it's very common inside of organizations for the data warehouse to already have its own subject areas right to already have built its own quote unquote master data. These are the dimensions of the fact tables. Okay, for those of you that follow along to that kind of modeling discussion. So let's bring along MDM. It is is not wise at that point to develop it in MDM and then not update the data warehouse so you have one right the data warehouse should become a subscriber to the great MDM data that is one it's more recent. You know, you've put a lot of good emphasis into that data to make it meet all of the seven bullet points that I had before. Right. So it's truly master data. And that's much better operationally speaking, then a data warehouse is communications road mapping around communications. You're going to be telling people how what this means to them, what this means to them so you're building the customer master data. Okay, let's say, what does this mean to this that application over there that you know we hardly ever talked to but we know they use customer right. We want to get them into the fold into the family if you will we want to understand what they need from customer, which I already discussed. We want, we want them to understand that we are building this for them as well maybe not for tomorrow, but down the road, and there is a time lag there again. So you have to start planting your seeds if you want a real program here. And that's where the MDM value really kicks in when you have a real program to it. So here's a sample road mapping around data governance and stewardship efforts, which is one of the first things that we shore up when we do MDM we want to be sure that that's in place to the degree necessary to do all the wonderful things we want to do inside of MDM. So here's a sample roadmap. All right. Now, how do you pick your targets I got customer first here right. So there are three criteria for choosing. So what we want to do, we like easy. We like easy to get, get the thing going right. We want to know what is prerequisites for other things so the customers have to come before product for example, do products have to come before suppliers that may be true and most organizations for example so that dictates some things. And finally, the most important thing is business impact business impact. Remember the schedule that we looked at before right. We're looking at everybody schedules and who needs what when and where, and, and we are using that very much again, art and science going on here. I like to build out a subject area and when I see that we are doing this well. I like to jump to the next subject area maybe ramp up another scrum team and start with that. I would kind of hold your horses on trying to do multiple subject areas from the outset, because you want to develop one great way of doing things within the organization and then rinse and repeat. And you can't rinse and repeat if you haven't done it well. And you're going to learn some lessons in that first one you are. You're going to learn what works in your environment what doesn't how long things take. Who's on board who's not who needs to be short up a little bit in that regard and so on. Now you can do this by organizing it around a subject area, or you can organize it around a subscriber I don't like to do it that way but sometimes I have to. Now what this means is like let's say you're doing SAP you're doing mbm for SAP it needs some things from customer needs some things from product some things from supplier and on and on right. When you build that stuff, all collectively MDM master data that is in the MDM hub and you make it. You make the big old push to SAP great. Okay, so you've satisfied, if you will, at least for now, the SAP group that subscriber alright move on to the next. So that's another way that you could phase this out. And by the way, as I say this, and I show you customer might take. What am I showing here. Two and a half quarters all right of work that's over half a year, maybe six seven eight months all right. That's that's about kind of where I want to draw the line if things take longer than that to get to production I don't want to. I don't want to do I want to want to sharpen the pencil a little bit around that maybe customers too big for you too big. A subject area it doesn't work for you. Maybe you have to divide that up maybe there's domestic customer and then international customer and so on. So, how long for a subject area. Yeah, that comes into play too. So again, art and science. This slide is a little bit of an interjection on my part because I kind of know what you're thinking at this point. Because what right okay this has nothing to do with the attributes we're putting in there the analytic analytics, you know who's subscribing to the data and so on but it's very important, it's going to help you get there right. Remember we're creating data as a service. Who's going to who's going to how far does the build team go. And these are the questions you have to ask yourself about how far the core build team for MDM goes, I've done it both ways. And most organizations are not taking to this level or maybe there's some assumptions going on. We know about assumptions right. There may be assumptions going on from the application teams about who's going to do what. And by the way, some application teams are thinking yeah we're going to do it. And some applications teams are thinking oh good that that MDM teams going to do it. What is it build an SLA for the master data, MDM communication and center of excellence where's that going to reside. And this is a big one who's going to do the integration. Let's say MDM creates this great customer subject area, who is it the MDM team or is it the application team. For the subscriber, you know who is going to actually port that data into the subscribing systems and I'm not here to say there's one right and one wrong way. It depends. I suppose if I have my preference and nobody stepping up and it's it, you know, nothing's obvious. I would say the MDM team but but everyone's going to be a little different in that regard and that's okay. Figure it out. The hub model and the rule expansion how far do you go. Remember I said earlier you want to get all the known requirements but that's, I might look at and say we got all the known requirements you might look at and go we don't have them all yet. So when when you draw that line and really start to build, start to build your model. I go through this a lot in in our implementations. When do we draw the line and stop and move on. Well, you know, hopefully you're you're targeting something and so that plays in as well right. Who's going to map the elements from the hub is the subscriber as I just mentioned. Who's going to customize of elements and data quality rules for the subscriber. And remember, as much as you try to cover all your basis. Initially, every new integration every new subscriber will have some additional work. You can't just say you can't just create a project plan for a project that just has like one day okay we'll get our master data. Nobody's like that it's going to take some time regardless. Okay, you are including empowering attributes. So there are core in my view, there are core attributes and then there they are there are the empowering analytical attributes. For example, last channel used last visit date, most use channel ID lifetime value lifetime transactions and so on. Like the net promoter score in retail and whatever the equivalent of that is in your industry segment what segment is this customer and are they new, are they gold plated or they the silver, are they, are we worried about them a trading things like that what categories do they always have they purchased from. What is their propensity to turn. What is their propensity to buy another product product X product what is their propensity around social. Can they be an asset, or detriment to us there or don't they do that. These are things a lot of some of them are you know fueled by third party data okay. We explore that marketplace but a lot of them come from within your organization. How do we know the lifetime for example the lifetime spend right, we got to look at every transaction. Okay, so in absence of that within an environment. Already we're going to come up with this list of empowering attributes, and we're going to figure out how we're going to do that within mbm. I'm saying mbm should be storing transaction data. Don't get me wrong I'm saying mbm should glean, or otherwise get all of the analytical value out of transactions. So does that mean you feed your transactions to mbm. Yeah, probably, probably that's okay. That's okay again we're not storing it we're going to keep a small database, but it's going to be high quality, high quality stuff like what you're doing here in health care, we might be talking about conditions. The table stakes are core where we're all doing that right, but where you really get to exponential value from your mbm program is in these empowering attributes. And that's what I want you to think about now to be clear what I'm talking about when it comes to mbm. Put it right in there. Whoops, one too far is there's a hub it's a database. It's a database. It works with the catalog it works with the data warehouse it works with other things this is just sort of the basic architecture of things right. There's all these sources d 365 might be for example dynamics 365. This is obviously an Azure looking kind of diagram but you know whatever the data comes into the hub. It goes out to everywhere that needs it, all the data consumers and so on I, I didn't draw all the arrows, but a lot of the master data management hub data is going to go right back to the left side, all to all those data sources, they become sources and targets, maybe they're a source for customer information, but they're a target for product information for example very normal. They're the source of master data. So for example, in here just kind of fill it out the mbm metadata is published to the data catalog. The data catalog is populated with lineage information from the Azure data factory, and the m can leverage the data catalog to display the glossary and lineage information. mdm auto publishes the master data to the dimensional data stores that's in the data warehouse and other places, and you have the ability to view metadata and the data lineage across the entire data life cycle and that's kind of what we're striving for. Now remember this about mdm data. It's relatively small it's not big data. If you're thinking it's terabytes and terabytes and, and something like that, you might want to rethink it because we're going to put a database in place. That's high spec and high quality, but it's not going to be really geared for that level of data and I'm only speaking of volume really it's the criticality of the data that we need to talk about the criticality is high. It's nimble data. It's suitable for the edge where we can only put a limited amount of data. The edge we used to put no data we use then we started putting just some flat file data. And then we started putting database data, like mdm data. Well we're not thinking too much about mdm data on the edge but I am, and I think you should be too. Now we're thinking not just basic processing at the edge we're thinking AI at the edge. That's so empowering for so many of the applications that you're working on mdm data should be accessible. It should be shareable should be high quality. The hub is a touchstone for the organization. And an organization says, Well where's the great customer data that I can count on. Where's the great product data that I can count on. I want it to be the mdm hub. That's your touchstone. And it's a touchstone for pushing that data out everywhere. And I'm going to put in something here that we're not thinking enough about and that's to the data lake to the data lake. So many of us have data lakes that have kind of hodgepodge master data we didn't think we needed it there. We thought we would a just have all transactional type data in there all these sensor data. That type of data in there all the big data clickstream whatever what have you. Well we're virtualize that to the mdm hub which I get that I get that that might work, but you might physically want to push that data out into the data lake as well your data scientists that are working out there will thank you for it. And mdm data eliminates point to point. So very distinguished from big data and there's and secondly I want to say there's no great wall of China around this data. This data was meant to be used. And so if you have that you need to get rid of it. Now what are you what are companies out there doing with mdm circa 2021 as last year right customer duplication name business matching customer profiling for marketing or operations product catalogs supply chain management, some level of that. The internal asset management network management identity management that's those sorts of things. These are the big uses for mdm circa 2021. I think it's great. I think it's it's foundational. I think these these are absolutely where mdm knocked it out of the park and continues to knock it out of the park, but we're going to build on that. Let's just let me build on this a little bit more supply chain management. That's a big one for me deliveries shipments carriers transport modes material sites. Don't those sound like excellent subject areas that if they were mastered boy when supply chain management be a lot easier be a lot more effective. A lot of money. Yeah, network management, your application applications, your services, your VMs your data centers your routers your switches, your fabrics, all of these things, if they were managed, your network management would be at another level. But where are we going with this. In the future we're going to add those analytical or empowering attributes to the model that I showed you before calculate those attributes and mdm that's okay. That's okay. We're going to add subscribers remember I said at the beginning. mdm data does nothing in and of itself it has to be used with an application. Now there's a lot of applications on your data lake right by definition a data lake is shared. By definition a data lake is not sitting there working for one application. It's leverageable. So all of those applications whatever they may be for you for detection. Maybe you're doing some customer management in there. Maybe you're monitoring your sensors for something. So what those applications are they can have added value if they have mdm data edge. Same thing. Same thing as I mentioned a little bit about before. So I think just generally mdm needs more attention in the organization these ideas will begin to grow. These ideas will begin to drive some ROI. Remember this is analytical. Remember, I brought you in today to talk, talk about the value of these analytical attributes, most of the mdm futures, beyond those basics that I talked about is going to going into the application, excuse me the analytical area. So if you're in your if you're an mdm professional, your customers are those applications and those application budgets are largely fixed and they don't consider mdm today. So we have to make the awareness create the awareness. How can you data governance to help create the awareness of these leverageable assets. I hope data governance you feel good about your mdm program there, and your mdm hub and data governance if you're sitting there and you're not creating an mdm program why not. Why not let it let it grow out of that because the goals of data governance and the goals of mdm. They overlap quite a bit. Speaking of overlap. There's an elephant in the room. Many places, and that elephant looks something like we have CRM don't we. Yeah, there's some overlap there. There's some overlap there. Now, but it's not full overlap. Okay, CRM is not meant to be a leverageable data store for master data it's not meant to be the place where master data gets integrated into applications from. Not at all. But there may be some value within CRM inside of your organization to the goals of mdm which are different. Now, I always want to know about CRM when I'm doing mdm. What does it do. How mature is it. Is it doing analytics. What are the analytical attributes that are stored in CRM, and I learned a lot there and you know can they be trusted. And if it's yes and yes, then, well we just want to push of those attributes in mdm like I said before give us your analytical. Give us your hard masses give us your analytical attributes okay, wherever they may may come from CRM or otherwise. We're agnostic, we just want, we just want the gold, we want the good, good data and if it's already created somewhere great. But if it isn't created somewhere mdm certainly can do that. And I do lean that way in environments where I have the choice. These are some sample applications that are improved with mdm. We have, we have different industries here trying to connect with a lot of you specifically here I won't read all this but we have some subject areas that are of high importance today to those industries. We have some applications, and we have some bottom line objectives with mdm the fourth column goes deeper than the third column here. I'm going to now discuss some of those objectives. Some of the objectives that you see here for the various industries. Let's discuss them in a little more detail customer fraud let's start there. Now, I'm going to use this kind of framework to discuss customer fraud, you got some things on the left but on the right I'm showing you all of the data, those enterprise data domains that I had up earlier, and I circled a few. The ones that that you need mastered in order to do great customer fraud detection. All right, and by the way, let me just take a quick aside and say, this is how you do your mdm roadmap, you do this for all of the applications that are in focus for the next year or two, or three or four depends on your organization how far out ahead you're looking. You do this and that helps you determine what's priority to do inside the enterprise inside the mdm program so there you go. I've gone pretty light I think on connections here. I don't want to scare anybody right by circling everything for customer fraud detection, but truly advanced customer fraud detection gets into more than what I have circled, especially when you get into artificial intelligence customer fraud detection. Now, I'm saying customer fraud there are other kinds of fraud, this largely applies there as well, including false invoicing CEO fraud, business email compromise. All of these are being carried out through social engineering rather than high tech hacking, and also third party data is very interesting to customer fraud detection there are other entities out there that focus on risk management. Okay, so most fraud detection today is transaction heavy. It's just looking at the transaction saying, this is transaction makes sense. Now, now that's going to capture a good amount of customer fraud and that's why customer fraud is, it's at an all time low, because we're doing a great job with this. However, it's still there. And it's, when I say it's at an all time low I mean on a percentage basis, there's still a lot of dollars and I won't get into it but a lot of dollars that are being lost by organizations it's very worth it for all organizations that deal in this kind of arena to do customer fraud detection and they all are it's just, are they doing it well, are they doing it with artificial intelligence, are they doing it with master data, or do, or is the data kind of suspect well the data suspect so will be the fraud detection. We want to sync MDM out to the edge because that's where we can process a lot of what's happening in our environment, right. I talked a little bit before about edge computing edge, edge computing is is highly facilitated by the use of specific types of CPUs by the way. And there's a whole host of companies that are building these types of CPUs this is these are the CPUs you want of the edge. Anyway, customer attributes to include the last in transactions. Keep those transactions in there, but you say, but you say there's many transactions per customer. I thought MDM data was one to one customer has an a primary address, a customer has a primary contact, blah blah blah a you know one. Not not so in MDM data you can have as you can do whatever you want, really. And again, without getting crazy in terms of volume but having the last five transactions there and depends on what your concept is what transaction means but I mentioned before I have a client that usually does one transaction with their customers so yeah have that in there what the heck. But you know, last whatever that's going to feed into the into your algorithms, average high low transaction profiles wouldn't that be nice. Wouldn't that be nice to consider when you're looking at whether something is fraud or not in real time. Right, you want to get it right in real time. You can always deny transactions and wait and look at things in batch. Right. But that's not good. What about the customer state the state that customers in. Are they, are they, you know, hot and heavy about your company right now they done some some negative social media have they been complaining to the call center etc etc. You know that may factor in customers financial profile, which you may not know. You may not know completely this is where third party data might come into play. Right, but of course there's whatever you got as well that might be interesting to MDM. I'm trying to make MDM at the edge facilitate customer fraud detection here. What about real time recommendations, I guess it's kind of similar right where in fraud detection we're recommending whether we're taking the transaction or not but real time recommendations is more, more positive I guess we'll get more positive here and talk about you know what we should be pushing next to our customers out there in real time. We wanted to be real time and relevant. We want to combine customer demographics, the purchase history and the activity and match historical and session data. We want probabilistic models which aid in understanding in the conversational shopping scenario, accuracy in the scope increases with data. So the more data you can bring to bear the more quality data you can bring to bear, the better it should be. Now, when I say the more the merrier here. I don't mean, oh, gosh, we got to bring all the transactions to bear and analyze them all in in real time that's going to take a while. And you know the customer is going to click away and blah blah blah. No, I'm not talking about that I'm talking about you've done your homework you've done your work in the background, there will come a day. And it's not too far off where all the summary of data that I'm talking about it won't be necessary. Because because the processing will be fast enough to pour through terabytes to petabytes in real time and come up with up to the minute up to the second. So customer profile recommendations, fraud detection, all this sort of thing we're not there today. We're not quite there and we can't wait for something like this this is an absolute necessity for any kind of business to have great real time recommendations so when I say accurate accuracy and scope increases with data, I mean with high quality data. Here's another area that MDM is going to go into. And again, it's based upon having mastery of certain subject areas, trading partners, creditors, customers, companies. If you have that mastered your, the application part of this is light. If you have it mastered for, if you have the right subject areas mastered per my definition earlier. The application component is going to be light. And I know you're thinking, well, no, no, no, you're anti-munder learning is complicated. Yeah, of course, I get I get what you're where you're going there, but look at the subject areas that I have before you. And what if they were developed to a low granularity, high quality up to the minute, you know, high quality data there if that was made available in real time. That would go a long way. I'll just put it that way schemes are sophisticated now there's no more when it comes to, I shouldn't say no more but there's there's not a lot of the old school bank robberies, you know, when it comes to financial fraud, you know, where the robber comes in the bank with the bandana over their, their eyeballs with the eye holes cut out and says stick them up, maybe with the finger in the pocket, you know, like this, or maybe a real gun, whatever. But there's not a lot of that and more so much more sophisticated. There is smurfing activity now which is huge this is splitting large sums of illicit funds to a hidden network of beneficiaries. Can you smoke that out. If you're in the financial industry, can you smoke that out today don't you need some data to help with that. That company questions that you might answer if you have great master data do you know the owners company and the partners. Are they in high risk geographies. You know, if you had that kind of information your master did that would factor in creditors. Are they associated with companies where you have little to no information are they in a high risk geography themselves. These are just some other questions that would come to bear on an anti money money laundering application now we're not all doing this, but hopefully you can kind of find your way and see how I'm thinking about applications. I'll talk about supply chain manager. So here again, here again I have a bunch of subject areas, all appropriate for master data in some way shape or full. Next level supply chain management what you know we should be working on can take months, not years, if these subjects are mastered. So, for stuff like geography, I have you developed that what I what I hate to see is a lightly developed subject area in master data management, and then each application has to build on top of that and they they of course build it inside of MDM so nobody else is ever going to get the value of that. And they had to correct a lot of the wrongs that are inside of MDM some of which the MDM team knows and they just don't have time to deal with and some of the, some of which the MDM team doesn't even know that. And that's kind of a shame when that's the case that's very inefficient. So, again open communications helps a lot with this stuff right. So, for an example, supply chain management breakdown breakdown is you're distributing network resources to meet the demand. You're doing route planning for time and transport costs customer management to keep them coming back risk analysis of potential accidents and extraordinary events, which may factor into the supply chain right. So, innovations and asset purchases distribution centers and warehouse management for proper allocation of capacity and available space. So you learn from your network as you go and that's great supply chain management there it doesn't just optimize what you have. It improves upon what you have. It's all based on great master data so I've given you some ideas here today hopefully about some analytical uses of master data management in the enterprise. I've talked about plotting your, your route of master data through the enterprise over time, the sooner the better that you get started on that. And the more, the more broad thinking I guess that you are when you do that, the better. So where do you look for MDM opportunities I've given you some examples. But you can look at the products that you make and the services that you offer the supply chain for those products and services, the business operations. The intelligence used in designing your product and service set. What do they look at what, what are they using is that master data. And the intelligence used in the marketing or approval funnel for your products and services so the approval funnel as well what kind of master data might be interesting there. And that brings me to the end of the formal part of the presentation if you have any questions. I will take them now back over to you Shannon. William, thank you so much as always 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 for this webinar with links to the slides and links to the recording along with anything else requested to everybody. So diving into the questions here William lots of good ones coming in, you know, for data warehouse and data lakes do you suggest to use APIs to get MDM data for example customer attributes like name, etc, or store copy locally in the warehouse and constantly refresh example what if APIs are down I still need the customer attributes available those Dale. Yeah I mean that's that's a great question. I like API is I like the use of API is wherever possible within the organization. I think that's great, but you can't. You can't overlook the value of physically having the data where it's going to be used. I get the virtualization I get the API's and all that but I think if there's going to be high use you have to make this this call with every integration, every piece of integration you have to make this great judgment call this is why you need some great experience there. Some great data architecture there inside of the enterprise helping with these types of important decisions because there's so many different ways to integrate data so many different ways to skin that cat but I'm going to say most of the time I tell you what I do is actually physically push the data through data integration to the data warehouse to the data lake to really almost everywhere that that needs it. And, and by the way API is not mutually exclusive with this approach right. It's always great to pull that data via an API and actually physically move the data as a result. I love it so should data harmonization golden record pushback to source system which is tricky is a must to have use case and MDM solution. Yeah, we get into architecture there yeah absolutely. And it is tricky, as was mentioned but sometimes the, you know, the data, the hub the master data hub becomes sort of an information factory right. It's going to with that's where we're going to push data, churn the data do whatever we need to do with it I'm doing one, one, you know implementation right now where the MDM deduplication, the implementation features within MDM are, that's what's important, and that's, that's what MDM is doing to the data and then pushing it back where it came from. So, yeah, absolutely if there's value there if there's priority there to do that to have that great data there. Absolutely so the warehouse or excuse me, the master data hub, and all the master data models kind of become an extension of that of that data set right because it's going to provide a function to the data set, the data is going to go back, it's going to be cleansed, then it, then it can hopefully go on to greater uses so absolutely. What is the difference between conceptual data model and data domain model are they the same. Practically they are the same. Now you might find some, you know, curious from Dana or whatever that might contradict me on that but from a, I'm down at the project level right we're doing projects and I'm not just I'm not drawing to find a line between those things and somebody gives me a great conceptual data model. And that's in those blocks. Those those spokes I guess of that model are subject areas, hopefully, and hopefully they are also subject areas that I can master within MDM and I can do so within that kind of six month window again getting back to what I said before that if it's going to take us to master it. And according to my my definitions, then I believe that you need to break out that subject area. If it's going to be, if I'm going to have a complex web of data stewards for the quote unquote subject area, then you need to break that up and make it more simple I'm not saying I'm one day to steward per subject area that might be stretching it a bit for a lot of organizations maybe it's a small department. Okay, but it can't be 10 departments, you know that are going to weigh in on every single decision right so if that's the case you got to break it down even more so I like a good either one conceptual data model subject area model as a, as a one of the early projects that I'm going to do in a, in an MDM program and it shouldn't take all day. You should, you should be able to pound that out in in half a day. And that's it move on. I love it. I think we have time for at least one more question here. Is it necessary to have sub domains under domains aren't domains good enough. Is there a strong rationale to have some domains. I mean, I would, getting back to my previous answer, you might find a use for sub domains where the domain is just too big to be actionable. And in that case, you might have sub domains but really then we're talking that the sub domain in that context is going to be the level that we're actually going to work with inside of a MDM roadmap. That's what I care about. That's what we all should care about. That's the actual part of this. So, you know, domains and sub domains that may factor into your data steward strategy, right, because you might have different levels of stewards and you know each organization is going to be a little different in that regard so yeah I definitely want to go with it make sure I get great data stewardship make sure I get great data governance, great program management and so on, a program governance if you will. And that may lead me to using terms like domains and sub domains but I tend to try to keep it simple at least at the outset and just say, here's some subject areas, let's work on them. And I can slip in one more here. Would you address ESG data management within MDM thoughts with regards to challenges and are having reasonable expectations with respect to establishing the framework versus achieving threshold. What was that first word you said Shannon what kind of data ESG so environmental social governance. Yes, I mean it fits the mold, it fits the mold of master data. Absolutely. I haven't had an opportunity I guess to call it out as such, but I do believe that it fits the mold of MDM and should be treated like MDM. Again, it's kind of a form of reference data right and talked a little bit about that as being just a, just an easier form of a master data management subject or maybe one that we don't have to have a steward for maybe one that's very very static, maybe one that the only update that we do is we put on a very light workflow panel, I guess, on MDM where that data can can be updated again, we're going to keep, we're going to keep all all history of data that ever happened inside of MDM so that keeps us, you know, moving forward and being able to look in the past and so on. I think ESG data fits that mold. So yeah. William again thank you so much as always for another fantastic presentation, but I'm afraid that is all the time that we have for today. Thanks to all the attendees for being so engaged in everything we do I just love so many familiar faces out there are familiar names. It's been great. You guys are the best. And that reminder I was going to follow up email by end of day Monday with links to the slides and the recording of this session. So thanks everybody. Hope you all have a great day. Thanks, William. Thank you.