 We would like to join the Data Diversity Webinar today. We're going to ask for data. Is there a difference? The second solver of the Monthly Data Diversity Webinar Series for World Data Governance with Bob Siner. Does the call point just to get us started? Due to the large number of people that attend these sessions, you will be muted during the webinar. For questions, we will be collecting them at the Q&A section in the bottom right-hand corner of your screen. We would like to invite you to share your questions or questions via Twitter using hashtag RWDG, Real World Data Governance. As always, we will send a follow-up email with the two businesses containing links to the slides, the recording of the session, and additional information requested throughout the webinar. Introduced to our speaker for today, Bob Siner. Bob is the President and Principal of KIK Consulting and Educational Services and the Publisher of the Data Administration newsletter, tdown.com. Bob has been a recipient of the DAMA Professional Award for Significant and Demonstrating the Contributions to the Data Management Industry. And Bob Siner advises in non-invasive data governance, data stewardship, and metadata management solutions. With that, I will give the floor to Bob to introduce the webinar. Hello and welcome. Thank you very much, Shannon. Thank you, like always. Thank you, everybody, for taking time out of your busy schedule to participate in this webinar. I hope you're having a great summer. I know summer is coming to an end. It's been hot and cold here in Pittsburgh, Pennsylvania. So, I hope you've had an enjoyable summer wherever you are. Today's webinar, as Shannon had mentioned, is called Governing Customer Data. Is there a difference? And oftentimes, when I go into organizations, we talk about the different types of data that they have and if there are any nuances or idiosyncrasies that are associated with one type of data versus another type of data. So, that's what we're going to talk about today in regards to customer data. And from that abstract, and let me proceed here, first of all, let me just tell you that the upcoming webinars that we have over the next couple of months are using governance metadata for mass consumption, understanding data, big and small, come one, come all, and data governance expectations. So, I'm really looking forward to completing the year with these three webinars. And if you're a regular listener to the webinar series, or if you are new to the webinar series, I welcome one and all, but if there are specific subjects associated with data governance that you would like us to address, we're getting ready to set the agenda for the coming year. And if there are things that you would like to have me talk about or really anybody talk about, please send that information to Shannon. I'll send it to myself as well, because we're really interested in trying to hit a home run with each of these webinars and find subjects that are really meaningful to people that are participating in the webinars. So, these are the three webinars that are coming up. You can register at dataversity.net, and I look forward to having you participate in those sessions as well. I want to talk a little bit about the abstract, and I started talking about it a little at the beginning. A lot of organizations tend to focus their data governance or information governance initiatives around a specific subject of data, rather than all of the subjects of data within an organization. In fact, I was talking to two groups the week, and we spoke specifically about that, how moving forward with your governance program to try a Big Bang approach doesn't seem to make sense in most organizations, and I can tell you honestly that I don't think I've ever seen an organization that has been successful with a big governance program where they focused on all of the data at once. Oftentimes, they do it incrementally. They start with a piece of a piece of the pie, and they start to work their way towards covering most of the most important data for the organization. But what I'm finding out from most of the organizations, or at least a lot of the organizations that I speak to, that they focus on customer data first. So, we figured we'd pick that subject for this month's webinar and talk about what are some of the things that are specific to governing customer data versus governing any other types of data in the organization. And what I'd like to do is if you're sitting in front of a computer right now and you have your hand on the mouse, or maybe perhaps you're just listening to the webinar, but I'm going to ask the question for you guys that are in attendance is, do you think that there is a difference between governing customer data and other data in the organization? So, if you can either by showing your hands or accident, I guess I didn't put this up front, but send a message and say whether or not you think that governing customer data really has to be different than governing any of the other data in the organization. But a lot of organizations do start their focus on becoming customer-centric and becoming data-centric through working on their customer data. So, people talk about the 360-degree view of the customer and how the customer is constantly evolving and all those things. Truly, the customer, for no matter what your business is, no matter what you call a customer, hopefully it's something nice, but whenever you call your customer, the customer is truly the main thing that keeps us in business. So, the question I have here is, if you can put a check mark next to it, is there or should there be a difference in how we govern data about our customer and how we govern data around other subject areas or domains? And so, I'm not going to answer that question yet. In fact, I don't think there is a single answer to that question, but let's talk about it a little bit and see if we can draw some conclusions from that. What I'm going to do is I do it with a lot of the webinars, and I kind of focus at the beginning on the definitions of governance and stewardship, just because there may be some new listeners out there who may not understand the approach that I take to governance and how I define these terms. So, data governance is the execution and enforcement of authority over the management of data and data-related resources. And when I read that, a lot of organizations cringe. They say it's just worded way too strongly. Organizations take that definition and say, you know, what do we really need to execute and enforce authority over the management of data? So, why don't we define governance as what it is and the approach that we take to implementing governance within our organization, of course, I suggest that we take a non-invasive approach. I'm not going to talk a whole lot about the non-invasive approach during this webinar, but you can kind of tell what my definition is through my definition of data stewardship. When I talk about data stewardship as being the formalization of accountability over the management of data and data-related resources. So, rather than assigning responsibility to people or giving them work that feels like it's additional work, I suggest that we recognize people or we identify people that already have steward responsibilities and we start to apply governance or help them to apply governance to the data that is meaningful and impactful across the organization. So, just real quickly, my definition of non-invasive data governance is the practice of applying formal accountability and behavior to non-invasive roles to existing processes to assure that definition, production, and usage of data assures these things. I mean, it's kind of a general definition of data governance, but I talk a little bit about the approach, which is let's be non-invasive. Let's not have people feel that we're hitting them over the head with a stick and we're telling them what to do or we're giving them new titles. Let's apply governance to the organizations. A lot of times when I'm speaking at a conference, the first thing I'll do is I'll ask the audience how many of your organizations are governing data and only a percentage of the hands will go up. And then I say, well, let me ask the question again. How many of your organizations are governing data? And this time I want everybody to raise your hands and it kind of gave me a strange look, but they all raised their hands. The truth is that you are already governing data. You're probably governing data in an inefficient, ineffective, maybe informal way and non-invasive kind of addresses taking that informality and turning it into formality within your organization. So I've seen this diagram before. I just want to walk through it real quickly. Again, for those people that are new to the series, I want to highlight areas here in the middle. So oftentimes in an organization, if you can get your senior management, your management at least, to say that we need to do these things that are listed here in the middle. And specifically for customer data, if we do these things for customer data, is that going to be necessary in our organization? And they are. Data must be recognized as an asset. I seem to hear a lot of organizations talking about that. Data must have clearly defined accountability. Well, if we put the word customer before it, well, customer data needs to have clearly defined accountability. Certain product data and vendor data and material data and employee data, they also have to have clearly defined accountability. So I think you can see which way I'm leaning in here. I think governing customer data is different from governing other types of data. Data must be managed to follow internal and external rules and regulations. Quality must be defined and managed consistently across the lifecycle. So I've had organizations tell me that this slide here is almost a picture that's worth a thousand words. If we can get our senior management to agree that these things in the middle of the diagram are important and they're willing to sign their name to it or maybe not even just sign their name to it, you just have to nod, then that's probably the backbone of what we need to in order to put data governance in place. We would need people to recognize that data is an asset, that we need to have clearly defined accountability and all of those types of things. So let's talk about customer data. And so customer by any other name, I don't know what types of industries you guys are all in, but maybe you don't call your customers customers. Maybe you call them members, maybe you call them associates, students for universities and for profit education, companies and public school systems, subscribers and patients and visitors and guarantors. I'm trying to think about another domain or another subject area of data in organizations that I've worked with that have so many different names for something that's really kind of the same thing for the organization. And I really didn't, I couldn't come up with one. I mean, it seems as though customer data may be about as confusing to an organization as any type of data that you have in your organization. I worked with an oil and gas company this week. They were focusing on well data. Well, well, well data is very important to their organization across the board. They don't have a single definition of what it is. A lot of organizations don't have a single definition of what a customer is, a member or a student or a visitor or whatever or all those things that are listed on this page and whatever other names that you have for a customer. So the first thing we need to realize is that customer is very complex. Customer hits everybody in the organization. However, the problem with the same can be said for most of the types of data that we manage within our organizations. So I want to ask six questions about your customer data. And if you're interested, and I would be really interested in seeing it if you are interested in kind of participating in the webinar this way, but if you have an answer to this question that's specific to your organization, you don't have to tell us what specific organization you're from, but you should have an answer with us through the chat sessions because Shannon and I and everybody else who is registered for the webinar and wasn't able to make it and who's going to get the email, they may be interested in the questions that you have. And, you know, my perspective and other people's perspective on these questions as well. So let's start with the first question. Is customer data different from other data in your organization? Is customer data more heavily regulated than other data in your organization? Are there more people? See, I'm seeing the chat line move really quickly so that's really kind of interesting that I'm seeing a lot of yeses from people. So customer data more heavily regulated than other data in your organization. Are there more people who handle customer data than handle other types of data within your organization? Customer data used in more decisions than other data in your organization. Is customer data managed any differently than other data in your organization? I was speaking to a good friend of mine recently about big data governance and customer data governance and little data governance and all these different names that we give to the data governance. I actually had a client this summer that referred to their data governance program as being a customer data governance program because they were specifically only focusing on customer data in their organization and they didn't want other people in the organization to think that they were going to be applying governance to other types of data even though customer touches on so many different types of data in the organization. They wanted to call it customer data governance but really what it was was data governance for the customer. So is your corporate data used in more decisions? Is your customer data managed any differently? Is your customer data more of a corporate asset than the other types of data within your organization? So the best question really is, should we get different customer data any differently than other data? So that's really the bottom line of what we're trying to get to with this webinar. So let's go through each of those questions and let's talk about those for a second. So is your customer data different from other data in your organization? The answer to that question is yes. It's different from other types of data. It's a different domain. It's a different subject area. There are different people that touch it. It's different than other data in our organization because of where that data comes from. It impacts all of the other data and how it gets handed down from person to person through the organization. Yes, it's different because the rules we have to follow. There are rules, a lot of rules. I'm going to share some of these with you in a second but there are a lot of rules that are associated with customer data and any of our organizations that use customer data or where customer data is in a center of our organization, we know that there are a heck of a lot of rules that we have to follow for customer data. Yes, because without our customers, we're going to go out of business. Yes, it's another domain of data for all of these reasons. It's different from other data for all of these reasons. The other side of the coin is, no, it's not any different because it's data. It's data that's in bits and bytes and we're going to talk about structured data here. We're not going to bring unstructured data into the equation, but I guess you can do that as well. But the data that we have about our customers is coming from a variety of sources, sometimes from the customers themselves, sometimes from other organizations, sometimes we buy the data, sometimes we have institutions and clinics that submit this data to our organization. But let's talk about it. Aren't there other types of data that we do some of those same things for? So in the response that I do to this webinar, this specific webinar in the email that I send back to you, I'm going to kind of take some of the answers that you've provided or some of your thoughts because it looks like the chat sessions are pretty busy and that's great. I'd love to see participation, but I'm going to let you know what other people are saying as well. So if some data is different from other data, I guess you could say yes, but I guess you could say no too. So we really haven't answered the question yet as to whether or not governing customer data is different from being any other type of data. So is your customer data more heavily regulated than other data within your organization? So yes or no? Are you thinking more heavily regulated? What I'm providing for you on this page here is a list, I don't know if it's largely for you to read it or not, but there's also a list of United States privacy laws pertaining to customer data. And then down through there's things like FERPA, there's things like the Patriot Act, there's things like the International Internet Protection Act of 2001. We don't think about all these things, but there are a ton of regulations that are associated with customer data. So this week, as I mentioned earlier, I'm with an oil and gas company talking, they're telling me about all the different regulations that they have associated with their data. And I don't have a list for you of those. Maybe at some point it would be great to compile all the different regulations for all the different industries somewhere. I don't have the time to do that, but it may be something that is very worthwhile for people out there. So the answer to this question, is your customer data more heavily regulated than other data? You could say, yeah, it's got a lot of regulations associated. Maybe, maybe not. I don't know of all the regulations for all the different types of data in all the different industries. But what you see in front of you here is a list of a couple different regulations. And they are US regulations. And they're primarily privacy laws pertaining to data. So there's only US, and we know that there's organizations all around the world that use data, right? And they have different regulations depending on the different parts of the world that they're from, or even the states or the provinces within the countries that may have some specific rules. And also, there's just the privacy laws. What about any of the other laws that you don't have to be concerned with regarding our data? There's international laws. There's laws other than privacy. There's classification rules. There's security and operations. And there's specific business rules that you use to regulate the data within your organization. And so, again, what's the answer to the question? Is your customer data more heavily regulated than other data? And a lot of you that are on the call that are focusing on customer data are going to say, yes, it's more heavily regulated. But then talk to somebody in another industry and see what they think and how they would answer that question. They most likely would say, you know, there's a lot of regulations too. So I'm not sure that I could say that customer data is more heavily regulated than other types of data in our organization. So the third question was, are there more people in the organization who handle customer data than other types of data? So yes, more attention is paid to customer data. I can see somebody from a very customer-centric organization saying that. You know, from our strategy on down to our marketing, to sales, to operations, to customer service, to support retention, retirement, you know, basically customer data hits everybody in the organization. So for sure, there are a lot of people in our organization who handle customer data. But the answer to the coin, again, is no, it's just data. There's lots of different types of data that come in that we have to be strategic about, that we have to market sell, and there's a lot of things. So, again, we don't necessarily have an answer to that question that customer data is different from a governing customer data is different from governing other types of data within our organization. Are your customer data used in more decisions than other data? Well, maybe we are a very customer-centric organization and we have to, the customer, matter of the fact that we may not have a single definition of the customer, which is always problematic for those of you who understand what I'm talking about. But customer data, even though we may not have a single definition of the customer data seems to be used in a lot of the decisions within our organization. So I really, I guess it really depends upon your organization's business whether or not customer data is used in more decisions than other data. A lot of people in a lot of organizations think that their customer data is. They need to know how decisions that are associated with how to identify, attract, sell, service, to determine the lifetime value of customers, satisfy customers, what happened that caused this to lose customers. So, yes, customer data is used in a lot of the decisions that are taking place in a lot of our organizations. Again, the underlying customer that seems to be at the core of most of our analytics. In fact, an organization, an education company I was working with recently, Student, which is their customer basically. Without their students, they go away. Student is at the core of most, if not pretty much all of their key performance indicators and a lot of their analytical power is being focused on data about the student. So, maybe you could say, yes, customer data is being used in more parts of the organization. The other side of the coin, again, is no, it's not. We have all types of data, materials and employees and what do you do, which are your different buckets of data that you have in your organization that are used in more decisions that are used in the same amount of decisions or different types of decisions than customer data. So, is your customer data used in more decisions than other data? I'd be interested in hearing from you, whether or not your customer data, everything in your organization generates around customer data. Is customer data managed any differently? I'm going to kind of get through the rest of these questions. I think the general theme that's coming from me here in this webinar is, yes, it's managed differently. More attention's paid to the customer. No, we don't manage any of our data well. There are multiple occurrences of customer that are multiple occurrences of a lot of different types of data. There's not a single answer. We talked about that just now. Customer's just another domain of data. No, it's just data. So, my answer to the question is, is managing, you know, do we need to bring customer data differently than we need to govern other types of data within our organization? So, I think you can see where I'm at here. So, is your customer data more of a corporate asset? Yes. We think of it as being one of our primary assets. No, it's just another domain of data. We can answer a lot of these same questions the same exact way, but we think about it that way. So, again, what I'd like to see from you if you've got a moment to enter into the chat is, is your customer data different from your other data? And how do you think it is different? And do you govern it differently than you govern other data within your organization? Again, I'd be very interested in hearing from you if you have some comments on those questions. All right, should we govern customer data any different? You could leave a lengthy debate, which we're not going to talk about now, but customer data governance programs. Again, I've seen organizations that have defined things as customer data governance programs, but the reason that they did that was not because that was really all they wanted to govern. That was all they wanted people to know that they were trying to govern at least right out of the gate. So, we wouldn't have all the people in the organization coming to them at one time. They called it customer data governance. So, the question is, should we govern it differently or is it just another domain of data? And again, I don't think I have a single answer for that question. I would venture to say that it's very important to give to all of our organizations whether we govern it differently or we govern it the same from my perspective and from the organizations that I've worked with, customer data has been very important to them. However, we have not governed it any differently than they've governed the other types of data in the organization. So, what we're going to talk about in the remainder of the webinar here is we'll talk about what the stewards do with customer data or what stewards do with other types of data in the organization and how can we apply that specifically to customer data. So, we're going to start by focusing on what the customer data stewards do. So, if you recall from previous presentations or if you haven't been in previous presentations, my philosophy is that almost anybody in your organization could be considered a steward of data. We don't need to necessarily tag each of them on the shoulder and tell them that they are a steward. However, we do need to know where they are and we do need to know what data in the organization they define and they produce and that they use. And think about it. So, whether your senior management agree with that, would they agree that everybody in the organization could be considered a steward of data? Well, if you ask the question a little bit differently, I think they may agree. They may say, if you ask them, should everybody in the organization access the data or that has a relationship to the data be accountable for what they do in association to that data? In your organizations, I would guess that your senior management would want to know how you were going to do that, but they would say yes. People in your organization, they need to understand those regulatory rules and the compliance rules. They need to know that before they go out and create some additional data, that they're not just creating another occurrence and making the situation around your customer data more complex and more difficult to manage. Could everybody in the organization be considered to be a steward? I would ask that question yes, and that's, I guess, a little bit different than what you would hear from other people, but if your management thinks that everybody should be accountable for what they do with the data, then that's the answer to the question. They need to be at least identified as to what part of the organization they're in. They don't necessarily document what their name is, but they know that in different parts of the organization there are different types of stewards. Look at what their day-to-day responsibilities and activities would be. If you've seen what I've written about data stewards, their day-to-day responsibilities are going to be whatever is called for in their job. There may not be any specific activities that are steward activities for these individuals, but then all of their activities may be considered to be steward activities. If there are any things to define business requirements for a new project or to solve a problem, and they're focused on the data that's associated with that project or with that problem, that's just part of the job. We don't have to call those things governance activities. We can just call them whatever they are as issue resolution techniques or data certification or project management, all those things. We shouldn't call those things governance activities. Again, I don't like what that implies to the organization because then people start looking for reasons why does governance seem to stand in the way of success in our organization. Well, then everything's a governance activity. That's the reason why. But if you think about the people that steward customer data in our organization, they have a daily job. They define data and they produce data as part of their job or they bring data in from some other part of the organization or they use data for reports and for analytics. Shouldn't all of those people have their hands on the data that way have some level of accountability? Again, it doesn't mean that we need to go out and push data stewardship down their throat. But maybe what we want to do is we want to recognize them as stewards and maybe let them know that they've been identified or recognized as somebody who has their hands on this specific data. So we need to know who they are. So in case a business rule changes or something changes along the course of regular operations, we can communicate with them. So we need to know who all those people are. Maybe not their names, but at least the parts of the organization that define person use different types of data. These are involved in decision-making. There's a high level of scrutiny around the data that they use. A larger evaluation is based on how efficient and effective they are. That may not be... That efficiency and the effectiveness may not be their fault. It may be the fault of the data. So it's the same with other types of data and other domains and other types of data stewards within our organization. And certainly there's security, privacy, classification rules associated with their specific data in regards to customer data. And certainly needs to be some level of enforcement around the management, around the governance of the customer data as well as other types of data within our organization. Customer data stewards... I mean, we can call people customer data stewards or we can identify them as being data stewards of customer data. Is there a difference? We're not really sure. I mean, some people will tell you, yeah, probably there's a difference. There's customer data domain stewards or maybe we just have subject matter experts around customer data that we would allow as a customer data domain steward. Customer data definers, customer data producers, customer data users. We have got a lot of different definers, producers and users of data of different types of data across the organization. Do we need to set up a program or do we need to specifically focus on customer when we start to roll up governance within our organization? Maybe that's just the first domain of data that we want to focus on with the idea that we're going to try to take leverage as much as we develop from developing our customer data governance for other domains of data. So in the future, you may be looking to reusing a lot of the things that you use around customer around other types of data. So maybe the answer to your question is yes. Now it's more important to us. It's different to us. But when we start to evolve and start to cover other aspects of data in our organization, maybe we want to try to reuse a lot of the things that we've defined for stewarding and for governing customer data. So the question is, is there a difference? I would say, let me see how you do this. I would say probably not. And I like to use some of the word owner either. That's the reason why you see the X across the term. And our owner implies that it's mine. I can do what I want. Typically in a lot of organizations, the organization owns data. People are stewards of the data. In fact, the definition of steward is somebody that takes care of something for somebody else. So I don't like the word, the use of the word owner. Organizations have that kind of embedded into some of the things they do. At least some organizations do. Some will tell organizations not to use it if people understand what it means. Owner is different than steward. Steward takes care of something for somebody else. Actually, in one of the classes that I was teaching this week, somebody pulled up Webster Dictionary and showed me the definition of steward. And that's exactly what I said to them, which is it's somebody who takes care of something for somebody else. So you've got customer data stewards or you just have data stewards of customer data. So you may have seen this diagram before. This is probably one of the most valuable diagrams. There's a couple diagrams that I think are most valuable in the conversations that I have with folks like yourself. This is an operating model of roles and responsibilities. Down here, we've got our operational data stewards. And here, we've got our tactical data stewards. And as you can see, they're by business unit in the operational level. They're by business unit in the tactical level. But they are the stewards of the data. So we'll talk a little bit more about what is the role and responsibilities of those stewards and how does it compare from one domain of data to another domain of data. So this becomes a very valuable tool and I'm not going to spend the time talking about all the different roles and responsibilities that are associated with a business program. Some of you may have seen that before, but the reason why I put the words exist or leverage along the outside of the diagram is because I show this diagram to somebody. The first one is that this is very bureaucratic and that there's lots of layers. When the fact is that governance team may already exist. IT team may already exist. Your senior leadership may already exist. You've got people day to day defining, producing and using data, producing customer data so the operational levels exist. This area right in here, these two levels seem to be where a lot of organizations focus with data governance programs. Another diagram that I feel is really valuable to people and organizations as they start to put data governance programs together, they cross-reference the domains of data, the subject areas and you can see the data very prevalent in this diagram here. You can see the different parts of the organization across the top. If we recognize that this specific type of data is in this specific system and this specific person, for those of you that are just listening to this, that's being very helpful to you. What I'm doing is I have the common data matrix up in front of me. I'm saying that for a specific subject area of data that was on a specific system in a specific part of the organization, we may want to know who the person is or who the people are or just the fact that that part of the organization recognizes that specific type of data in that specific system. One of the things that I suggest to most of the organizations that I work with is that they focus on the common data matrix as something that they focus on very early on. If you're interested in a generic version of a common data matrix, I'd be interested in hearing from you. Please end the note saying that you're interested in seeing it or contact with me directly and let me know how you'd like to use something like this within your organization. But it becomes a very useful tool for most organizations that are implementing not only customer data governance, but other types of governance within our organization. So that's what I did, and I think this is the first time that I've done this in one of my presentations, is I kind of superimposed the common model diagram on top of the common data matrix. And if you can see, now this is color coordinated. How many does that, right? So we've got the different roles identified in the operating model, and I'm showing you where they're kind of highlighted also in the common matrix. So again, these tools, if you can define an operating model of roles and responsibilities, and you can identify where the people are in the organization and have those responsibilities, that's a step forward for data governance in your organization. And in fact, it's a step forward for data governance, whether you're focusing on customer data as your initial domain, as your primary domain, as your only domain, or other domains of data in your organization. So again, you can have these two things together, and we can then leverage these different roles and responsibilities. And we're not going to say before, that all titles of being data stewards or domain stewards or council members, they have titles already. They're already doing their job. We need to identify who they are, what their association with the data is, so that we can help them, help the organization have govern data as a result. And it's not the heavy-handed way. It's not the command and control way. It's what I call, and I talk about so often, non-invasive data governance. All we're doing is identifying and formalizing people's responsibilities rather than handing them to people as their additional responsibilities. So with that being said, let me spend a minute here talking about signers' rules for becoming a data steward. So before I visit the pages of TDAN.com, my publication, I write articles from time to time, and an article that I wrote fairly recently was really meant to be controversial. It was meant to kind of spark some air in some people that they would come to me and say, signer, you're wrong. This is not the way it should operate in our organization. I didn't get any of those. The ownership contacts that I got were from people that said, you know what, I can't agree with that as the approach within our organization. So let's walk through signers' rules for becoming a data steward. Anybody can be a data steward. I'll talk about that a little bit already because in our organization, if somebody has a relationship with data and they do something with data, we need to formalize that relationship. Oftentimes, in those conversations with those people, who we identify and recognize as stewards, their response is, well, you know what, I'm already doing that stuff. But what you should do is point your nose and say, hit it right on your nose. You're already doing it. That's why we've identified you as being a steward because the organization has told us that everybody needs to really be held accountable, that we need to build efficiencies and effectiveness into how we manage data as an asset. So that's how we've identified you as being a steward. So basically anybody in the organization can be a steward. Being a data steward describes a relationship to the data and it's not a position. In fact, just to skip to the fourth rule, a data steward does not have to have the title of data steward. They're not given a title of data steward. They're given a title, they're not given a title. They have a title. Their title is whatever it is and the fact that they have a relationship with data is what makes them a data steward in the first place. So people in the organization that define, produce, and use data as part of their job, and that could be basically anybody really considered a steward of customer data in the organization. They don't use customer data. They're a steward. So we need to help them. We need to educate them on what the rules are. We need to help them to not define the data at a hundredth time. We need to help them rather than add some additional burdens to them. And it's definitely a difference of philosophy around the governance. So let's focus on helping people instead of giving people responsibility. Let's criminalize the levels of accountability of whatever we can. There's not additional accountability where it's not taking place where there is no accountability. Those are part of signers' rules for becoming a data steward. A data steward does not have to be told how to do their job. And the public certification of data steward is not really valuable. I mean, I can see organizations certifying data stewards within their own organization. So today we want to certify the regulations that we know that we need to comply around customer data. And all the specifics around what's the single point of truth? Where's the system of reference for customer data? Let's educate them on that. Let's certify them internally. But somebody outside the organization can't do that. So a data steward does not have to be told how to do their job. The certification is a little bit bunk. There's more than one data steward for each type of data. And data steward training should focus on formalizing accountability, not handing things to people as new and over and above what they presently do within the organization. So somebody, it may feel like it's not just one person in the organization that's accountable for that data. There's a whole lot of people that are accountable for that data. So therefore, there's more than one data steward for each type of data. So somebody, it may feel as though it's an old work. But the fact is, hopefully, it's just things that should have been formalized or been done formally all along. Certainly, there will be a feeling of, well, this is over and above. So do everything that you can to eliminate that feeling or kind of minimize that feeling from people across your organization. How about the responsibilities while data steward, they're responsible for doing their job with formal accountability for the data they define, produce, and use. Understanding the impact, their impact to the quality of data and usefulness of that data across the organization. Understanding the meaning and the priority of governance for the organization. And these two bullets may be the most important bullets that are out here. They have the responsibility to change business requirements to individuals that are going to be impacted. Communicating concerns, issues, and problems with data to those people that can influence change. So the operational data stewards, these folks down here at the bottom of the pyramid diagram play a key role in your organization, obviously, but they're not being engaged in the decision as to how we are going to certify the data that goes into the data warehouse. They're not being engaged in your organization that don't engage the operational data stewards. More and more they engage the data domain stewards. So the operational stewards exist here on the common data matrix where in their part of the organization they use that type of data. That's where the operational data stewards reside. The common data domain stewards. So these are the domain stewards that have responsibility for the data across the organization. So they're not responsible for customer data just within their part of the organization. They have the responsibility for the enterprise view of customer. An client came up to me at a client several years ago when we were having a very hard time identifying who we are customer data domain steward and he said, look, I don't know customer data across the organization. I don't know it for everybody in the organization how they use it and how they define it but I will be a willing facilitator of bringing people together to define this, to make sure that we do things at least from a customer domain at least from how we define customer so when our management wants to know how many customers we have we can actually answer that question. This is that person. It's a person that knows this data or can facilitate an agreement in this domain so they're responsible for enterprise management of the data rather than the operational view of the data so they are on this side of the blue line in the common data matrix meaning their view is across the enterprise rather than siloed within one specific business unit and all organizations. This is the most difficult hurdle to get over in organizations identifying the people who are going to be the domain stewards or even specifically the domain stewards for customer data. By position often they act in the role of the domain steward their affiliation to their business unit becomes secondary so they probably reside in one of these parts of the organization however when they're playing this role they understand that they're working in the interest of the organization and not just their specific business unit so they're an involved facilitator in the cross-business unit resolution of data definition production and usage issues pertaining to customer data. They may or may not be the authority and if they're not the authority then and we're not going to talk a lot about it here but this data governance council that a lot of people talk about that the authority that's why you see this era that goes up along the right side of the pyramid diagram it's the escalation path so these customer data domain stewards may or may not have the authority to make decisions pertaining to that domain of data if they don't then we need to be able to bump it up a level to a strategic level or to what a lot of organizations will call their data governance council or data governance board or data governance committee or we're naming they use to describe that role of data governance within the organization. Additional responsibilities of the customer data domain steward or really any other domain stewards that we have is possible for escalating well documented issues to the strategic level with or without recommendation that strategic level that's the data governance council we just talked about. They're possible for documenting classification rules, compliance rules, business rules for the data in their domain in this data domain that we're talking about being customer data so back earlier in the presentation I gave you that list of privacy laws there's other laws too there's other rules that need to be documented somebody has to take that out of the books and make actually something that's active within our organization and communicate with all of those operational stewards that define producer use that specific domain of data. They're responsible for making certain the rules are communicated for participating in tactical groups to solve problems different from a domain steward or any other domain of data is what they do. I would say this is a good description of what a domain steward or an enterprise data steward or what again you call them in your organization there's pretty much the responsibility of any type of domain steward not just a customer data steward. So going back to the common data matrix I talked about the data domain stewards being associated with the domains partners or IT having knowledge as well and I've always said that it's it'd be ridiculous for us not to take advantage of the knowledge that IT has around the data so we need to know who they are are they data stewards? No probably not but they are data subject matter expert system subject matter experts we need to know who they are the government council is by business area steward coordinators by business area that's another station for another day but operational data stewards are where the rows meet the columns and we need to know who those people are not only for customer data customer data but we've got product and service data we've got a lot of other different buckets of data that we use within our organization such as an example again color coordinated with the common data matrix and the pyramid diagram of how we take advantage of utilizing these people so in a master data certification and a customer data certificate process these may be the steps that we want to follow these may be the different roles that we define in our pyramid diagram and this is whether or not these people are informed accountable consolidated responsible supportive however you use racy or don't use racy in your organization perhaps in one of these blocks you want to say what does this role do in that step what does this role do in that step so it makes becomes very clear what this specific process is and how we are going to involve the different people that we've defined as part of our governance program as part of that so just to get here to sum up and to take some questions hopefully there are some good questions out there messages for management you know let's stay noninvasive let's focus on being noninvasive so we're already governing data but we're doing it informally we can formalize what we're doing we can improve these things we don't have to spend a lot of money to do this it really costs us the time that we put into it and we really need some structure that's what we really need in order to put a governance program in place in our organization additional message is let's not fill this program as being a huge challenge so if we tell it that way that is what senior management is going to understand but if we do it for them and say we're already governing data but we're doing it informally I have a way of formalizing this without being the iron fist that comes down and smacks people in the head or the two by four as I often refer to it data governance is not a technical solution there are a heck of a lot of good products out there that will help you to enable your organization with data governance but it's not a technical solution it's a people solution if you implement a tool or a product it will assist your governance program but it will not be your data governance program solution people's behavior is what we're really governing we're not really governing data so maybe we should call it governing customer people instead governing customer peeps that's what we're going to call it data governance is an evolution not a revolution we talked about that a little bit earlier as well we talked about the fact that we may start on a domain of data we may start on a subject matter of data like a customer or something else but it's going to be an evolution we're going to once years ago said and you may have heard me say it before but that don't let perfection get in the way of good enough let's define the program as an evolution and see what's working for us and what's not being worked for us and let's move forward with putting governance in place and not making a revolution within organization so the last thing I want to share with you before we take questions is the most recent article that I put in the TDAN publication and again if you don't know of the TDAN publication please go out and take a look at it but I call it the data governance bill of rights and what the data governance bill of rights getting the right people involved with the right time in the right way using the right data to make the right decision leading to the right solution well at least most of the time right so a copy of the poster that's shown on the right hand side please let me know that and I'll be able to send you out a copy of the poster and you can proudly hang it above your office or your cubicle or wherever you work but it's the data governance bill of rights again getting the right people involved at the right time in the right way that's what governance is all about at least from my experience that's what I've seen governance being all about and so just to remind you now the next three webinars next Thursday of the month is October 17th we'll be talking about managing governance metadata for mass consumption we're going to talk about some of these tools I just went through and more of the specifics about the metadata that you capture and those tools, governing data governing data, governing small data just for everybody to hear that conversation that's going to be interesting because I have some interesting perspectives on big data and data governance so please tune in for that and the other one is how do we manage the expectations of the people within our organization that's how we manage the expectations of our senior management all the way down to the from the executive level all the way down to the operational level and everywhere in between in that operating model so that's I'm going to turn this back over to you and do we have any questions today? Looks like we have one going in the chat and just to remind you the most popular question of course is will people get the slides and we will of course include the slides, the links to the recording and a follow-up email that will go out by end of day on Monday and it's already been a request of course for your matrices so we'll get that out to you as well there's a question in the chat so go ahead and submit your questions to the Q&A section in the bottom right-hand corner there for me and there's a question that came through the chat just how do you approach defining additional data stewards for a subject area such as customer would you create sub-areas under main area? Yeah, that happens quite a bit and so in organizations when they're defining their their main buckets of data their domains of data or their subject areas of data customers are really high level so sometimes they break the customer domain down into a sub-domain we've got customer address information we've got customer transaction information we've got PI information for the customer we've got all these different subsets and certainly for an operational data steward if you're going to identify who uses those specific subsets of customer data the only difference is that it makes your program a little bit more granular than that higher level domain but that granular can be a really good thing and there are some organizations that started with data elements built their domains out of working one handful of elements and they kind of flushed out their domains and if they kind of broke their domains into sub-domains as well so yes, it's certainly all right on the domain steward side to even have people that know or more of the authority around a subset of customer data than all of customer data so we have domain stewards for sub-domains of customer and we also have data stewards where there's people that are out there in our operational areas and we only use a certain aspect of customer data so does it have to call them something different? No, we don't need to call them anything in fact we just don't know that they exist but if we know more particulars about what data they define, produce, and use we can communicate with them more effectively so it's really up to you I won't tell you to stay too high level I won't tell you to get too granular the beauty of the common data matrix and even some of the other tools are that you can really design it the way that you want to design it within your organization and if you need to know about subsets of customer data and maybe even different types of customer if you want to go that far that's another way of looking at it feel free to kind of move that in any way that you need to make it useful to your organization Another question when you have management support through an information governance board how do you get the operational and domain steward to participate? Well, one of the first things that you want to do is you don't want them to one of those meetings thinking that this is over and above what they're presently doing you want to in some way shape or form convince them that a lot of what they already do is steward activity they may not identify it or recognize it as being steward activity they may not identify it or recognize it as being steward activity they may not identify it or recognize it as being steward activity but again, if they're being formally held accountable for it then they need to know who they are so it's not as though they can inter-opt out the fact is they are operational data stewards whether or not they want to do it or not now the domain steward may be a little bit different because the domain steward seems to have more say or at least has a broader view of that subject of area data across the organization you talked about that center level of the pyramid diagram as being the largest hurdle to get over for a data governance program well maybe you already have a subject matter expert or you have subject matter experts about different aspects of customer let's identify who they are let's ask people who they go to when they have a question about this type of data or that type of data that's typically going to be your subject matter experts and that's what we call our subject matter experts if they have a sub-level authority or at least some responsibility for facilitation around that data they're the subject matter expert for let's formalize that so one thing we want to avoid when we're going to the operational stewards and the domain stewards is to let them think that this is difficult this is over and above this is going to change their job and if they come out with that perspective then I think we need to resell it to them and take a method that is less invasive or I should say non-invasive the way that I always talk about for the questions today everybody thank you so much for attending today and your time and Bob thank you so much for another fantastic conversation and another presentation we even had an attendee who was waking up at 3 a.m. to attend your session here so that's quite impressive thank you Gabriel and to Data Governance just as Bob mentioned I'll get just again I'll get the slides up to everyone and the links for recording and links to the agencies by end of day Monday and I hope everyone has a great day can I say one more thing? absolutely you're still on? I'm still on I'm going to do what I said which is all the comments that were through chat I'm going to try to address some of those and kind of put together a summary of what people told me their thoughts were to the primary question that I asked at the beginning of the seminar so we'll include that in the email as well awesome love it I'll get a copy of the chat up to everyone and I'll get this to you right away and Jillian, thank you Rock and again thank you everybody I really appreciate it I just really love these sessions have a great day