 Hello and welcome. My name is Shannon Kemp and I'm the Chief Digital Manager of DataVercity. We'd like to thank you for joining the latest installment of the DataVercity Webinar Series, Data Insights and Analytics brought to you in partnership with First San Francisco partners. Today, Kelly O'Neill and Joe Mildley will discuss data-centric analytics and understanding the full data supply chain. Just a couple of points to get us started. Due to a large number of people that attend these sessions, you will be muted during the webinar. For questions, we will be collecting them via the Q&A in the bottom right-hand corner of your screen. Or if you'd like to tweet, we encourage you to share highlights or questions via Twitter using hashtag DI Analytics. As always, we will send a follow-up email within two business days containing links to the slides, the recording of this session, and additional information requested throughout the webinar. Now let me introduce two of our speakers for today. Joan is a Business Technology Thought Leader and Recognized Enterprise Information Management Authority. His 30 years of experience including planning, project management, implementation information systems, and improving IT functions, Joan writes and speaks on a variety of topics that enjoys sharing his expertise on strategic planning, data governance, and practical technology applications that solve business problems. Kelly O'Neill is the founder and CEO of First San Francisco Partners, an information management consulting firm. She is a veteran industry leader, speaker, author, and trainer. Kelly is passionate about helping companies leverage the value of data, empowering them to derive insights that inform decision making and improve results. And with that, I will turn it over to John and Kelly to get today's webinar started. Hello and welcome. Hi there. Welcome, everyone. Hello. It just meant getting you there, John. I am here. I'm here. Excellent. I am ready to go. Fantastic. Well, today we're going to talk about data centric analytics. You know, you might have, for those of you in the audience, you might have heard us speak about the data centric development life cycle in the past and how to pull data to the forefront of your development life cycles. In fact, I think John actually presented on that topic. I was recently hearing about you. But today we're going to talk specifically about data centric analytics and how to leverage the concept of a data supply chain to ensure that your product actually provides you the results that you're seeking as you think through that concept of an analytics life cycle. So I love this topic. And part of the reason is because of the analogy to the supply chain and looking at practices from a supply chain perspective can really help us consider ways in which we can think about quality assurance and some of the techniques that help product organizations optimize their materials and product life cycle management. So for today's webinar, we're going to talk about that data supply chain and what is a data supply chain, how it impacts the analytics. And then we'll go into some of those design considerations, again, leveraging the thought process of a supply chain environment. So hopefully some of you on the phone are within supply chain companies and that you'll really appreciate this analogy that we're working on today. And with that, I'm actually going to turn some of the slides over to John based on his experience in supply chain businesses and some of the manufacturing experience that he's had to help articulate that analogy that we've got. So John, why don't you go ahead and start with some of this background information. I will do. Thank you very much, Kelly. So here's a couple of examples we found and we have some sources cited there that you can actually go through and find lots more examples. An insurance company doing their data science thing and they've got a predictor that they thought was really amazing that they could help say that this person was thinking of canceling their policy and we could market directly to them and they did this analysis and sent lots of e-mails out to these folks to get them to extend or renew and it turned out the indicator was actually a cancellation indicator and they were actually telling people to renew something they had canceled which was rubbing salt in the wood. A real estate A-model was a corrupted because it was deemed unuseful because there was an error in there that only one record in a million but you might have a magnitude of a thousand now you might say well that's a lot but in real estate when you're dealing with millions of transactions that can range from a few thousand dollars to hundreds of millions of dollars you have no reasonable range check available to you and the model was unable to support that because there had been no reasonableness applied during the processing of all this data. In the healthcare business almost everything is affected by how the electronic health record is built now and any omission, any change in that can skew healthcare results and healthcare analytics drastically. This is a serious problem because we're beginning to use conclusion from analytic models and AI and via machine learning for diagnosis support and you don't have to be bright-eyed and bushy-tailed and at the top of your game to realize that that could be problems with the patient. We all know that we never get our email right or an address right and that's because at any one time 20 to 20% of all emails and addresses are absolutely wrong because you all are moving around and it's hard to draw a bead on that. There's lots of examples of what can go with data that will affect your results, right? There's a website that I like to just pop into once in a while towards datascience.com, it's pretty sophisticated but every so often there are some real gems on that website for things that can drive your analytics off the rails. So this metaphor of a supply chain is really very powerful. We're talking about engineering your data movement to support the consumer of that data. A data scientist can be very proud of what they do and they can dampen out data issues through statistical methods but at the end of the day there are very few data scientists that will tell you they really enjoy spending all this time recrafting and repositioning and staging data to make it useful for their model. So here's a way to do it that the entire organization can benefit from and it is a powerful engineering based metaphor so it makes it easier for you to sell and understand how to do it. So with that we will go on and actually talk about some data supply chains. So what is it exactly? Well, as I said it's a metaphor so the best way to talk about it is what is it a metaphor to? Well it's the regular supply chain which is the coordination of material, the sourcing and assembling and the movement and stuff so that you can deliver goods or services to a customer and if I was making a washing machine or a car or any hard goods I have steel and aluminum and that's my raw material but that has to be managed in some way. We have the parts, we have other parts we would acquire, we might not build our motors, we might acquire those from somebody and then we're going to fabricate our raw materials and then we go through some type of sequencing and processing here to assemble things and then there's the distribution part of the supply chain which is how does the consumer get it or where do we store it or position it so that it can't be acquired at another time. We're pretty much all familiar with this. Well the data supply chain does something very similar and we all do this now. Everyone, whether you think you have an elegant ETL and data movement or you're populating your data lake with some sophisticated tools everyone from in any organization for profit, non-for profit government, non-government does this now. You have a data supply chain so we're not talking about building anything new we're talking about understanding what you have and making it work better. So for my data I have internal databases and data that I might derive or treat or update along the way. I can also acquire raw materials. I can get a file that might be the similar of a component part not the thing I make but I need it. I can clean and standardize it. I can ask my fabrication step there. Then as I do my assembly I might put a sandbox out there and I will develop and run my models and that gives me my product but there's the distribution or what we would call data accessing or publish and subscribe type things where folks can use it, visualize it or we might want to monetize our data. We would want to sell the results of that. So that's the full metaphor explained. Kelly, any comments or questions on that before I go to head? Any additional thoughts? I think that the way to be thinking about the part that this data supply chain is as you said it's kind of a model and it's an analogy. It's a way to think about how we look at the process as the data moves around our organization to really consider what quality means at different points and what analytics means at different points. Anyway, just a way that you consider that and also you can consider how you can leverage some of the best practices and optimization that your company may strive for within your supply chain to talk about how you would do something similar in your data supply chain to ensure that your analytics have the same amount of attention as possibly the product creation process within your supply chain. Yeah, we're going to talk about this a little more detail in a few more slides but if you have in mind the entire time you're building your data lake for analytics that you are going, even if you're not going to officially monetize your data if your mindset is I'm going to sell this someone external is going to scrutinize me because of this you're going to have a much better result. So let's just talk about why this is important. Try to imagine something without this metaphor and we have this. We have this now when someone says yes we have operational systems and we do things with our data then we go into the data lake and we do some stuff and the models aren't right. Well, it's because you haven't put some discipline on this and it's that simple. So I have my factory and I've been fortunate or unfortunate it depends on what you like. I always was very energized by my work in manufacturing but there's a parts and tools crib or cage and in that cage everything is very, very well managed. Excuse me here. So if I am one of the workers on the floor and I go to the cage and ask for a tool or a bolt or a fastener they will go get it and inventory will be decremented and they know right where to get where to get all of that. That's because there's a lot of policy. There's a lot of lean management and thoughts have gone into that. There's strong guidance. There's strong policies around that type of thing. There is an inventory control system and there's an item master. Well, what we talk about a lot on our conferences here and our webinars are metadata and data governance. Your inventory control system and your item master or your metadata and your data governance. So your data, imagine it's in a crib and I want to go get it and I need to know right where to go to get it. And that's an inventory control system. That's exactly how an inventory control system works. I heard an intake of error. Exactly. Yes, that's right. And so with some of that kind of inventory control system so how does a manufacturing or organization ensure that they understand where that part ends up going? Do they validate who takes it out of the cage or what is that tracking process? Well, yeah, that's right. The way it works nowadays is you'll scan your ID at the tool crib or the park script and then someone, then you'll stick your nose for something or you'll have some type of requisition or even some line controllers already sent a request into the crib and you're just going over there to pick it up and carry it back to the station. But either way, there is a built-in lineage that you ahead of time. How is this material supposed to flow? And it is documented. And then you make sure that your request matches that defined process. Of course, all the material now except the most primitive or raw materials have an RFID tag on them. And when you walk out of the crib, it's scanned and it is an inventory is decremented and it is put into the in-process cost. So all of this stuff is exactly what we talk about when we want really robust data lineage and we really want to know where the data comes from and GDPR tells companies you must know who touches it and all of that kind of stuff. In fact, I just popped into my head. We can extend the GDPR requirement for right to be forgotten, right? That's no different than we had a part go out and it's no good from the manufacturer. Where is it? Where is it used? We need to pull it out of the line. We can do that in manufacturing or especially consumer products. Let's say Romaine lettuce, for example. Just as a wild example here. You know exactly or you should know exactly where that is. There is that part that items right to be forgotten is a day in, day out table stakes functionality. And what we're saying with this, using this metaphor doesn't make a right to be forgotten or a right to remove anything a big huge problem. You engineer this stuff the right way and it's not a big deal. And you know, we're starting to see people think this way in our practice, which is why we're kind of diving really deep into this metaphor today. That's great. Thanks. So another reason is what we talked about this menu. If we talk about lettuce or we have a car that gets recalled or something, but suppose you put out a bad model. Well, right now, you know, you go with your hat in your hand to an executive desk and say, you know that model that said all your customers would buy this stuff? Well, they really aren't going to buy this stuff because the model was wrong. You don't want to do that. You want to know ahead of time who's going to be affected and what might do that. We do this a lot with data and again, this type of thinking really helps your governance functions as well as your data management functions. When I go and get a new supplier in a manufacturing business, some of you know this and Kelly knows this for sure. I have a hobby of restoring old airplanes and sometimes my good old reliable supplier won't have that part I need and I go to another supplier and it never ever fits. The same way that the old supplier had it because there's always some subtle difference even if the specifications are the same. Now we do that with data all the time. Why not use that mindset that the specs might not be right to then understand and see if the part we've ordered or external data we've signed a contract for is actually going to fit the process. Again, when you think this way, it's really easy to put in processes and capacities and capabilities that act in this way with your data. There we go. So like modern manufacturing, what you're really going for is not quality control. So for those of you out there listening that are in consumer products or manufacturing, you know that about 25, 30 years ago our minds shifted from quality control which is after it comes out the end of the building, someone looks at it and says that's not right and it goes over and gets fixed. Now it's quality assurance. Let's fix the process so that when it comes out the end of the building we know it's going to be right. That mindset is what gave us Kaizen and Lee and Six Sigma and all those kinds of things and we're saying let's apply that to your data. We have a client right now that has a very active, robust, lean management system in place. They're not getting a separate data governance program. They're getting a data governance program that is being inserted alongside and part of their lean system. So we're just taking their internal process improvements with all of their flow of goods and services within their organization and we're making data part of that mindset of lean improvement. So you fix the process. You build the data supply chain. You don't just fix it at the end because everyone knows we spend 80% of our time fixing this stuff at the end. The economics are irrefutable. Change the process so you don't have to do that. So then what does that look like, John? What's that approach to do that? Well, the number, you know, the way it's manifested for most part folks would be the easy example was data quality, right? We realize that we're trying to run models and data interventions are incorrect and we find out that somewhere back way up in some operational system, a data entry process is resulting in a bit of data with erroneous codes on it. So to use, to continue our manufacturing, someone put the wrong product type or the wrong color code or the wrong size code on it and then we do an analysis on the data and we want to do an analysis on shipping costs for very large items and because the data is coded incorrectly, we do an analysis on stuff that would fit in a shoebox and shouldn't have been in the analysis in the first place. A story I tell very, very often is one of the most inexpensive, high-return data changes I've ever been part of was a sticky note to tell data entry operators don't enter all nines in certain fields because that's what they were doing to get their job done quicker and go home sooner. So we, you know, those are the kind of things that is fixing the process versus at the end going, well, the data scientist says, well, the dimensionality's wrong here. I'm going to create a formula and spend weeks doing it that looks at all of the contextual other data and imputes or implies what that data dimension should be and that data scientists love doing that, but they're very expensive. I don't want to pay them to do that. I want to pay them to do the analytics. The data quality's probably your number one shiny example. Does that help, Kelly? Yeah, absolutely. Okay, all right. Time check here. And we are just to make sure people know that we do love answering questions and endeavor to answer them all we can. There are some questions coming in already. And there's one that I can't wait to answer. I just saw, oh, boy, let's hurry up and get to the end. We can get to this question. It's a really, really good one. So let's keep going. But don't please ask questions. I know a lot of you are out there going, well, how do I sell this? How does I position it? We can't use these words. We can't use data governance anymore. We can't use EIM anymore. Well, use data supply chain. Something along those lines. So the next thing is we've got this analogy down. Now, how do you think, how do you apply all of this? Well, first, we call this data-centric thinking. And you've heard Kelly and I talk about this before, of a data-centric systems life cycle and data-centric projects. You think differently than you do with a software product or something like that. The first thing is data is an asset, and you treat it as such. Now, we're not going to do that. There is a bit of a philosophical argument going on now that data in the balance sheet type asset should or should not be considered. And that's not what we're saying here. What we're saying is, look, just pretend it's really, really important, and you're not going to treat it as badly as you've been treating it. It is an asset is important to your organization. So that's the first part of data-centric thinking. The second is, everyone you are supplying data to, remember, they are going to do something with that data for somebody else they're working with. So you are not selling to a consumer. That data does not stop when someone picks up their report. They're going to pick up that report or the result of that data, of that analytical model, and they're going to turn around and take action on it. You are selling to a supplier, not a consumer. And even though a consumer can complain when you're doing it, but if you're in a complicated business model where you sell to somebody who's reselling at somebody else and you make them look bad to their customer, trust me, you'd rather have a mad consumer than somebody that you have messed up their supply chain. All right? So your mindset should be you're selling to a supplier who has a job to do with that, and you want to help them do the best job they can do. All right? That is a subtle mindset, but it makes a huge difference in how you focus on things for that person. You focus more on the utility of that versus just it's correct and it looks the way it's supposed to. It's actually actionable, usable data or information. Second, third thing, you've got to keep in mind, your data strategy should reflect your business strategy. We've talked about this over and over again on these things. And you must integrate your data supply chain with a data strategy. If you don't have a data strategy, and a lot of folks really don't have one, you need one. If you have one, don't go off buying best of breed tools that do really cool things on their own, and you haven't taken an overall look at the data strategy and you haven't taken the mindset to build an integrated data supply chain. Because if you get best of breed tools, there's a high likelihood that you will have a data supply chain where you need to do some extra engineering to connect the pieces together. The fourth item here is treat just like a real business line, even if you're not monetizing the data, which would mean you're selling it or looking for explicit revenue streams from your data or looking to explicitly reduce costs from your data, pretend you're doing it anyway. So AI and analytics and all of these architectures are really logistical challenges. Getting the data to the right spot in the right way so it can be used effectively. So pretend this is a product, even if it's internal, and build out a data supply chain. Anything Kelly, you're on onward and upward. No, I think let's keep going because I love the idea of an architecture to be able to manage those logistical challenges because it is logistical, right? It is. I'm going to go back to our reference architecture here to start the conversation. Most organizations are complicated. Even smaller organizations, as we move into more midsize, or we get calls from midsize companies as the whole analytics and machine learning trick goes down into other organizations or even sophisticated data warehouse or whatever. There are off-the-shelf old packages. There's off-the-shelf new packages. There's homegrown things. And there's modern data assets. And the fact is that your architecture in the 21st century is complicated. There is no one with that simple, here's some source systems and we're going to put the data and stage it and clean it up. And then we're going to use it and do great things. It's never that simple. So you have to be really practical about that. Well, again, building a data supply chain allows you to balance the movement between these vintage and contemporary sides of your architecture. I have a distribution and I have sourcing challenges, which I can take the time to identify all of my sources. What am I fabricating? What's raw material? What am I assembling? Who am I assembling it for? Let's remember that supplier mentality. And then how is it distributed? Is it push, is it pull, is it both? All of those characteristics of the four basic simple stages of the supply chain. And by the way, I supplied pretty much the textbook basic four stages of a supply chain in there just to keep the discussion cleaner today. All of those are reflected in the movement of data and information throughout your architecture. You're moving from the vintage side to the contemporary side. You're moving from the contemporary side to the vintage. Are your vintage? Do you have supplies or sources on both sides? Maybe yes, maybe no. Are you fabricating data on both sides? Maybe yes, maybe no. You can see where you can almost build a matrix that will give you some good guidance as to what types of requirements you're going to have to position your data in the best way for the analytics layer. Remember that analytics layer is down at the bottom. So the vintage can feed into that. The contemporary can feed into that. But where is it coming from? And then define that by way of definition, you've created some metadata and some implied policies as well. And so that way, you know, managing your data architecture with mindset gives you a more efficient architecture. I'm sorry, I had this puzzle for a drink of water there. Okay. So what are some of the features here? Let's dive into the supply chains while we have our heads around what the various functions and stuff are. In a regular goods and services supply chain, I have to worry about integrating all of my moving parts. I have to worry about good efficient operations. I have to worry about the actual acquisition of my position and purchasing my external items. And then I have to worry about, of course, distribution. What goes where and when is it supposed to get there? Of those four, probably integration is the heart and soul of a modern goods and services supply chain. That's your logistics function tends to be parked there. And the capabilities that are within that, we have our, and in terms of maybe operational data systems that we can weigh in here in your product type, management type systems, your organization of how you do your operations, purchasing. There will be policies and clients for purchasing and then your logistics for your distribution. The data supply chain, instead of hard goods integration, we have data integration. We have data operations. We have data management versus purchasing. And for data distribution, we have the push and pull. Our essential capabilities are product management as in managing the domain of product. There is an engagement model of how you work with the rest of the organization. Governance takes the place of compliance and oversight and BI and analytics are getting the data to who needs to see it becomes a logistical issue, not strictly an access issue. A typical data supply chain over simplified for clarity here in our discussion would be creating the data. Someone uses it probably in an operational mindset. Along the way, it gets updated. Along the way, you're measuring your organization. How many did we ship? Well, where did we ship it? Did they pay their bill? Those kinds of things. From a data standpoint, as I create the data, I use it to do some type of operational report. I update the data as my business model proceeds on a particular domain of data. I measure how we're doing. So how many products did I sell? How many customers did I sell to? Then I might build a model. That is model as an analytical model there or not data model. I might do my analysis, prescriptive, descriptive, predictive, whatever, and at the end of it, and this is where, boy, nobody thinks about this, but at some point we do have to delete it. We have an obsolete product. We don't want it on the shopping one. It costs more to keep it than it does to have it handy. And for those of you that have had a good argument with your legal area on how long to keep data, you know exactly what I'm talking about. So Kelly, the metaphor, the functions and the capabilities, they really do line up, don't they? Yeah, they do, absolutely. But I do think, though, that at some point the data supply chain does start to deviate from the simplicity that we're talking about here in the sense that, and I'm just expecting some of the data-savvy folks on the line to start asking questions as they come up. For example, you can create the data, you can use the data, but even at that juncture, it might start to take a fork off of this nice little linear chevron, right? And so I know that this is leading into the next slide, but there are some nuances about the data supply chain that are both interesting around, you know, why this analogy works, but also where the analogy doesn't necessarily map so cleanly how we want to address those sorts of things. So thinking that data does move in a nonlinear way within the organization and then potentially externally to the organization. So I know it's a lead into the next slide. Yeah, and this is a very simple example. If you were to draw one of these for real in your organization, one way you would think about it, first of all, there might be one for every domain, right? You would probably have a customer supply chain and a product supply chain. You may have a metrics supply chain. You could conceivably try to draw one that has all the data you're going to put into an analytical model. It might look a little complicated, but that might be another way to do this. Someone else made an observation in the chat. Not a question. So I can talk about this now because it's a chat. And it shows that great minds think alike and how smart our audience is, because when I was making this slide off to make it clean, I said it said originally delete and or archive. And I took that off to make it cleaner. And someone said, wait a minute, and or archive on the feet. So they are watching us, Kelly. You have to be honest with us. As we know. No, this is a very, yeah, folks, this is a really simple example to talk through it. And we do know that you can get complicated. I have actually in the past for a certain note. We don't have time to go into that today, but certain business situations where we have done a data supply same design, we've actually done that type of engineering. And there's a lot of techniques and stuff that go into that, but we've had to define that for companies that were entering into a new realm or had a burning platform and they had to totally reload their entire applications portfolio. So it's something that is done as a technique or just not using this as an analogy, but they can get pretty gnarly. So anyway, to move forward here, we have let's talk about some of the components that you're going to see. These, none of these will be really, really are shaking, but we have our typical data supply chain and what some things you're going to have to have to manage it. First of all, governance, right? That capability needs to be there. What are the rules of interacting with that supply chain? What are the policies and parameters that make that supply chain work the way it's supposed to work that? Of course, a big one along that way is data quality. That's, as we said earlier with our analogy, that's your number one quality assurance step is data quality. And of course, that requires a data catalog or metadata. And metadata is an absolute guaranteed requirement of a data supply chain. So we've got those good structural things. So if someone is telling you we don't need governance, we don't need metadata, just go through the work, just say, okay, we're going to build a data supply chain and we're going to do whatever it takes to make that run efficiently. And they go, yay, you're going to do it and then very quietly do your catalog and your governance because you have to do those anyway. They're not optional, all right? That means we're real clear about that one. So then we have our sources and sources can be legacy apps, ERPs type systems, often common, you know, COTS type things and external files. We can land in our data lake where we can land and standardize in our analytics, but we can also have in parallel traditional BI reporting and or some hybrid of both of those, all right? So you kind of have your manufacturing and fabrication and then to your distribution type thing. And these are the basic structures that you'll see along the way for those. Not a whole lot of surprises here, right? Yeah, but I do think, you know, one of the reasons that I wanted to raise that in the previous point is that some of these, you know, foundational building blocks on the bottom here are meant to address the nonlinear flow of data, right? Because it's not so nice and simple, and so as a way to ensure that there is a corralling and understanding of the data as it is used and then analyzed, and then maybe it's updated after the analytics occurs or when it jumps around on the supply chain. Yeah, really, and maybe when we touch on this topic again in the future because I'm sure we will, is multiple rows of brown chevrons that come together at the right-hand side to the analytical model because I want to combine product data, customer data, transaction data, et cetera, et cetera. Many, many, many supply chains will get put into that model. No different than if I'm building a very, very complicated product like an automobile or an aircraft carrier or a writer or something like that. Yeah, there's a lot of complexity to that. But at the core, to Kelly's point, if you don't have governance and a catalog and a mindset of data quality, it doesn't matter how much you talk about the supply chain is going to fall apart. You can't manage it. So some of the roles out here that you might see, remember the mindsets we talked about, which is you're going to a supplier and you're thinking this is a product. So here's some, you're going to need someone to be like the product manager, all right? So that's a person that might be, you know, is this suitable or is it right? Is it the right quality? Now, some places we might call this a custodian or a steward, all right? But the mindset would be their kind of product manager here. There is an architectural and engineering type role, which is defining a supply chain from the source all the way through to the end. And that would be perhaps your data architect or an enterprise architect of sort. You need your governance and your quality role and someone to manage data quality so that data scientists have a sustainable product and that you have the appropriate oversight in place to supply standards because like our tool crib, like our parts crib, there are many, many standards in place. No one is going to argue over those because it is so obvious what the excess costs would be if you didn't have standardization, all right? Imagine building a car or anything with no standardization of fasteners. And just use that bolt, you know, if the bolt's bigger, drill a bigger hole. The chaos that would ensue would be amazing. And we do that with data every darn day, all right? So you definitely need that role. And then lastly, leadership and alignment. And we kind of understate this. You need someone who sees it, first of all, these support mechanisms across all these data supply chains, across many demands, share very common capabilities. Leadership should be yes. So we're going to find a place where we can keep all of those monitored and managed and planned and defined. And we're going to also make sure that we're integrating with the data strategy and vision for the organization. So the generic roles, and you can find the job titles for these in all the various types of data management and data governance job titles we have. And then to take the, sorry, go back to the, and then to take that kind of back to the supply chain analogy. So obviously you would have a product manager. What are the equivalent sorts of titles for architect, engineer, governance, et cetera? Enterprise architect would be a really good one. A data architect. Meaning from the product. Oh, on the product side? Yeah, on the product side. Who would be an architect in a product supply chain? Industrial engineers. That's your number one degree. I've run into a logistics specialist. He's another one or someone with an advanced degree in logistics and are called, I can never say the word, right? Logisticians. All right. There's also mechanical engineers. Also civil engineers. Also those are the common industry titles you'll see out there for those equivalents. Got it. All right. So now the responsibilities. What are these people supposed to be doing? Well, someone's got to oversee who's using it. And are you getting out of it what you want to? Now that might mean, obviously, if you're monetizing your data, are you getting that revenue stream or cost saving stream? If you're not monetizing it, you're pretending you're monetizing it. So what, what other measures are in there that you're effective? Kelly, to extend your question in the real world, this would be a QA manager or a QC manager and your, your cost accounts would be, would be monitoring these things. Managing all the other numbers would be any of your metrics that are affected by this and any of your business impacts would, that would be affected by a data supply chain. Then your customer, we put in kind of a supply chain basic four step. There's a basic four step that you can use to kind of simplify your view of customer data and that's engage transact fulfilled service. Those are pretty four fundamental functions that go on with a customer. Think about those in terms of pretending that you're monetizing or selling or creating a product. How are you going to engage that downstream consumer? How are you going to do business with them? How do you know, how do you fulfill your business with them? And then what is the service after the sale? What are those, what do you do in terms of supplying an analytical model to somebody to make sure that they're happy, they got what they wanted and it's working and you don't need to adjust or if you do need to adjust, how do you, what is that mechanism to make the adjustments? And then lastly, again, we're going to go back to alignment here. You know, it's real important with a data supply chain eventually in a really mature organization develops peer status. That is you strive to become right up there sitting at the table with finance, legal and other products and revenue streams. Any organization that says they're going to monetize their data through analytics, even if it means cost savings needs to be at the table with those other folks. Simple business reason, you're making an impact on the income statement in the balance sheet. Why would you not be there? Why would someone be asking you to give me a better, improve my income statement but you're not at the table with legal finance and your product revenue streams, marketing sales, et cetera. All right. So those are definitely some responsibilities that you want to be able to embrace as you advance this data supply chain, especially with the analytical models that we've been talking about here in this series. Yeah. You know, I really like this concept of engage, transact, fulfill service because I think part of what we hear in other webinars, I'm surprised it hasn't come up here because it usually comes up at least once in every webinar is, well, how do you get the support of this? How do you get the buy-in and then how do you sustain that over time? And I think that this idea of engaging with a consumer as a customer and then transacting with them, fulfilling the requirements, servicing them, I think it's a nice way to think about maintaining relevance to those data consumers and to those business people over time to ensure that you're focusing your data program or your data service to the needs of the customer in a way that is sustaining the fact that you have multiple customers, so understanding that it's not just a single customer. Absolutely. So some best practices. We've talked about this and we want to kind of drive it home. Sell to suppliers, not consumers. Remember whatever you're giving that person, they are going to do something with it, especially a reporter and it results of an analytical model or whatever to take action. So it's not that, oh yeah, they're happy with what they got. That's no. Did they accomplish what they meant to accomplish? All right. So you're solving their customer's needs. All right. Provides something that they can turn into their own product. All right. Develop premium products for those sellers. For one thing, they're willing to pay more. Now, if you're monetizing data, that means I can sell my data or whatever I'm monetizing at a higher price, but that also means if I'm just using this as an analogy or a motivator, I can also get them to invest more in what I'm doing for them. That doesn't just mean I can get budget for next year's project. What else can I get them to invest? How about their time? All right. How about their energy? Kelly touched on buy-in on the last slide. This is how you get more buy-in. Folks, I'm helping you do your job. Help me help you do your job. All right. When you start to think about direct-to-consumer type thinking, that tends to be very fickle and very high-cost. But if I start to think about how can I help you be direct-to-consumer, I'm now in a much more manageable mindset of using data. Don't make your customer invest super heavily. If you say, hey, you can use this, but y'all got to go to hours of training and days of understanding and understand all these obscure terms I'm about to lay on you. Don't do that. Just don't do that. And then lastly, markets get so quickly. Proof of concepts are good. We're doing too many proof of concepts in the 21st century. Folks, this stuff works. What an organization says now, and Kelly, I'm going to watch you weigh in on this, because Kelly's glass is half full. Mine tends to be half empty a lot of times. When someone says, well, we need to prove a concept, to me, that's resistance to change. That's just a foot-dragging exercise, because we know this stuff works. But you make the call. If you don't get there sooner, some other department in many big organizations is going to do their own sandbox and beat you to it, which gives you a whole bunch of other sets of problems. Okay? Kelly, we have another one. Yeah, go ahead. Yeah, there is absolutely a case for proof of concepts and proving that something exists or something works before investing too heavily. There is the danger of analysis for analysis as well. I think when we choose the idea around, and then getting back to the concept of the supply chain, right? You can do a proof of concept to identify a minimum viable product or a minimum viable state. But once that's done, then you need to start thinking about how truly is this going to add the most value to the organization. And let's move on, because otherwise the other either lines of business or your competitors are going to be leveraging data in those more advanced ways that would enable them to be more productive, more agile, and serve your customers better than you can. I had a conversation just accidentally with a very, turned out to be a very astute data scientist the other day. And they said that they were doing their data science thing, but they really still wanted to do the sandbox and do stuff and try to answer questions no one had asked. But they knew that they couldn't do that. That they had to focus on doing this blocking and tackling inside that we just talked about. And their question was, should I outsource my R&D, right? Just total experimentation, get it outside the company, just give them access to the sandbox and let someone play with this and budget for that. I thought that was kind of neat. The other best practice here is integrating with your data strategy. And I'll go through this one quickly because we have one more panel to get to and then we have to leave time for our questions. All of these, information as a service and ecosystems, everything's intertwined. You're going to share data. You've got to have a data strategy to do all this. It's a win-win. I mean, when someone says, well, we don't have a data strategy and we're in there doing work with them, whatever it is we're doing, we go, oh, boy. Because we end up kind of backing into a data strategy that you just can't help but not do it. Metadata, got to have it. It's your inventory management system. It is, you're not going to build a factory and just kind of throw everything out on the floor and say if you need it, go find it. That's kind of a no-brainer on that one, right? Data landscape, where is all this stuff? Take a good inventory. Even once a year, even a factory, it was my first real corporate job where I got paid enough that I could feed myself. I was a plant accountant and I would have to go out every six months and just count stuff because even with the best systems you still have to count it and we would always find a pile of stuff that you had, right? And you're going to find that with your data. And then the last thing with data strategy, culture has your strategy for lunch. When you're going to integrate with your data strategy, integrate with your culture because none of this stuff will go down smoothly. That's just the way of the world. People don't really go with it as easily as you'd like them to. Kelly, anything? Let me make sure somebody there. Shannon did I make sure I didn't lose the confidence here. You're still there. Okay. All right. Thank you. All right. Thank you very much. We might have lost Kelly then. All right. How analytics. Now, where is your analytics going to sit here? Typical place. End of the supply chain. All right. I have my landing zone, my standardization, my analytics platform as I'm analyzing. Everything is coming to the end. What do we have? Boom. Let's take a look at it. That's great. That's wonderful. We're all thinking of this, but there's another thing that we're going to see more and more and more of, especially as AI and machine learning comes in, and that is with the Internet of Things and machine learning, that analytics and that data supply chain is going to drop into our analytics environments earlier. In fact, the data supply chain is at the end of the supply chain. The last takeaway here for our talk today is this analytics can intercept the supply chain at any spot. So if you've got some Internet of Things going on, or a lot of data, or a lot of sensor data, we're going to address a question here in a little bit about healthcare. Your data supply chain is feeding, dropping into analytics anywhere along that way. It's just not at the end. You're at the back end of everything that's going on. There's a lot of opportunities to drop IOT data, sensor data, just lots and lots of transactions, excuse me. It's a rough day today here with my voice. At the end, you're going to have some stuff at the beginning. So is Kelly back yet? I don't see Kelly yet. So let's just do our take away and then we'll hit the questions here. Kelly's drops. She's going to dial back in. The let's see here. Best practices. I just was checking my phone and Kelly's going to dial back in. She had a technical issue. There are many uses of data. It's coming from everywhere. This metaphor will help you balance all of that. You're just making your supply chain more complicated. It's not the end of the world. Just build a better supply chain. All right? All of these disciplines of lean management logistics are models in the non-data world that we can use in data management. There is a strong case to be made. Data management really isn't new. It's the same stuff, just a different subject. The end point is your data lake. Your end point is insights and monetizing your data. You can do that anywhere along the supply chain. All right? And your supply chain should be obviously data requirements driven. But fully exploit that whole assembly line metaphor. Raw data in, raw data out is a sophisticated product. And have a mindset that you're selling this stuff to somebody even if you're not. And of course, we have our well-established processes along the way. Metadata, data catalogs, I want to hit the questions here. And Kelly, you can jump in as soon as you can. One question here is, I love this analogy you presented. I didn't have to say that to answer the question, but that was really cool. All right? What are some ways in which you could use a concept in the healthcare sector? And they mentioned their employer, which is a very large well-known healthcare company. Healthcare is perfect for the data supply chain. You have the data, you have the clerk that's typing into a terminal. You have sensor data from all the medical devices that are out there. You have external data from other episodes of care for that same patient. You also have external data in terms of psychographic and demographic and geographic type influencers of people's health. So the healthcare is a perfect metaphor that in a really good, strong healthcare provider, if you engineer a good data supply chain and feed your various data feeds into the supply chain and just manage that really well so that at any point along the way you know where it is, what it is and how it got there, you can drop analytics in anywhere along the way of that without a whole lot of musts or fuss. In fact, we're working with healthcare organizations as we speak in exactly this type of process. So I hope that answered your questions there. We have a couple more here. One question came in. We kind of test on this, but maybe they joined like those with data supply chain, handle data quality. And yeah, that's a fundamental element of the data supply chain. And the next one, and Kelly maybe you can weigh in on this one if you're out there. This seems like a complicated metaphor. Will my management really get this? And I think it is a better metaphor for management. I think it's more realistic than saying I need a data architecture which gives you in your head any number of things that pops into your head. We have used similar analogies at many clients of an information factory where we build the final product, especially with analytics. So it's a very powerful metaphor. I think it's easier on management than harder. I really do. There you go. There's Kelly. Yeah. So I think that there might be some industries where it might not play. So there is probably some limitation. But I think the point of doing an analogy like this is to conversation grounded in something that the organization is fundamentally familiar with. And so a data supply chain and a manufacturing supply chain have some great analogies. So if you're not a manufacturing organization or if there's not the concept of a supply chain within your organization, there might be another sort of value chain, if you will, that does resonate. And so it might be an opportunity for you to use that metaphor within your specific industry. For example, we also do a lot of work in financial services. And one of our clients talks a lot about how the data governance organizations just helping the organization have a fiduciary viewpoint of their data. So fiduciary responsibility goes over really well with banks and asset management companies. So again, you might have an analogy that you can pick up. And if you do, we would love to hear about it. Yes. And at that, or I've always wanted to say this on that bombshell, Shannon, I think we're done. And yes, I think that's profound. Do you have a metaphor like this in your company, no matter what you do? Right? So, Shannon, back to you. Thank you. Thank you. I think that's a great presentation. And just a reminder to answer the most commonly asked question for the attendees, I will be sending a follow-up email by end of day Monday for this presentation with links to the slides, links to the recording of the session. And thanks again, everybody, for the participation. And we'll hope to see you next month. Thanks, John and Kelly. Bye. Thanks. Bye.