 Hello and welcome. My name is Shannon Kemp and I'm the Executive Editor of Data Diversity. We'd like to thank you for joining this month's installment of the Monthly Data Diversity Webinar Series, CDO Vision. This month, John Ladly and Tony Shaw will discuss the value of data. 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'll 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 CDOVision. As always, we will send a follow-up email within two business days containing links to the slides, the recording of the session, and additional information requested throughout the webinar. Now let me introduce our speakers for today. Well-known industry analyst John Ladly is a business technology thought leader and recognized authority in all aspects of enterprise information management with 30 years experience in planning, project management, improving IT organizations, and successful implementation of information systems. As president of IMQ Solutions, he leads a consultancy focused on improving a client's business results through information management and data governance. And moderating today's discussion is Data Diversity Zone CEO Tony Shaw. Tony is, of course, responsible for the business strategy of the company, and it's subsidiaries including DataVercity.net and all other conferences associated with DataVercity, including the conference we were just talking about, Data Governance and Information Quality, starting next week in San Diego, which John will also be speaking at. We also conduct training and publishing activities focused on the areas of enterprise data management. And with that, I will turn the webinar over to Tony to get us started. Hello and welcome. Thanks very much, Shannon. While we're talking about some upcoming events, given the profile of the folks who are probably on this webinar, let me mention a new event we're organizing November 2 through 5 called Enterprise DataVercity. It's going to be in Chicago. And there is a call for presentations open currently for another week at enterprisedatavercity.com. So if there's anybody on the call who's interested in making presentation to that meeting, it's about enterprise data strategy, architecture, and analytics. All right. And actually, I'm sure we're going to be talking about this topic during that meeting. This is a conversation today about the valuation of data and the metrics that we can apply to data to make it more valuable from a business perspective. We've been talking about this topic for many years, but it's interesting that a lot of new work has been done just in the past few months. And John has been very close to that. He's going to share a lot of new information with us today. So John, you and I have talked about this topic over the past many months, and I look forward to learning something new from you today. So over to you. Okay. Well, no pressure. Thank you, everybody. And we're going to talk about metrics today. So I'm just going to move forward into this and get into the topic. We often hear answers to these first two questions. Does information or data cost or make your company money? And people go, yeah, that's kind of a good philosophical statement. And the rise of big data, the rise of advanced analytics has contributed to that. Is there a broad economic impact? Of course there is. It's broad enough that major vendors are buying primetime advertisements on television, like IBM and their analytics and big data are related advertisements. But those tend to focus on specific instances. They're good examples. There's no detriment to that for sure. But at the end of the day, how do you tell somebody how much? When the CEO says, okay, I'll give you that the data or information costs us money or that it's making us money, but tell me how much? Where would it appear? So you immediately get put into a mindset of measuring. And that's something that a lot of information people don't do. But if we're going to be good at enterprise information management and data governance, we need to start to learn about data. We need to start to learn about those metrics. So our objective today is understand the wide variety of options that CDOs are considering and other top data job, that's the TDJ type, for measuring. And there's a lot of different ways to look at these. And I want to, the main objective here is to understand, I mean we have about 45 minutes plus questions. We're not going to dive into the entire set of metrics that are available, but we will cover them and we'll cover how they can be used. So you can see that this is not a topic that is frivolous. This is not a topic that is someone making up. There's people doing this work as we speak. I'm doing this work as we speak. There's other people doing this type of work as we speak. So let's carry on here. I want to make sure that the metaphor of data as an asset is reinforced with the audience first. And that's basically a relative valuation metaphor. And the story that Dr. Tom Redmond talks about is that there's a very valuable piece of furniture in the lobby of your company. It's a Louis XIV dresser. On top of that is a laptop, and within the laptop is a CD-ROM. The organization catches fire. The dresser costs $15,000. The laptop costs $3,000. The CD-ROM costs $0.20. And you go, well, on that basis alone, we're going to get the dresser out of there first. But if you say that on that CD-ROM is our only copy of all of our customer records, then obviously the $0.25 or the $0.20 CD-ROM is going to be the first object you rescue from the flames. When you start to think of it as in that term, then it is an asset. It is something that has value to your organization. You want to exchange it for future value. You can exchange it for current value. There are circumstances where information can show up on your balance sheet under the topic of goodwill. So when you talk about information as an asset, then you have to then go to the next step. You have to follow through. It can't be a metaphor like on our little cartoon here. It has to be the real deal. How do you treat it that way? How do we measure it? The value is also important for two reasons. The accounting aspect and a practical aspect. And I put the little spies up there from a magazine of my use. And it tends to be, it's not a black or white proposition. If this is an asset, if that CD-ROM is an asset, then it has the capability of generating future value. It is distinct from your financial and material assets, but we know we can count it. We have opinions out there from accounting standards boards that allow us to count it. So there is an accounting reason here to consider metrics. There's a practical reason is that information we know affects the organization. We need to quantify that effect. Also, valuing something lets us measure priorities. I have myself and many others that do this type of work. And those of you just in organizations realizing that prioritizing your work is difficult, you're confronted with enormous challenges where all of your data domains have some type of issue. Where do you start? Well, some type of measurement might help with that. Of course, it goes without saying any more that risk is buried in your data. And managing the risk means managing your data to our interchangeable concepts. And another concept here is that information management will offset your technology debt. Now, technology debt is a concept that's popped up here in the last few years out of the systems development, software development, and Agile type world as a way to measure the impact of the decision on doing code a certain way. And we can apply that exact logic to information as well. And we're going to talk about that in a few slides here. So moving forward, the first thing you have to consider with managing data is the key is the utilization. You'll hear the term intrinsic value. Back in the early 90s, we used to talk about the intrinsic value of data, and I always was puzzled with that. What really happens is until your information is actually being used, the only value you can measure is the sunk cost to put it on the digital storage device. We go back to our old CRUD metaphor for these measurements, which is C for create, U for update, D for delete, and R is the read. And that means that when you use something, you read it. So the value we get from a reading has to exceed whatever it costs us to create, update, and delete. Someone recently argued with me that intellectual property didn't fit into that, and while it does, a lot of companies value their intellectual property through stating the cash flow from royalties or licensing their intellectual property. But they do not apply that revenue until the customer uses the intellectual property. For example, if you have a magazine subscription, you pay $24 at the beginning of the year, the organization only takes $2 a month as income. So usage of intellectual property applies to this particular little piece of algebra as well. But this little simple equation is something to keep, that when you're really worried about the value of something and the impact, let's start to talk about its usage versus its handling costs. And that's at the fundamental of an awful lot of these types of metrics. CDOs are thinking this way now. What benefit am I getting out of data versus the cost, even in the big data realm where everyone seems to want to go out and buy all the big data machinery and all the big data type software and such, folks are starting to slow down and say, wait, this is going to cost a lot of money. What are we going to do with this? And if we do something with it, what types of returns are we expecting? Which in any other business endeavor, that's exactly the way you think. If you're building a new factory, if you're building a new warehouse, you think in exact those terms. So it's time for us information managers to think in those terms as well. So usage is the key there. Now the other way to look at your measures is not only that the valuation comes from a simple equation, but there's a taxonomy of where these metrics lie. Part of this taxonomy is the simple financial statements that we all learned about in an early accounting class. If you've never had accounting class or when you took accounting class, that's when you determined to switch your major to computer science, then you might not have remembered this or seen these. Two fundamental business reports, the balance sheet and the income statement, are the core of an awful lot of metrics, including your information metrics. You can look at them from a balance sheet standpoint, which we'll look at a little bit, and that means there has to be an asset statement or a liability statement or an equity statement. There are no other choices. It is either an asset of value to you, it is a liability to you, or it is stating the valuation of your organization. And when you restrict that, it doesn't hurt you. It helps you zero in on how to value that data asset. Within assets we have tangible and intangible classifications. Tangible is easy. If I go out in the warehouse and count widgets on the shelves, I have my widget valuation. Data is a little harder, but it can have tangible value. For example, the intellectual property, or if my organization has data that someone else is interested in, and we sell it, such as a Google or a Facebook. Liability also encompasses some information things, such as risk. If there's risk in our data, and we know it, we're obligated from an accounting standpoint to report that risk to the organization. I can't tell you how many organizations raised their eyebrows when we tell them that there is X amount of liability embedded in your data, and you're not reporting it on your balance sheet. Of course, they don't really know how to report it, but sometimes there has to be an allowance or a set aside for that. There is another liability there, which I put a little square around, called technical debt. We just mentioned that. It doesn't appear officially on balance sheets, but it's something we can treat as though it would. And we'll talk about that in a minute. On the income statement, there's income and costs. And a good way to see if your information management or data programs working is to state some type of efficiency as a reduction in cost versus the income that's gathered from that cost. So that's a really big category of metrics. We'll take a look at a few of those. And then program effectiveness, the progress and the effectiveness of your data governance or your information management. And we can state that in terms of value of the program, whether it's IM or data governance. So if you're thinking about managing things, this is a really good little item to print off and put up on your cubicle wall. So moving into what some of these might look like in terms of just valuation. Before we get into some equations or some formula, or formula, I don't know what it is anyway. Lots of formula. There's a couple of component parts that we consider when we're doing measurements. Some of them are relative or qualitative aspects because some of our metrics are qualitative. Others are quantitative. This is a brief sampling of a list that's about twice as long as this, but this is enough to give you a good understanding. Relevance, which is the relevance of the data to a particular function. The overall contribution is importance. Accuracy is relative accuracy to the business success, not someone's personal function but business success. Completeness is the relative of all the elements being available. History, the importance of keeping history versus not keeping history. Volume, for example, in a big data world, volume is one of the three requirements. Volume, velocity, variety is volume really important. If it is, that is a determining factor in value. Variety, volatility are the other two, and then latency is when is this available. So these are some variables in equation that we can consider and apply those to some numerical constants or some numbers. A methodology to do this would be to, first of all, understand your business needs. This is vital. If you're going to say I've got to come up with some type of value of information management or you're told to do that, but your organization won't make you privy to a business strategy or business goals, you can't complete this exercise. The exercise, the result, has to be stated in some way that reflects positively or negatively on your business direction. So you have to connect what your business wants to accomplish with the data elements or data aspects or components of architecture required to meet those goals. Then identify the assets within that. Are they particular domains? Are they particular sets of metrics? Is it particular sets of data that you can sell or acquire? Are they external or internal type data? Classify them into whether they're tangible, intangible, and how you want to store them, to measure them. There's many, many ways now to value these. So the valuation philosophy, and I'll show you an example of a handful of those very soon, is important. Then you execute your calculations and present the results. Make sure that they understand what these results mean and how you want to apply them. Nearly all of these measurements we're going to talk to cannot be placed on an income statement or a balance sheet right now. The accounting standards boards will not permit it, but that doesn't mean you can't produce a pro forma or a notional report that says what if. And those can be very powerful numbers to organizations. We'll see, sorry about that. So here is a handful of valuation methods. These are sourced from Gartner Group. I have a good working relationship with their analyst in charge of these, their metrics practice. And we have a good active interchange of research and results here. So these aren't frivolous items. There's a lot of work behind these. Moving down from top left column, and then we'll cover the right hand column. Intrinsic value is a formula that's been created to determine how correct, complete, or exclusive data is. So if a bit of data is sitting in your organization based on its completeness, its correctness, and exclusivity, which of course would be a competitive advantage, what does that contribute to your organization? How good or relevant is the data would be a business value. So for example, if you wanted to use information to accomplish a certain business goal, you would appraise the data required to accomplish that goal and see how well it contributes. This number is an index, but that index can be applied against a financial number. Performance value is another index, which talks about how your data affects your business drivers. If you have a known set of business direction or business drivers, this is a statement of how your data is going to help you get there. What would it cost if you were to... I'm on the other right hand column now, cost value of information. If we were to just lose our data, what would it cost? Now you might initially think, well, that's just the cost to replace it. That's not necessarily true. You can have cost of reputation. You can have the cost of recreation. Yes, there still are organizations in this day and age that if they lost all of their customer data, they would be a month behind when they restored their files. So there is an implied cost of reconstructing as well. Now, if you combine a metric like that with risk of that happening, you get a pretty powerful number to improve your data management. What would we get if we sold or traded is the market value of information. And this is where a real economic benefit comes out. Tony and I have both talked to organizations in the last few months that are monetizing data, and you would never think that this particular business vertical would be ever monetizing and selling its data. Some of it is pretty proprietary. I'm not going to go into who or what other than to say that business models that you would never think they had data to sell are taking that data, merging it with some type of an analytical process coming up with a conclusion, and offering that out to the general market. This is probably the most interesting metric and the most common one we are seeing right now, where someone says, I think I can make money off my data. I've been selling widgets for 20 years, and there is a market for the consumer profiles that buy my widgets, and I have that information and I want to sell it. So we can impute a cash flow and a net present value by applying this formula, and that is almost a balance sheet item or an income statement item. Lastly, what is the economic value of some type of data that if we were selling it or if we could sell it or if others in the market are selling it and we could be doing that too? How do we come up with a contribution to our bottom line? Again, these are all, there's an entire day-long class to learn how to do these. We don't have the time right now to go into that. However, those metrics do exist and they are very, very powerful. The ones on the left focus mostly on discipline. Your information management rigor. They tend to be indexes not tied a terrifically close to a numerical balance sheet or income statement number. The ones on the right are focused on economic benefits. You have a tendency to see many more dollar signs on those metrics on the right than you would normally see in a typical business case for, say, an EIM or a data governance project. I'm just going to take a simple version of one of our index type ones, the business value of information. How good is our data? How applicable is it to us getting our job done? We take our factors. We went over early. Accuracy times completeness times relevance divided by latency. Now, these are all indexes. So, on a scale of 1 to 100, we survey internally in organizations the relevance of certain data sets to certain business leaders. Everything is scored at 100% becomes a 1. So, 98% would be a .98, et cetera, et cetera. We produce a weighted type measure of those. And that gives us an index of how the organization really can identify that this piece of data is valued. We use this a lot to prioritize road maps because very often the road map is prioritized by, well, this is where we have the most visible pain right now, but when you step back and analyze through some type of process like this, the global cross-organizational perceptions, you find out that what you think is the most important thing is not. The example on the next page kind of brings that home where the average of people surveyed across the accuracy completeness, et cetera, et cetera, are displayed there on the screen as percentages or an index. They're multiplied and divided by the latency to give us some type of business value index. And initially, and this is from a semi-real example that's been diluted a little bit to fit on the slide, the organization said, well, our contact data, we must absolutely do that part first. That's why we're doing master data management. When we evaluated everything, look what scored higher. It was the actual mundane, boring transaction data as having a higher index. So we ended up having to recycle our prioritizations on that project by taking an objective-measured look of things. I'm going to talk a little bit shift gears now to do another example on technical debt. And first, we need a bit of a primer, I think, for some of you on technical debt. And organizations accumulate technical debt by doing things poorly. All right, we all know the old adage. We don't have time to design it, so let's just start coding. Anyone who's been in IT for a while gets that and can see the old cartoon that used to be in your cubicle in your office. So this particular graphic is taken from a very good blog on technical debt by a man named Steve Garnett, and he explains it very, very clearly and talks about how to calculate it. The upper right-hand corner of this matrix is the really valuable one, because sometimes you have to do something that you know is sloppy, that you know is quick. And we do this a lot with information. There might be some bone-crushing data need that we whip up a quick database, and we have to do it to do a report for a regulator. And we know that to reproduce this data in the future, again, we'll require the same painful processes, but we didn't have time to stand up a good process. But what we're saying here is that if you find yourself doing that, or if you're doing it and you shouldn't be doing it, you can measure the cost, that delta between doing it the right way and maybe waiting longer. There's no denial that if it goes through a project process and IT goes through ideation and design and deployment, that things might take a little longer than some business analysts slamming together a spreadsheet and entering, you know, half the data. Yes, that might take a little longer. It might be a little bit more of a heavier-handed solution. But in the long run, it's going to cost us a lot less, because we don't accrue any debt by that. Think of it this way. You have an adult child who has their first credit card. What's your advice? The advice is not to go out, run that credit card up to the max, because you want all those little trinkets really, really fast. Your advice is to slowly build your credit rating and do the right things. Now, all of us that have been financially participating in society, which is almost everyone on this call, realize that every so often your car blows up to get three flat tires or the washer or dryer breaks, and you go and you use that credit card and you know you're not going to be able to pay it off in a couple of months. But you have to do it anyway. But you acknowledge that and you institute a process to set some money aside and pay that off over time. What we're saying here is information management is that process to set money aside to reduce your information debt over time. So I have a little example here on the next slide. I'm sorry, we don't have an example. That's the slide after this one. This is more of an expansion. This is what I hear from a data standpoint along the same metaphor. From a reckless standpoint, the lower left-hand corner reckless and inadvertent someone doesn't bother to understand what a taxonomy is or how valuable it is. They just hear, I don't want to hear all that information abstract words. We're just going to go do this because we do things here. We're going to do this. And that's reckless. That is profoundly reckless in the 21st century to not bother to understand some very simple concepts. On the other side, as they prudent as the cost of BI and data handling is getting silly. Now we know that we've arrived there by some type of poor behavior with data because now we have access databases and data march and spreadsheets all over the organization and business analysts creating more and more spreadsheets and reports every day and in fact it becomes the way of doing business. But someone finally realizes this is costing us way too much. So you recognize, because that's on the prudent side, that we have technical debt. We're here because we're here. We are where we are. Now we have to move forward. We have to do something more deliberate. The upper left-hand corner is technical debt by the big resistance point for most people out there doing data governance. The app dev says, I can't do this. You're going to slow me down. And that is an absolute falsehood. That's the wrong way to look at the program. If we look at it from an information measurement standpoint, all you're saying is, okay, maybe we might slow you down that first project because you have to learn a few things. But that assumes that all your other projects, first and foremost, have never generated technical debt of their own. But they have. We know that. We know we do poor systems already that don't meet expectations and have to be re-engineered. So, first of all, that makes that argument invalid. The second thing is, it's okay. Suppose we do slow you down for a little bit. Is the cost of that slowing down worth the accumulation of the technical debt if we didn't slow you down? It's just like the old oil filter commercial. Pay now or pay later. You make your choice. The cost of paying now is a lot less than the cost of paying later. So, if we use a technical debt measurement, you're telling the organization, here's the price of your decision. Make your decision. The upper right hand is what we talked about. Sometimes you just have to do it. You just have to use that credit card to go fix your car. But you're going to figure out a way to pay it off out of time with a good EIM and data management program. Until you rein in your bad data habits, that interest is accumulating on that credit card. And it's going to get harder and harder and harder to pay off. So, let's put a number on that credit card stuff. So, I have a simple example here that's extremely relevant and realistic, I think, because I run into it all the time. And that is the business area needs something done. They go to IT and IT says, well, we're going to have to do a project and it's going to cost $100,000 to do the project. Now, that's internal money. It's not usually cash, but it's $100,000. And the business area throws up their hands and also it's going to take six months or three months. They throw up their hands and say, that's terrible. We're going to go do that some other way. And they just happen to have a business card from a software as a service vendor on their desk. They call up. They outsource a chunk of data. They send data out of the company without permission. Do a five-year license commitment for $25,000 plus another $25,000 a year for five years. They spend $125,000 for a quicker solution in the cloud. However, they get their reports. They get their solution. That data has to be reintegrated back into the company. And IT says, now it's going to cost you $45,000 for us to integrate these three new interfaces at $15,000 a piece. Plus, we have to have someone maintain them because this data is constantly changing. So we're going to spend $50,000 anyway, giving you a cost of the quick fix of $177,000. Now, when you compare that to the cost to build it plus the same cost of maintenance, you have accumulated an information debt of $72,000. So do you make a conscious decision to say, this is okay. Our washer and our dryer broke. We need to get out the credit card. Or do you say, that's bad management of our money. We don't really want to do that. We'll take the six-month hit or the three-month hit and do this the right way. But it's not that you sell your data program because of the merits of the data program. You just tell the business, make a conscious decision. We'll go along with whatever you make. One other thing you can do, which I didn't put here because it complicates the example, is you can figure out the net present value of that $72,000. If your company is getting money at 3% over five years, my rough guess is the net present value would be $68,000 there. So what you could say is already the $100,000 of internal non-cash money, the current cost of that is really $68,000 in cash money. So you have a positive cash flow coming out of the decision to do this thing the correct way. That's the power of thinking about this in terms of the debt, in terms of the financial measurement. Now, it's something that makes a lot of data architects brains hurt because you're thinking like a financial analyst. But there is some powerful, powerful things. This is a simple example to fit on one side. When you do this for an MDM program or data governance program, you can get some very, very interesting ebbs and flows of numbers. You've got to have the financial people kind of crank internal rates of return and such. But it still gives you a cash number versus a phony number, and it gives you a lot of good, again, what's the main reason to do some of these numbers? Just to make a good, solid decision. This gives you a way to do a good, solid decision. I can't use this one enough. I really, it's just fun to use that one. So here's some more simple ones. This stuff you can go out and do tomorrow. All right. What's your cost of your IT? Your entire IT budget divided by the number of instances within a standard pattern domain like party, you know, customer member. If you have 10,000 customers, divide that into the cost of IT. What's your IT or your information cost per customer? Even better, add the cost of IT to the cost of your shadow IT, which is that handful of BAs in every business department doing IT. Let's not sugarcoat this. Add that number to that number. Now you get a powerful, powerful productivity number. The amount of end user labor by the number of users. All right. What's it costing them versus how many? Of course, you want to drive that cost per head down through using data. Your total data budget, BI data warehouse divided by total users. Again, that's a productivity number. The number of interfaces that you send out, just you can count this tomorrow. This is an organization a few years ago. Every night, 3,000 comma separated files were spun out to numerous business users. I would guess that the amount of redundancy and duplication and risk in that was pretty tremendous. That's certainly a number that you would like to reduce over time. The cost per interface, I showed that to you on the prior example. I use a number of $15,000, because that's actually a pretty close number. If a business person comes and says, I want you to send me this data every night on a CSV file, you can say give me $15,000, because that's what it will probably cost your organization to develop it and support it for the first year. Your compliance costs as a percentage of your total income. How much are we spending on governance, risk management, and compliance as a percentage of our organization's income? A lot of organizations, especially financial services, have really, really big compliance areas, and they need to spend that money, but sometimes it gets a little bit material. Several very high-profile organizations, financial organizations in the last few years, have publicly shown the millions and millions of dollars they're spending on compliance and risk management, and I say add to that data governance, because data governance should be part of that number. It should be part of the driving that percentage down over time. Also, your compliance costs, instead of income, if it's an insurance company, take that as a percentage of your risk reserves or even your premiums. That gives you an idea of impact of governance on risks and premiums. Budget per terabyte or gigabyte, that's always a nice number to see if all the stuff you're storing is worth it, and also that includes all the access databases and all the Excel spreadsheets and the departmental servers, because when you add that number together, we might forget terabyte, we might leave that behind and go right up the petabyte really, really fast. And then there's an awful lot of benchmarks in the industry on the number of IT tools. Who doesn't have too many query tools? Who doesn't have too many or duplicate ETL tools or something like that? Licensing costs, training costs, et cetera, et cetera. These are all metrics that you can go out to do tomorrow that are relevant to a CDO immediately or any type of top data job, because they are dead-on indicators of progress and success. From a standpoint of risk management, it's another key metric area. You can have risk across operational, strategic, financial, and regulatory domains or dimensions. Within operational, supplier exposure, employee turnover, and just a loss of the information, that cost of recovery can be there. Supplier exposure is what happened to Target because it was a supplier that opened the hole that created the leak that lets somebody get in. Competition mergers an acquisition. Our strategic risk. What's our competition doing? Are they selling their data? We're going to merge with somebody. Who's got the better data processes? Is it them or us? We're buying a company, but maybe that company has better processes. You want to avoid the tragedy that I saw personally about 10 years ago of a company with relatively good information management being acquired by a company with very poor data management. And on a Monday morning, a beautiful corporate scorecard with drilled-down graphical capabilities was replaced by a large green bar printed report from a mainframe. You want to try to avoid that particular risk. Financial, of course, there's liquidities, the market, the basil accords, BCBS, those are well documented. But don't forget something mundane like cash flow. Let's go back to our technical debt. That one example where we went outside to a cloud, that was cash weaving the company in that present value of $68,000 give or take versus $100,000 of, yes, expense, but not real cash. That's something to really consider. Regulatory wise, we've got the penalties. From a quantitative standpoint, just look at all the possible fines you could get and try to see if those conditions are matched. The cost to adhere to regulations is also a key item, as well as the opportunity cost to spend some money to not get in trouble from regulatory matters. So those are all risk-type metrics as well. Again, things you can probably start to do tomorrow. A couple of other risk things that are very specific, just your cost per downtime, your cost of loss of customer confidence or reputation. A really good way to do that one is, let's think balance sheet again, go to equity. Something bad happens and your stock price goes down $3 or $4. What does that do to book value? Book value is your equity. It's on your balance sheet. So if you do something bad with data, a large investment firm the day before yesterday was very publicly fined a lot of money for bad data. And that affected their equity. You can connect the two explicitly. Financial risk, liquidity, operational costs, and market value reduction, we hit that one already. And then the potential penalties per your subject area. What kind of legal risks are in my customer data? What kind of legal risks are in my financial data? Those can be explored and added up. And then litigation fees over time or another one. Lastly, just getting to the bottom of my little taxonomy, some effectiveness and efficiency metrics. Operating income, my knowledge worker. This is my favorite. You can go do this one after the art talk. Go grab your income statement. Find adjusted gross income or operating income. Any number that before you apply, variable overhead and taxes are right. Divide that by the number of knowledge workers. A knowledge worker is somebody who makes decisions and takes actions based on data. Not the person that's putting the spreadsheet together, but the person reading the spreadsheet and making a decision. If you don't know what that is, take 10% of your workforce. Get that amount of money divided by the number of knowledge workers. So let's say you get $1 per knowledge worker. If over time you make more money and you have the same knowledge workers and you have $1.10 per knowledge worker, for example, that means pretty much you're more productive with the same amount of data and using your data. That's actually a metric that can be tied to data management. The net present value of any specific data project, that number as well as the portfolio come into play when we're talking technical debt. If I have cash leaving the organization in lieu of internal money, I need to take a hard look at the cash flows, the present values. It becomes a buy versus build decision and it has to be removed from the realm of political inconvenience for a particular area to be worried about timing and things like that and you can put some hard numbers on those things. In summary, this is something you can do. I think we showed and CDOs that I talked to and CDOs that Tony talked to are monetizing data, are really, really diving heavily into this type of work. There's many, many options. The key to this is understanding the categories of measurement. Start to think income statement and balance sheet. A lot of times people ask me, John, how do I do the return on my data governance program? My question back to them is what part of the balance sheet is your business want to affect by the data governance program? Then we can start to worry about the return. What I don't hear very much anymore but I hear occasionally is it's too hard to measure this stuff. No one will understand it. That's not true. It might be hard for data types to get their head around it, for business folks to understand that there are just as powerful metrics in the data management world as there is in the business management world. But they are there. Every day we evolve. We try new things. We're doing more. We have a lot of good, qualified experience in this area and we can render a solid opinion that this is the real thing and the real deal and something that you can definitely start to do. At that point I'm going to take some questions. I will turn it back over to Tony and Shannon. I will invite everybody in the audience to leave the questions in the Q&A section which is in the bottom right corner of your screen. There are a couple that have been submitted already and one is a nice entry point because I was going to ask a simple question myself. There's a question about the notion of a data accountant. Have you run into anywhere, John and your clients are elsewhere, where the organization is using accounting staff to manage the costs and revenues related to data? Are you familiar with the term at all? Yeah, I actually, a long time ago, in a galaxy far away, I was for a short time the data accountant for a large IT department. The CIO assigned me to our charge back system and we basically applied internal accounting concepts to our work, which is kind of where I got the seed planted for this. Maxi, just some background. My degree is not in computer. My training is economics and accounting. So that planted the seed. So from maybe an internal thing, someone that can crunch numbers and do this, I wouldn't necessarily call them a data accountant but maybe an information value analyst or something. The one thing we need to be clear about is if we're getting into accounting and we're getting into the balance sheets and the income statements, that is the job of accounting. So there is a separation of duties concept here that for an organization to get a qualified financial statement, they must honor that. So that data accountant might do some accounting kind of things but I would make them more of a financial analyst or a contributing person to the accounting function. That's how I would position those types of things. Okay. So as often happens, there are folks who want to know about specific valuation methods and how do we track certain types of things. So we'll try not to spend too much time on these because they can be very lengthy answers and we've got four or five of them to get through here. So the classic, John, is how do you put a cost on poor quality data? Well, that's perfect for the technical debt. You can identify the cost of fixing the data. You say, well, here's data we've identified as undesirable quality. What's it going to cost us to fix it? And that is a number and that is debt. That is number. Because you've already acknowledged that the data is not correct, that it is a problem, now you must acknowledge the cost of that problem. And once you figure out the cost to do it, that's technical debt. Now, so it's just like, you know, the adult child that runs the credit cards home and comes crying to dad and going, you know, my car broke down and my credit cards are at the limit and I can't fix it. Well, you need to handle your money better. All right. So do you want to reduce that debt a little bit at a time by implementing going forward or prospective data management? Do you want to have a big project to reduce that debt? We would call that a junior get a second job, right, and pay off the debt. So do we have an extra effort to do that? But the cost of the other cost that would add to the technical debt number, not only the cost to repair, but the impact cost of that data. That poor data became poor data because it doesn't meet expectations. What are those expectations? What is the cost of that not being met? Those can be quantified nine times out of 10. And I think, in fact, if you were just to Google that, that question, there's quite a lot of discussion around that sort of thing on a lot of marketing discussion boards, for example. Oh, yeah. There's a few equations we didn't have time to show here, which we can run that. Also, Danette Mibilvres' work has some nice treatments of that as well. And I think her book even dives into that. So there's another resource for somebody. Okay. Yes, to answer the question, Shannon will distribute a copy of John's slide deck after the presentation. She sends a link approximately 48 hours or two business days after each of these events with a link to the recording into the slide deck. Also, there's a couple of questions here about where can we get more information about different things. If that's not available right now, we'll attach that to that same follow-up message. John, do you know where somebody can get some more information about the information valuation method? The methods are going to be... The one page of methods I talked about are going to be released in a very detailed set of literature from Gartner Group here in the near future. In fact, we were really lucky that Doug Laney of Gartner Group allowed us a sneak peek at this today. We've been noodling with these, improving the concept for a while to kind of qualify us to talk about it. Now that there's qualifications and data and evidence, Gartner will be releasing their version of this in the very near future. If you're a Gartner client that's a no-brainer, just keep an eye out for it. If you're not, keep an eye out on a blogosphere. I'm sure they will release some teasers for this that would encourage you to buy the white paper or something like that. That's where those would come from. The other ones, the ones that I use, we have a class and I've done some blog entries on these over the years. Have people just get in touch with me and I can try to provide some material to you as well. Okay. So my friend Jane has asked, how do you suggest evaluating unstructured information as opposed to data? I know the environment that she comes from, which might prompt that question, but is there really a difference? No. No, for this, I mean, if you're going to, you know, once it's spinning around on that disk, it's ones and zeros. And using it and marketing it and using or abusing it, those all tend to start to blend together. The one aspect of the unstructured data might be in the amount of investment you need to make it useful to somebody. If you have to parse it, massage it, strip it, et cetera, et cetera, those are extra steps, extra costs that you don't want to forget. But other than that, it pretty much all sits in the same place. It's content that has some type of value from some type of perspective. Okay. So Jane, if there's additional context there that we're not taking account of, just jot that into the Q&A section. We only have a couple of minutes left. I wanted to ask you, you know, what's your perception about the view that the accounting profession takes currently of some of the reporting and accounting issues involved in data-oriented assets and to the balance sheet? Yeah. They're starting to come around until a few years ago. FASB, for example, was just adamant that there was no way to do that. But now that more and more organizations are monetizing data like a Facebook, like a Google, they have to address it. One thing that when I answer this question and as you listen to my answer, you have to keep in mind one really brutal concept of accounting that is in Violet. We can't ever change it. You have to match expenses with M-Revenue. You can't have one versus the other or just match. And that's why a balance sheet balances and an income statement, result of the income statement, has to find its way to the balance sheet. And then that balancing mechanism is a wonderful thousands-of-year-old mathematical process that tells us our organization's financial state. We can never, ever change that. So from the state of the accounting profession, it is we have not seen a revenue stream and a matching up expense stream to date that is tangible enough to say we need to do that accounting treatment. Now we're starting to get there and now they're starting to think about this. It's not an easy topic, but we have seen some progress. I don't know if we'll see FASB do something in the next two years, but I would say within 10 years you're going to see an adjustment in some accounting practices that have some roots in data valuation. We'll just be to wrap it up there. John, just before you leave, why don't you click forward one more slide and then people will be able to see your content information and follow up with you. I don't want to mention that these webinars occur on the first Thursday of each month. So our next one will be on July the 2nd. We're going to be interviewing Anthony Algman, the Chief Data Officer of the Chicago Transit Authority. Anthony was appointed recently and has a lot of different goals and a lot of different perspectives on everything from the use of APIs to strategic data quality and data governance. He's an entertaining guy and I look forward to having him during our next program. I will hand it back now to Shannon and thank John and Shannon for organizing today's program and thank everybody for joining us. Thank you, Tony, and thank you, John, as always for a great presentation. You can meet both Tony and John at our Data Governance and Information Quality Conference next week in San Diego. If you're going to be there, be sure to stop by and say hi to both of them. And as Tony mentioned, as a reminder, I will be sending out the follow-up email by end of day Monday with links to the slides, links to the recording, and the additional information requested throughout the webinar today. I hope everyone has a great day. Thanks as always to all of our attendees who participate in everything we do and for asking such great questions and being involved in the webinar. Have a great day, everyone. Thanks, Tony.