 Hello, my name is Shannon Kemp and I'm the Executive Editor of DataVercity. We would like to thank you for joining January's installment of the Monthly DataVercity Webinar Series, Enterprise Data World. This Webinar Series is designed to give our Enterprise Data World Conference attendees education year-round, a conference we produce in partnership with Dama International. Enterprise Data World will be held this year in Austin, Texas, April 27th through May 4th, 2014. In today's Webinar is a preview of one of those talks that you can experience at the event, Information Management Principles, with John Ladly. 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 via Twitter, you can use the hashtag EDW14. 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 to you our speaker for today, John Ladly. John is a business technology thought leader with 30 years experience in planning, project management, and improving IT organizations, and successful implementation of information systems. John is a recognized authority in the use and implementation of business intelligence and enterprise information management. He is the author of Making EIM Work for Business, a Guide to Managing Information as an Asset, and Data Governance, How to Deploy and Sustain a Data Governance, both books you can find on the Data Diversity Book Store, and I'll be sure and get you links for that. He frequently writes and speaks on a variety of technology and enterprise information management topics. His information management experience is barrels between strategic technology planning, project management, and practical application of technology to business problems. We are very lucky to have him here with us today, and with that, I will give the floor to John. Hello and welcome. Hello, very much. This is Shannon, and good morning, afternoon, evening to everybody, wherever you may need you so much for your time, and even at this moment. Let's get into the topic here. Shannon, I assume I've got control now. You do? Yes, there we go. I am under control. I hardly ever get to say that. Here is me, and we've heard all of that. There's pictures of the data for mentioned books. Some of the material there actually is actually in the Data Governance book, so if you want to look at that again or in a little more detail, do so, and we have a nice session coming up at EDW at the end of April in Austin. So today we're going to talk about the role of principles. This is an area where you hear a lot of things about, but there seems to be a lack, obviously, here. Well, we need principles. I don't think a lot of people understand how important these principles are, or the foundation of a good data governance or information management program. Another area we're going to cover is that there is a distinct difference between principles and policies, and you want to try to maintain that separation. We'll look at some examples, and lastly we'll take a very brief look at the approach used to develop principles. This is an education session. This is an introduction. The goal on education will be at EDW, but this will give you a good general idea. We will be leaving time for questions at the end, so if you do have questions, please do so. I am preparing to answer many of the questions around this topic, but please, anything you want to ask, please do so. Some rules of principles. The best way to look at an information or a data principle is to take a look at a similar example, and I would call that something like a religious canon, a commandment, or the Bill of Rights, the first ten amendments to the United States Constitution. These lay out foundational philosophy for society or a belief system, and I know it sounds a little bit high-handed, but that's what you need to do around information principles. What there are a lot of people who are listening to this webinar is because you'd like to manage your information as an asset, but you therefore aren't really doing it now, at least in your point of view. Well, the first and foremost, you need to adopt some philosophy that says, your creation is an asset and will be managed as such, and that is not just a trivial metaphor. That is a belief system that, in turn, forms the foundation of corporate or organizational behavior. There's a lot of books out on the business non-IT side about principle-centered management and principle-centered leadership, et cetera, et cetera. Those are a coincidence to what I'm talking about here today. That's how important information and data principles are. These become everyday guidance. When an organization follows a data principle, it means you have internalized and accepted that philosophy, that data is an asset, for example, you're going to treat it. If you say, we're going to go ahead and embark upon our data thing without any type of policy, we're just going to say, everyone here has some policies, listen to the data governance stuff, and then we're going to take it from there. You're going to actually find yourself less likely to be successful, because psychologically you haven't moved the organization. It sounds a bit, again, I'm going to wrap up on this slide a little bit lofty for an information person or a technical person to be talking like this, but this is really a psychological weapon or tactic or technique to get your organization moved in the direction of managing the information. The policy principle and codify the desired behavior, some people say, I want to treat information as an asset, the policy, how you go about doing it. If your data issues are built around data quality or master data management, you're going to have policies that support new behaviors to improve data quality, new behaviors to go for that golden copy of the truth that you're seeking. The policies are policies, but not in the policies, you have to have that philosophy. A lot of organizations will write policies, and they'll have 20, 30, 40, 50 policies. They'll just crank up policies like crazy. Well, they could be effective, but they're less likely to be effective because there isn't any education or foundation in them. Arizona was drawn four years ago, my first book, and it's two people facing each other. The background is this huge bookshelf, and it's like standards. The tagline is, of course, we believe in standards. Look how many we have. Most organizations are like that with policies. When we go in and do a data governance program or EIM program to build out the principles and policies, we of course look for policies that already exist. And in every organization we go to, we will find scores of policies that have been written, diligently published, diligently distributed, and absolutely totally ignored and not enforced. That's usually because there's no acceptance of the philosophy behind that policy. So processes built into quality, and those things are policies when you create a process. You're saying, everyone does this process. Well, when you qualify a behavior, that is a policy. Another one that we really think is significant is integrating your data policies with your systems development processes, whether you're Waterfall or at Iterative or Agile or some blend of all of them. It's important to have policies that support a different development and use of data and information, and that of course will that affect the procedures of developing systems and your scorecards and things like that. Several flavors of policies. One that we talk about all the time and don't really accept that as a policy or as a codification of philosophy, and that's the data standard. A lot of organizations say, here's our standards. Well, what's the point of that? Put yourself in the shoes of a business person or son-in-app dev, and your data people come trolling down the hall and throw the book on the desk and say, here are our data standards. What world would they listen to those or adhere to those if that's the only way you go about it? I mean, you would say, okay, thank you very much, and then politely move it off to the side because I have work to do. There has to be that philosophy behind it. There has to be that backup. Data standards, data model standards. Now we're getting into semantic standards. So adopting an industry taxonomy or an industry ontology, those are important adoption of policies, and those have to be grounded in some philosophy or principle for their use. Controls. Now this is a policy that's widely accepted in many organizations, especially financial service in that. And controls again are a type of policy. So we want to make sure that we have X rows of data from this particular application and X rows of data go into the next application or we process 2 million euro of items here and the other system has to also produce that 2 million euro of things and we want to balance that. Or reserves have to be a certain amount of level controls. Those are standards and types of policies. If you violate those, there's a problem. There's an interruption. There is a feedback. Okay. That's the other thing that is difficult with policies. Someone writes a policy and you get to the section where we say what are the consequences of not adhering to the policy. And organizations as well, we can't do that. We're just going to call the guideline now because we don't want to get into trouble or management says you can't set rules and hold people accountable or that means HR needs to be involved or there's a labor union involved for some reason and all the teeth comes out of the policy. Well, then it's no longer a policy. Don't call it policy. It's a guideline. It's a recommendation and it's also a waste of ink and paper because nobody's going to obey it. This goes back again before I move to the next slide to sum up what these principles mean. They really do mean changing behavior. They really do mean altering your organization and things about information. It's not yes, it would be wonderful if we had a golden copy and everything would be met and if we had great clear quality data analytics and we could answer all of our questions and not argue about the answer or not. That would be wonderful too. But what we've missed over the years is the fact that organizations don't think that way. They think about doing their jobs and we have to change that mindset. That principle is for what we've talked about. Here's a little taxonomy for policies right here and you have the principle with its ordinance policies. Policies are made up of standards. We've talked about such as data standards or data model standards or using certain ontology or taxonomy. We have controls which can be financial controls, regulatory controls, compliance type controls, and then all the other processes such as processes from a development lifecycle. A classic example of a principle beginning a policy that's a process standard or a process policy is we're going to be data as an asset. Okay, fine, that's the principle. The policy is while we're developing new applications that has to be considered from the beginning. So that means you alter your development cycle or your methodology to consider data at the beginning or the charter phase or the initiation phase or the ideation phase and then you work with data all along the way. Normally most organizations get to the end and say, well, now what should we do about the data? So you can see where mindsets have to change behaviors and change yours. And we all say this, we all wish would happen in the thousands of engagements and the thousands of people I talk to. And they say, well, how do I get my organization to change? This is one of the core jurors for that is really understand that principles and policies are very, very important. So let's look some of a library, a very brief library of principles. When I was writing the data governance book I was gathering all these basic principles that I was seeing in organizations and was going to present them and I realized that there was a pattern to them. You know they were worded differently. They had core meaning that was the same. And because we really want to treat information like we treat any other asset, I'm going to give you the conclusion that maybe we should be bold enough to propose some generally accepted information principles. Those of you with a financial background might have heard of GAAP, Generally Accepted Accounting Principles. Those are a set of standards. They're not law. They're not code. But they're standards that no accountant or financial person on the planet would violate. Because without them, accounting doesn't work. We need something similar in our information world. We need some type of canon that applies to that. So here are ten higher order principles that can be used to form the foundation of yours. And we built this presentation to data, leave enough time to go over these. The first one is the content as asset principle. Now we hear this all the time that information is an asset. Data is an asset. This will broadens that. All enterprise content, structured, unstructured, rows and columns, documents, images, recordings, all of that is an asset. Well, then if you're going to say that, they have to be managed, secured and accounted for as those other assets have been talking about for hundreds and thousands of years. So this is the foundational asset principle. It's the principle of GAAP that's for real value. And so there is value in all of this data and content. Now the value can come from the contribution to objectives. And the last set of business and operational objectives is saying, as part of a policy and principle, that information is valuable because we're going to make better decisions and our reports are going to agree not what I'm talking about. That is not a statement of real value. What I'm saying is if our information is good and treated as an asset, we're going to retain customers and make more money. Real, quantifiable income statement are balance sheet appearing objectives. Also, it's the marketability of data and in the 21st century, year more and more and more organizations are treating that as a fungible item or a commodity. And then the contribution to goodwill, which is your balance sheet valuation. And there are actually accounting opinions on that if you feel like it's a really boring, cold evening in the financial accounting standards board's opinions under Google and you will see valuation equations for data and information. This foundational principle here says, look, your content has value and it's not just metaphorical value. Even if it's not on the balance sheet yet, it's that type of value. Next point, concern. Now, going concern is also a gap. It's an accounting principle. And what that means is that when we look at a business, we don't look at it as of today and it's going to be out of business tomorrow. We assume that there is a life, a forever life to the organization until told otherwise. Now, the same with data. Approximately the last four decades, data and information has been a lubricant for applications. It makes applications run. Data is something application A can send over to application B so it can work. Well, the same with this principle is for data. That is primitive. It's not a means to achieve a result or a byproduct. But this data and the information is critical to the operation and management of the business and needs to be treated much better than treated it now because you're not a going concern with treating the data the right way. And if you want to understand and input that, just look at the financial crisis of 2008. Look at the numbers of it and you're going to see poorly treated data everywhere you look. Next, due diligence. Due diligence is a legal term. That means if you have an action, it should be taken to ensure a positive result you need to take that action. And when we apply the information, we talk about risk. If risk is known, it must be reported. If risk is possible, it must be confirmed. There's an obligation to list some data. Some of you out there might be looking at each other and some of you might be winking at each other because you've done a data quality project or have uncovered an absolute cesspool of data quality. If someone has said, we can't tell the boss that the data is that bad. This principle saves you because this principle says you're obligated to tell somebody about that. That's an important principle. Let's talk about quality. We're talking about quality of content or information. Relevance meaning after CN life cycles. So we kind of put a lot of concepts into one principle here. Update content can affect your financial status. In other words, we're not going to tolerate bad data. Some of you might be in an organization that says, okay, well, we don't have time to fix it and we're not our thing where we're a hard-charging business organization that just gets things done and by golly, we're just going to clean it up at the end or we'll get it up someday. This principle invalidates that approach. What you're seeing here is, sorry, this is really important stuff. We're not going to let you consciously create bad data with the philosophy of cleaning it up. We've worked with several organizations in the last few years where massive data cleanup efforts, cleanup systems, cleanup departments have become accepted practices. They're on their third generation of people working here and creating vast spreadsheets to do find and fix items have become accepted business practices and they've become built into budgets and things and now it's at least done it that way. The reason it was done in the first place was to create a Band-Aid for a data problem. It might be the right thing to keep doing that for some reason, for costs or other reasons, but we find it very surprising that what has been, that was an exception to the rule, has now become classification and standardization of many organizations. On it, this basically says that if you're going to be serious about your data, you're going to let someone check it out. And over-conclusion, they come with, that's okay if they say, well, it's still pretty lousy. Okay, accept that and try to fix it. That's when it's risk, and that's a little bit to the due diligence, but this takes a bit further. There is risk associated with content. It has to be recognized either as a liability or through costs or through some activity to reduce that risk. But what it says is that content can create risk for the organization. We don't overlook that anymore. And we're going to address it. Again, this supports when organizations are deliberately and consciously saying, we're going to fix it at the end. We're going to tolerate that and live with that. That means that they're failing to recognize the risk of that behavior. Accountability, a very unusual word in the IT world for many decades, and that is holding people accountable for poor work with data. This principle says, well, we're going to do that. So someone can lose, in the ultimate instantiation, is someone can lose their job over bad data. And for those of you that are struggling in organizations and having integrated data and poor data left and right, would sometimes wonder that that would never happen. But that's what this principle says. We had one person joke once that if we adopted that principle, there would be nobody left to work here. So I hope it's not that bad where you are. The last one is liability. And I think that those risks and information can form a liability. And you need to understand that someone can misuse your data and that it would be an ethical misuse or regulatory misuse. And if you have been following the news in the United States about some department change and some math hacks, you are seeing what the liability principle is all about. And that's just the tip of the iceberg. There's lots of other liabilities buried in your data and needs to be recognized. So there are some core principles. Now, your principles will come from these. And principles organizations tend to be a little bit simpler, not as wordy, but as I said, those are my higher-order canons around information. So the common seeds we see in our law is information is an asset. Information should be representative. In other words, it speaks to truth or it has authority. Currently, we should be able to share something to see the word collaborate with information. Obviously, secure and secure can cover privacy and regulatory security. It's knowledgeable. And that can cover we can use it. We understand that we know where it is. That's a principle that covers metadata. It should be catalogued. And there's another principle that would cover metadata and a repository or something. So think about with your principle whether it's the higher you implement a very high-order version like I first showed you or something simple and short and sweet to the point. Is this a global? And can you implement it? And it's something that you cannot implement or your organization cannot possibly culturally tolerate. They need to try to think of a different wording for that. But here is a list of common ones. They just Google on the Internet. You'll find hundreds of examples of other principles. So example of one, this particular organization wanted to really emphasize customer because they were very, very customer-centric. They had two really critical, critical, critical subject areas, customer and item. But none of them had their own principle. They had a single authoritative source for customer data. Now, there's two things that go with the principle when you write one. And if you just don't write the principle and say, here we go. You need to talk in a disciplined fashion about the rationale behind that. Why are you doing this? Why is that? This one is this particular phrase or choice of words important enough to make a principle to basically go to change the behavior or the culture of your organization or its belief system. You need to come up with a handful of reasons. In this particular organization, we're going into a customer-centric organization because the market had changed. There was many, many new market pressures. The customers were getting information from the organization and it wasn't matching. There's the concept of the single view. A lot of times you'll hear a 360-degree view of a customer. There were tremendous costs with maintaining redundant data. Those of you that are struggling to do some type of master data management solution, recently I found that if you take a really good look at the cost of your redundant profiles or item files or customer files, you can get management to raise an eyebrow. When you really, really take a look at the real cost of all of that, it's a scary number. A single, clearly identified source of data will lose latency. It's faster to get to things. This is the type of rationale. This is really important to have a rule. We'll see why in a minute. There are many implications, even more important. Now, you have a rationale and you kind of play pretend. You say, well, is this really, if we school this out? Hello, everybody. We're going to have a single authoritative source of customer. What does that mean? Well, it's going to mean we're going to have some new business rules. We're going to have to capture data once and only once. We're going to have to have a single source. In our organization, some organizations, you won't have a single source. It might just be just a designated place of truth, but it could be multiple sources. Clear points of capture and controls and mechanisms and etc. I'm not going to read all of that to any of this time here. But the happier are a lot of mechanical things that have to happen and have to be in place. And these are really important that you go through this exercise and talk about these. And if you have two pages of these, fine, because this is where your policies come from. Many years ago, we were doing an organization where someone said, how do I know what policies I need? And we're early on into this and we'll be honest to say, well, we just kind of know. Well, it wasn't good enough. This particular organization had a very unusual business model. And the standard policies just weren't enough. So we get creative. And what we did was we took a look at the rationale and, more importantly, the implications. We said, well, what? How do we deal with the implications? And what we figured out was once we came up with a policy or a statement to deal with every implication. In other words, if we have to have business rules, what's the policy to have those? If we're going to have a single source, do we need a policy to enforce that? And we found from looking at all the implications that those writing something to address the implications created an abstract for a policy. And then we were able to take those and refer them and blend them and create policies from the implications. Then we bounced them back up against the rationale and look up a slide here to see that those policies support the business rationale. So if I have a policy that says, you will only enter the data here and only here, it'll have these rules on it. Does that make the rationale happen? That won't be able to handle the cost. That we're going to have a clearly identified source. We will be able to address those market pressures. And that will give us, gives you a mechanism or a technique versus just maybe a creative exercise. We can put some due diligence on your policies here. The policies, remember, are processes and standards based on your principles. You review the implications for your policy. So once again, you go through your implications and come up with some statement that addresses every single one. We close down into statements of codified behavior that they are supportive of the rationale. And every principle has at least one policy, but a few or more policies. There are policies that will be written once in a while that will have more than one principle and they are supportive of, so that's okay as well. I'm going to go through a little process here to do that, and we're going to do that as soon as I take a sip of water and then we will just, thank you for me. There's factors that drive, and I showed you the list of high-order principles, the GAPs, and then sample seed principles, and then I showed you just kind of how one would look in a very compact format. To get to that point, you need to consider your environment. One, business need. We know we had an organization that had a lot of market pressures related to customers. So obviously, we're looking at an organization saying, we're an organization that needs to respond to customer problems, so I think some principles around our customer data are going to be required here. Or we're going to have some policies that are anchored in some principle whose channel is supportive of our business needs. Some organization that, for example, is really dependent on operational response. And so this is a big example. You're going to want to have a principle that's supportive, that lays the foundation for policies, supportive of low latency and high turnaround and high responsiveness. So you're going to get some version of the going concern principle, and there you're going to have some application, some, I'm sorry, that creates some policies related to responsiveness, and then from there you're going to have some policies that say, when we do information systems, we're going to be built around responsive service layers or something like that. So you can see how you need to sit and take an effort to plug this together. Again, we have a five-minute-plus-questions event here. We're going to go into this a bit more deeply. Also, if your organization's maturity, if you have an organization that is highly decentralized, fragmented, and is culturally incapable of any type of discipline at all, and has no information discipline at all, you're not going to go anywhere with a principle that says, we're going to superimpose your customer. Because of all the implications, there are things that you can't really do. So you're going to need to back up, find a principle that says, or go with one of the higher-order principles that says, we're going to treat information as an asset as such. And that means as a true asset as such. And then you might want to bring in some of the risks, be it principles or the asset-type principles. So you're going to say, we're going to start to consider an account. Those principles will start to change your maturity. The policy could be very, very primitive and very focused on just particular point solutions. So maturity is very important. Last of your culture, culture is different from maturity. Culture is how your organization gets things done. You can be an immature data company, a very mature data company, have a very fragmented, independent culture, a very centralized culture, or a very rigorous culture, and you can have combinations of all of those. So you need to consider that because when you put in a principle and you want to codify behavior, your culture will resist it. Any change to a culture will be resisted. It doesn't matter how your culture is the most receptive culture in the world or not. Change is change is change. You need to accept that. So you just need to consider how that change is going to occur as you're developing your principles. Now, the other steps are, of course, we apply those higher-order principles. And by the way, I'd love to leave all those. What you're looking at with the game are in my interpretation and while I was writing a book. So you might have a better idea and please email me. My email is in this presentation and where you can get a whole new true data versatility. With person other suggestions, I have several people suggest who merge the risk and do these principles in some way, shape, or form, and we play that with a accuracy or single source or golden copy type principle. So please feel free to suggest something. So if we apply the higher-order principle, then we take the seed principle. So the higher-order ones might be really cool and awesome, but if you look at the language, someone might say, wow, that's what John did, but that's just dyke and we can't use that. And so you do something a bit more appropriate for your organization. Again, you're applying your culture, your business needs, and your videos here. Once you do those, you want to refine those principles because the first time you do a list, you're going to have too many. I have a rule of thumb. No more than 10 principles for any organization. No matter how big or how small. Sometimes we will start with one principle because an organization's culture can only handle one method of change in philosophy at a time. But when they're doing an enterprise-wide and saying, let's try a mistake in their ground and here's all of our principles, we really work hard to get them under 10. There's an old scene from an old movie in Old Mel Brooks, it would be called History of the World Part I, where he is portraying Moses coming down off the mountains and with the commandments. And he says, behold, I have 15 commandments and he drops one. He says, behold, I have 10 commandments. That's kind of where I'm going with here. 15's too many, it's too much to carry. It's a better number. I'm talking about philosophy here. No one's going to want that different philosophy. Then you complete your principles by adding the rationale and the implications and it's really important to do these. Really think about hard, I'm sorry, really think hard about what we're doing this particular principle and what it means and what are the implications. And now go back to our three little bubbles on the left there. While our code impacts, are we mature enough to do this? Do we need to alter this or do we say, well, here's 10 principles. Less through 10 are way advanced for us. We're never going to get there. If we start with them, let's hold those back for a while. Of course, the business needs, if we see that our market place is demanding, that we have, for example, a profound operational integrity and flexibility. And if we don't have a principle that supports that, well, then back to the drawing board, you're new and you need to have one there. In fact, that's been a suggestion enough. One of the gates is that information management is directly connected and tied in support of business goals. I don't want to make that into a philosophy, however. Any ideas again? Just send me a note. So, if there's any questions here, principles are an essential building block for any type of data governance program. When you do data governance, you've got three big chunks of stuff. One, you've built out the organization, that is how you operate data governance. I use the word organization, and that's a misnomer. A lot of people use it. I don't like it. I'd rather call that an operating framework. But it's how you do it. The next important component is the business alignment of that, which is you've got to be doing something for the business. And doing data governance so we have better data so our reports are more accurate is not sustainable, which is the third. How do you make it last? And that's some of the culture change things we've talked about in other talks and things like that. Foundationally, so that's especially to the operating part are the principles and the policies. You can set out roles and responsibilities. So, you know, here's my stewards, and here's my custodians, here's my owners, all of that, and they're going to do these things. Here's what a steward does, and here's what a custodian does, all that. But if you don't have that philosophy behind them, you can rationale that goes with it and the implications, therefore the policies. And oh, by the way, I can measure policies, I mean, I can measure adherence to policies. So if you don't have principles and good policies, you can't measure the effectiveness of the organization. Well, then that plays into the business alignment because now I can't prove to the business that the investment in governance is paid off or not or is paying off. And that's sustainable because I don't have a lot of the data I need from my metrics. And I'm able to change to make some type of cultural adjustment or some behavior adjustment, and I don't have a philosophy behind it. You can see where this is a very, very important aspect of we are moving along well here. So I think we're ready for some questions. Shannon, I'll open it up, and I think we have a few coming through and you can read those or any others that you're getting and we'll have a nice juicy Q&A session here. Sounds good. And one of the questions that always comes up, of course, is that people will receive links to the slides and the recording. And I will be sending out both within the next two business days to all the registrants, so you'll be sure to get those. So go ahead and type your questions in the Q&A section in the bottom right-hand corner of your screen. And we've got a question coming in. John, is there a particular maturity model you would recommend in assessing our organization's maturity? There are many maturity models. We had that slide handy. But now there will be a little bit of just not do that because then we'll make up time for any other questions. Let me phrase it this way. There's a very traditional type of maturity model where someone says there's an initial stage and then he goes through repeatable and refinement type things. Those are connected to the old CMF, the king of the software industry in the 1990s. A lot of people will use that, but that's a process model and it's difficult to map to an information model. There are other similar ones where you can say that you are proactive to things and proactive to things, and those are okay. They fit your culture. Fine. There are some that just bolden what you're capable of with information, and some organizations can just do reporting or what did you do yesterday level of maturity all the way to an ontology or taxonomy type thing, which is we have context and we can figure out what we did and analyze what we did contextually and then perhaps a very, very college model where we're going to predict what we're going to do tomorrow or we're going to predict what might happen tomorrow using analytics. It's a maturity model of what you can do. That is a really good one too. I would say any one of those that I just talked about are very effective because it gives you a good qualitative measurement. There's one, however, that I'm beginning to really adopt and strain that as an education or capabilities model, and it's a simple four steps. And those steps are road, and an organization around information, if it has a road level of understanding, it knows and people will walk around saying, information is important, but we ought to do something about that. Understanding is when people say, I'm going to do something about that and I'm going to do something about that. I'm going to make sure that I sponsor a data quality program or a facility that says we're going to do some type of master data thing or something like that. Recently, we had an organization where the CEO said, enough is enough. Just somebody, please start to show me one mile so I can count belly buttons. So that understanding. Next is an application. We're seeing that in a lot of organizations have a master data management solution, a data governance program going into place, a sophisticated analytics, something like that. The core mission thing happens, though, when people automatically be in their job with this ability that data is important, that it's an asset. So when something, when a new effort starts, immediately the thinking is let's care of our data. They correlate the effort or the new challenge, there's a new business opportunity with how am I going to take care of the information. And that's what I like. It's simple as four steps. It's based on educational theory. A lot of people understand that. So that's what I just talked about in combination with a couple others would be why that. Another question. What are your top tips to convince senior management of the importance of data governance, information management? Information is changing over the time. A few years ago it would be, don't you want to be competitive? Don't you understand how much this is really costing you and that kind of thing? Senior management doesn't really become motivated until it's more customers, more profit, lower cost, better products. Very, very simple approach in there. And by the way, that's as it should be. I'm not arguing with it at all. More recently, as more and more companies go on the bandwagon with this, and I see things like health care reform here in the United States, things like that. I want to scream, you can't do this, but don't you want to survive? I'll be kidding to think about here. So my top tips for management are understand your business needs. Is your business trying to dominate its market with good products or with agility? Does your business need to be more flexible and responsive? Are you having trouble retaining customers? Do you want to retain more customers? Do you want to grow? Do you want to grow by mergers? These are all things you can find in your annual report or in strategic documents somewhere. And you need to talk about those activities too and the concepts of governance and information management. You have to show that, well, you want to have more customers. Well, you need to be able to count the customers you have. Oh, you can't count the customers you have. In fact, you go ask three vice presidents for three counts, you'll get three different customer counts. And by the way, that's silly. Oh, by the way, this is what it's costing you to get three incorrect answers. Wouldn't you want to know what the correct answer is? Because without that correct answer, you're not going to be able to retain and enrich your customer base. It can't happen. And even if it did happen, you wouldn't know it. So a explicit connection of what information management and governance does to business needs. And again, I have to emphasize this again and again and again. When I see a project for do master data or big data or whatever, and I see more data as the business objectives, or our reports don't agree with us as the business objectives, they get afraid because the company doesn't understand the impact. Again, they have not accommodated the cultural change that information has announced. They might be saying they do, but they haven't, because those are the wrong objectives. Jeff just should be saying, we're going to manage our data really well so we can increase our customer base by X percent. So we'll have X percent more sales. So those are the objectives I want to see. Then I know that the company is starting to get it. So make that time between what those things do. Both my books, several examples of strategy maps. Again, send me an email. Happy to send you one. Something like that. You'll start to see how you can make that direct connection. Years ago, people said you can't do that. Information is too abstract. It's too abstract. That's a bunch of... You can do it. And we do it all the time. And that's the important driver right there. That's my favorite topic that you can tell. Next question. Hi, Edwin. I have an organization with very few comprehensive policies. How do you gauge how many principles your organization should attempt to start out with from one up to ten scale? There are very few comprehensive policies. The first thing I would do is one. Is anyone listening to the policies at all? Is anyone comprehensive? But is it comprehensive because of the scope of the policy? Or is it comprehensive because lots of people follow the policy? Is it comprehensive because lots of people follow it that look for that principle if it existed would be the foundational principle of that policy? I'd start with that one. I'd kind of reverse engineer it. If you have a lot of comprehensive policies and scope but not many people are paying attention to them, I would say forget them. We'll bring them back in later when somebody notices. Start with the old standby. Information is an asset. We're going to treat it as such. What are the implications of all of that? That's the one I would start with with everybody. That's kind of the Uber principle. That's the overlying principle that everybody needs. It's an asset, but we don't mean it as a metaphor. We mean it as a true driver of cultural and philosophical change. And that's the one. And again, any more than 10 principles, that's too many. You've got too many statements upon. My guess is, as clients say, we'd love to send you, we were working on our principles and we think we're done. We're going to send you all 25 of them for review. I'm happy to review it, but I'm going to tell you right now, there's at least 15 policies in there that you think are principles. And we'll review the applications in the rationale we always find out that they've actually taken a policy and raised it to a statement of philosophy. That's okay. I mean, that's what the refinement process is for. Imagine if you're familiar with the United States Constitution, our bill writes those first 10 amendments really set a philosophical tone that has operated the United States for well over 200 years. Imagine if the bill of rights would have had 60 amendments in it. The funding fathers would, first of all, not have been taken very seriously. And then the Supreme Court would be busy reinterpreting all of the conflicts between them. Keep them simple and keep them there. So scale one to 10, start with one for sure, and then that's the question here. Oh, yeah. We have loads of questions coming up here. We may run out of time. The next one is from one of our regular webinar attendees. So, yeah, there was a question to go back and just, Janie, let me know if you want to, there's a different slide that you wanted to view. How exactly does one get management to listen long enough without their eyes glazing over to afford one the opportunity and overhead to begin reporting the cesspool of data quality existing in the organization? Repeat that one. There was a hiccup in the circuit there. Repeat that one again. Absolutely. How exactly does one get management to listen long enough without their eyes glazing over to afford one the opportunity and overhead to begin reporting the cesspool of data quality existing in the organization? They will actively do a data quality exercise, profile a certain set of data, show quality out of the numbers of what is really costing in a way of missed opportunity, and show information, show management anything but that. Information people, and boy, I'm guilty of it back in the old days. We're so proud of our data. We're so proud of our concepts and models and the way we can abstract and understand things and that we just simply think that our management must be here all of that. And they put their eyes glazed over. Do not show our management the data model. Do not say that information is an asset in the abstract and in the initial comment. No, that's not what we did. Start with we have the data is like this. It is costing us very much. We lost a contract last year from a major client. We are not competitive. It costs us, you know, we've got clients where they may, where there's been mistakes from data quality of millions of dollars in rerounds of products and things. We have a problem here. That problem is labeled as data quality. The solution is manage our data better. There's a lot of things that go around that. We'll get to that later. But do now understand that this is a problem that we need to address. Stop there. Show them the numbers and go there. Someone says, there's another thing where someone says, we don't have time. The problem is go back. We've got projects to do. Don't do this. This is where I do diligence things. If you know there's a problem and you know it's costing your organization money, my philosophy is if you're a professional, you don't have to ask. Just spend the time, do it, put it in writing, and take it there. If you're walking from the plant to the car and saw a big tank leaking, you would report the leak in the tank. You want to report the bad data. Same thing. So that's the thing. Tell management about the problem and tell them that there is a solution and ask for their permission to go from there. The next question is, where can we find any reference material on GAIP? The only reference material is what I have there in the lines in the book. I explained to one of those in detail in the book and kind of how they came about. I would like to write at least a small book or an exhaustive white paper on them, sometime in the next year or so, but that's all I got. I have to sleep sometime, kids. Now, isn't it in the government's book? I think it's a link to John's books so you can have access to that. Of course, both are available at the date of our City Book Star. Another question. Oh, so this is a follow-up to the previous question. Additionally, management has the tendency to purchase a release of new tools without culture change. Is the panacea for all data quality ills? How do you advise management to fool with a tool that is still a tool without losing your job? Well, you just... Look, if management says buy this and you say, you're going to buy us this table saw with laser cut and everything else, but we don't know how to use it and we don't have any wood yet. And they say go ahead and buy it anyway. Don't say no. If you really like your job, don't say no. Just don't use the tool. All right? And you're not the first person to have an organization that has a tool nobody uses. Trust me on that one. All right? But if you have any say in it, just say we can't buy... Tools are for productivity. We don't know where our productivity needs are. Let us try this one way. We can find where we need it to apply a tool and then we'll apply it as a tool. There's tools that you can go ahead and get everybody that's big and have a data quality tool pretty much. And those of you that are really getting into elaborate guide data governance should start to really think about something to manage your policies and your workflows and things like that. But other than that, just don't buy anything. If they make you buy it, don't use it. And then take your resume. Ben, there's one here I'd like to take a crack at before we run out of time. What additional hurdles do global enterprises prize have when developing principles that are relevant across geographic and culturally diverse groups? This is also applicable to even a single patient. Consideration is a real big part of your business environment. I'd just sell you those three bubbles. How you better your principles is important. That's why that rationale is so important. If you have a problem that is... We're working with a client now that is everywhere. We're in 39 countries and they're a very complicated business model and six strategic business units. A business unit has its own set of principles, but we had to come up with two principles like everybody. One was information is an asset. And we have to treat it as such. And the other one was based on risk. Information can contain risk. And we are also going to put the policy in place to understand and manage the risk and the information. This is something we could apply to everybody. But the rest of them, because a strategic business unit might have a slightly different culture, slightly different level of security, things like that, they end up with their own federated or sub-principles. It's not just one set. We had the layers of principles for international organizations. You can easily apply that to an organization that has just two or three lines of business in one country. So, there you go. This is fantastic. I'm afraid that's all we have time for today. And, Joan, again, thanks for this great presentation and Q&A. It's a very good insight, and I look forward to the full presentation at EDW. And just to remind everyone, we will be posting the recording of this webinar and slides to dataversed.net within two business days. And I will send out a follow-up email to let you know the links and other requested information. And I hope that you will be able to get a world in Austin, Texas this year by January 31st to take advantage of the best prices available. Thanks again for all the great questions. I just love it when everyone's so involved and for your time today. And I hope everyone has a great day. Thank you. Thanks, Joan.