 Hello and welcome. My name is Shannon Kamp and I'm the Chief Digital Manager of Data Diversity. We are proud to produce this webinar series of Data Governance Case Studies for the Data Governance Professionals Organization. I would like to thank you for joining today's CGPO, Data Governance from Chaos to Harmony sponsored today by Calibra. And as you can see, WebEx has undergone a significant UI update. Feel free to look around. You'll find most of the needed icon buttons in the bottom middle of your screen. There's a couple of points to get us started due to the large number of people that attend these sessions. He will be muted during the webinar. For questions, we'll be collecting them via the Q&A panel in the bottom right-hand corner of your screen. Or if you'd like to treat, we encourage you to share how it's a question via Twitter using hashtag DGPO. And to find and open the Q&A panel, just click the three dots icon in the selection of icons at the bottom middle of your screen. And if you'd like to chat with us or with each other, we certainly encourage you to do so. Click the chat icon, which is likewise in the bottom middle of your screen. So let me turn the webinar over to Michelle Cook from the Data Governance Professionals Organization to introduce today's webinars and speakers. Michelle, hello and welcome. Hi. Thanks, Shannon. It's good to be here again. And a reminder for our attendees, the recording for the webinar will be posted in the DGPO members-only section of the DGPO website in a few days. So the Data Governance Professional Organization is a community of Data Governance Professionals whose mission is to share knowledge, content, and best practices with its members to build a community of practice. And that's why we participate in these webinars every month. To learn more about the DGPO, I welcome you to visit our website at dgpo.org. Now, a word from our sponsor, Calibra. And presenting for Calibra is Erin Lowe. Welcome, Erin. Thank you, Michelle. And good morning and afternoon to everyone. I appreciate your time and am excited to briefly introduce you to Calibra. Our webinar topic today will be addressing how introducing enterprise data governments to your organization and multiple stakeholders can be really challenging. And there's a natural pushback as organizations need to buy in to change or was perceived as additional work. At Calibra, we have found in our conversations with our champions and at our client organizations that demonstrating true business value has been the easiest way of gaining alignment and kind of knocking down that wall. Of course, data governance can also deliver efficiencies for everyday processes, but truly helping an end-business user execute better and be the hero is what we are looking to enable through data governance. So we're really excited to hear Sean speak to how JL accomplishes this. Also, at Calibra, we are the leader in the data governance and catalog software space, helping organizations globally gain a competitive advantage by maximizing the value of their data across their enterprise. And we are the only purpose-built solution to address the needs of the data citizens, including data stewardship, governance, and management needs of the most complex and data-intensive industries. Our flexible and configurable cloud-based on-premise solution put people and processes first, so it's really about empowering every data citizen to be able to find, understand, and trust the data to unlock business value. So really being grounded in data governance, our perspective on data governance can be summed up as data is a raw material and governance data is an asset for your organization. And in today's world of data privacy and concerns, ungoverned data is really becoming a liability. Organizations need data governance and it's becoming a mandate across the teams as there's a digital transformation, digital growth, really a lot of data flying around everywhere in front and center as we've seen through Gartner's report and study of global CEOs. It's what CEOs are now saying they need their IT departments to really have a larger impact as this continues to grow. And today's answer for unlocking the value of data through BI and data management really isn't sufficient anymore as additional challenges still remain. How can my end business users find and understand the data that's out there and at their fingertips if it's even available to them? Why should they trust what is being presented to them? Unfortunately, a lack of trust leads to a lack of consumption or adoption which is counterintuitive or not beneficial to the organization. We talk about this as everybody's becoming more data-driven. And we touched on this before but managing risk around data today is really at the forefront and protecting our customers and their data can be seen as the ability to build a stronger relationship than trust. So where can we turn to? At Calibra we see it as providing foundational governance with a strong operating model and sharing best practices, having a set process flows and policies to ensure that data goes through these rigors and can be trusted. A robust solution for stewards to perform their tasks and enrich the data. The ability to add in reference data and finally the ability for owners to or the data owners to be able to certify their assets. And if you think of data governance as a journey and what you're really aspiring to of creating that business value, you actually look at it to create data experiences one day and with the help and adoption create that business value for multiple stakeholders across the organization. So at Calibra we strive to help our data citizens find, understand and trust their data through our purpose-built data governance platform. And whether your data is in the cloud or on-premise we offer the tools that efficiently organize your data through processes and governance to help those. Data scientists effectively spend their time optimizing and surfacing assets with the data versus just finding the data. And with governance as a foundation you can provide your scientists with an analyst with the time savings and risk management eventually creating value in ROI with end business users and even creating new revenue opportunities in a safe way or manner. So Calibra is a leader in data governance and it's because we've had this singular focus. We are recognized by Forrester and Gartner as a leader in this space. And as we know that data governance is a journey we employ many resources to help what we consider data citizens improve their journey and we built a community of experts out there such as yourselves to have these conversations with each other and share ideas. We offer university courses, personal one-on-one coaching and best practices as well as agnostic approach to the ecosystem where we understand that one organization's solution fits everybody else's needs. So being able to partner out there with the leading technologies. And just a quick glimpse into in addition to offering a business glossary and dictionary for organizational alignment we also have the ability to surface reports with ratings and recommendations tools that encourage collaboration. We have features that can help you import data quality scores linked to assets for easy usability as well as to improve your view of lineage and robust diagrams. Then finally we look to certify workloads, the policies, everything that makes things easier and instilled trust by the end user. So I encourage everyone after this webinar to join our community and continue the conversation as we have organizations in the same position as you looking to develop their data governance initiative and how to get started. And with that I'm going to hand it off to Sean to kick off his presentation. Thanks Erin. This is Michelle. Let me introduce Sean before we get started. Sean is from JLL. He's the Vice President of Global Data Governance. He studied Computer Operated Business Information Systems at Howard University in D.C. and had a unique opportunity to work in a family business developing a budgeting system for colleges and universities. He built upon that experience creating similar systems for country clubs. So realizing that his true passion was the data captured by the applications. Sean focused his journey in the data arena. From database administration to data architecture to business intelligence and finally data governance, Sean has served in all roles surrounding data. He earned MBA degrees in finance and marketing from Drexel University to increases business acumen and he combined those degrees with his data skills. He's helped Fortune 50 and Fortune 500 companies such as Comcast, JLL and DeVita realize improved data quality and real value from their data driving revenue gains. So it's my pleasure to introduce Sean. Thank you for presenting for us today. Thank you, Michelle. Thank you Erin and Shannon as well. And everyone that's on the call hopefully you'll be able to get something meaningful after the presentation. I know we have limited time so I'm going to go ahead and get started. There'll be some time for questions and answers after the presentation. Okay, so the topic that we're talking about data governance from chaos to harmony. I titled this a JLL case study. Basically what we'll be doing is kind of going from our journey five years ago when we started our data governance organization by Jones Lang LaSalle as a formal organization. And this is kind of the things that we had to go through to get to where we are now. So it's not one specific item that we went through but a collection of our experiences. So a little bit about Jones Lang LaSalle. So a Fortune 500 company. We're a professional service firm specializing in real estate and investment management. And I'm going to try to make sure I don't talk too fast. I have a tendency sometimes to do key tricks and talk too fast. I'll make sure I keep the pace. We have about 82,000 employees. It's a global company. So we'll have all the challenges that you have with a global company of different cultures as well as different types of data that's going to come across, different types of data values that are going to come across. So we'll get into that as we go through the presentation. So this is just a quick slide in its size. Kind of tell you about the complexity of the data as well. So this is me. Like she said, Vice President of Global Data Governance, Corporate Solutions. I've been in JLF for four years and our department has been about five years. The phrase that I like to kind of go by and I know my kids are tired of me telling this to them but how you do anything is how you do everything from T-Heart, ECR, basically saying even in the small things practices that you have in the large things to come and have the forming that you're actually doing the right things because how you do anything is really how you do everything. So let's start off with the beginning. So we talk about a journey. A lot of times when we talk about data when we give presentations, people on our team may have seen some other people on my team present. We always talk about a journey and so we talk about where we are and where we want to get to. So in this particular case, we're talking about a journey from a chaotic situation, chaos to harmony. And so here's where I'll give a quick disclaimer. I think it's when I first made this presentation and I put out the term chaos, I was told by some of the people I worked with to just be very careful that I wasn't offending anyone. So I don't want to offend anyone and say that chaos is really what this definition says here complete disorder and confusion because that's not actually the case. You very rarely will find a case that comes to the extreme. More and more correct or more to a point there's some type of disorganization going on, maybe some confusion going on. So I wouldn't say that we came into JLL. There was chaos, a complete chaos, but there were some situations that were very in need of somebody coming in and alleviating some confusion, putting some standards in, putting some order into the situation. And I think you'll see the same thing where you work. You feel like at times that this is complete chaos, but the reality is there's probably some things that are working and there's probably some things that really aren't working. And so that was one of the ones that we're going to take a challenge on. And other things that are working, and that's where it is. So let's talk about chaos and we want to do it through the lens of data governance. So looking at the lens of data governance, some things that we can look at as chaos, siloed lines of business. Now that can be a look at as a chaotic situation, but it also can be looked at as, you know, something that's being successful. There are a lot of businesses that are siloed on purpose. And that used to be the way a lot of businesses ran. You know, I ran, this is my lease administration system, property management system. We're doing renovation projects to have their own system or their own line of business all the way from somebody who leaves the business to marketing sales all the way down to whatever kind of data governance activities that they're doing. And that's fine. That's what they want to do. They're running their business. They're being successful. And it's kind of hard to look at them and tell them they're not doing it right because the bottom line is that they're being successful. And so if you look at it that way, the siloed on businesses are successful. But as we have evolved in businesses and we've seen the synergies that we can get, and in fact, have the demand from our customers come back to us and say, we want you to be able to share these data, this data that we have across these systems so that we can actually find synergistic gains from this data. Then we started getting challenges on the data governance side of saying, you know, how are we going to share this data across? How do we define, say, for example, a customer across all of them so we know that this customer is the same as this customer is the same as this customer? All those things started becoming data governance activities. A lack of standards. So what do we call a data? A very clear example could be, how do we call the United States? One person may call the United States in their system. Another person may call it America. Another person may call it U.S. So just in that simple example, we have three different ways somebody has decided to define a country and what it's referred to. Now, we can easily hear it maybe as Americans or that we know what that means or anywhere else somebody may be able to understand it because it's very popular, but when we start getting to other things, it doesn't become so clear and you may have different ideas of what that is. And so the lack of standards start becoming more pronounced in those cases. So that becomes an issue. It could be a very chaotic situation. One we came across was CASEL. And CASEL could be anything. So if you try to standardize what a CASEL is, could you really do it? It may be an entertainment thing for somebody to look at as a property type. It may be a business office. It could be a bunch of things. And so standardizing becomes an issue. And finally, data quality issues. So what is the quality of your data? Are you actually addressing that? To know the quality of your data? Do you have the business rules? Do you have the validation rules? So all those are key that come up. And in the lack of having these things, you have what most people would term it as a type of chaotic situation. So let's go into getting a little deeper in there. We talked about this lack of data integration across applications. Duplication of responsibility. So you have all these different lines of business that have traditionally worked on their own. So you have each one of those people doing similar things. And in the case that we had, we have data governance coming in again doing similar things as well. Inconsistent data. So having the data that is represented in one system, not consistently being represented across all the other systems, maybe different values, maybe different standards. No communication. And this one is a big one. And I hesitate to say anyone is bigger than the other one, but when you have organizations or parts of your business that don't talk to each other at all, by the time that's maybe the first place you have to start to be able to open up that line of communication so that people can work together. Now I have an example that we came across here at JLL. And then the final one, unclear and non-existent data governance processes. So how are you introducing new concepts? How are you approving new things that are brought into the system? Do you have you identified who the stewards are of data? Have you identified it? What number of people need to vote on the data? Who your subject matter experts are? It all falls under there. Here we go. And so we're at the end of our journey. So we know where the beginning of our journey is. Let's talk about what we think that end of our journey is. And so I use the term harmony, agreement or concord. My favorite word is consensus. Consensus is not necessarily agreement. It basically means that no one has a strong disagreement. So we may not all be able to come and say, okay, I agree that we should all call everything United States. But we come to a consensus to say that our standard may be United States. You may not have all of our systems that can agree with the standard. And so a common argument that I hear from data governance people is, if I come up with a standard and everybody doesn't adopt it, is it really a standard? And there's a whole bunch of different answers to that. I won't get into whatever the answer is to that debate. However, what I will say is there's reality, right? And then there's utopia. So if we look at it from the pure data governance perspective, we say we come up with a standard. Everybody should be able to have it. The reality is people are running their business. Their systems are connected to other third-party systems. They may not be able to adopt your standard at the immediate time that you came up with that standard. And so therefore maybe there's some other workaround using reference data solutions where you're able to take the data that's in that particular system and map it to a standard so that you have systems that will know that when this system is talking about a customer, it's this. And when this system is talking about a customer, it's this. Or a better example I find I can give is property address, right? And so the property address in one system may be the physical address and another one may be something that's a contractual address. So we'll just look at it. We're looking here and we're talking about harmony. I'm basically talking about consensus. So data, and we always put this in our presentation. So we can go all level set what we think data and when data is useful. And it's kind of in line. You'll see a lot of the similarities with some things that Aaron talked about because we all agree to a very high level of what we're trying to get to. So data is only useful when it's clearly understood. We know this is the data we have. This is what the values mean. It's accessible. People can actually get to it. I think there was a portion that he showed on his slide. Finding the data. That's important. Protect it so there has to be some type of security. Making sure the right people are able to see it and the wrong people aren't able to see it. And that the data is trusted. If I look at it today, it's going to be the same thing as I looked at it when it was yesterday. And I have all of the data values and things like that. And so we have to have the structures in place. The mandates mean there will be times when I tell you do you have no choice but to do this. Processes in place. We've talked about the structure. So what is the structure of your data governance team? Is it distributed? Is it all in some type of central organization? These all become important. And then what platforms are you going to use to do your data governance processes? One thing to talk about on structure. So let's kind of look at the example of we had. So we were a new organization, a new part of a longstanding organization as it came in as a data governance group. So three people, I think, is what the organization started off. Ho-Chun Ho was the leader and two other people. I came shortly after that into the organization. So about four or five people new to the organization. We don't know anybody. We haven't built any relationships. And we're coming in saying we're going to do data governance inside this organization. So there's a lot of resistance there. There's a lot of personality conflicts that could come up here. There are people who had responsibilities for data governance before we came in. Successful people. So you can't necessarily assume I'm going to come in and be the savior for this organization because if you come in with your attitude, you may turn off a lot of people and you may not be able to get anything done. So the first challenge when you come into the organization is to get people to, I hate to say like you, but it's almost that. It's almost to be included into the conversation of where you need to put the data governance processes and activities. Because until people actually like and trust you, you have a hard time getting into the meetings. And that's what we found. So we spent a lot of time in the beginning getting to know people, meet people, and before we could even get to the data governance process part. That's people skills. That shows the importance of people skills. So here was our challenge. We had a business that was very successful but to a certain degree very siloed because it's just the way the world was running, right? The lease application, they specialized in leases. They did everything they needed to do for a lease and top of the industry. Same thing with projects, with the running renovation projects and things that were very successful. And then there became the need to say, well, you want to be able to do business KPIs and analytics across all these systems to find where the opportunities are that one system's data inform another line of the business. And so the thought was we'll come up with this that goes across all these KPIs, right? We'll have some type of multi-platform data environment. We'll have some type of master data here for all the properties that go across all these systems. And we'll have reference data. We know we have third party systems that we have to bring in. And when we do this, all the data come in and work harmoniously, right? And that's the thought, right? That's not the reality. The reality is there's a lot of complexity in bringing all these together, right? And so you'll see that, and what we saw was in a lot of cases, some of the assumptions that were made across these systems, it just didn't work. And so that was our challenges. We had very capable people, but maybe they just needed some direction from some data governance experts to come in and just kind of guide the process in a certain direction. So not to say that we knew anymore than anyone else, you know, it's just a new role, a new task, a new job that had to be done. Let's talk about the first thing, breaking the silos. That's the first thing. Like I said, you come in with a new organization five years ago. We're walking in. These teams have been working very well. They're successful. And now you're saying you all have to work together, right? And they're like, we don't have to work together. And so here's the things that we're going for. Business and support teams, collaboration. The big key part of that is collaboration, a shared responsibility, a common understanding of the data, and where are the opportunities to integrate your systems. So the story that I'll talk about on this one is whether teams feel like they need to collaborate. There's a whole bunch of issues that may be existing inside a company when you come in. It could be personal issues. Like, you know, they make people really not like each other because of something that happened before you came along. It could also be just a distrust. Like, we feel like we're better than that group. And we don't, or we don't know that group, right? So we don't know what they're doing. Or we have enough work on our own. Why do we have to bring in another group and the complexity of that group and things like that? So all of those things were going on when we came in. There was a specific issue that we had to, we came across, and it had to do with addresses. So there's two different systems. There's a property system and there's a lease administration system. So if you think about that, there's two different teams. There's a lease administration team and a property portfolio team. And like I said, they're all doing great jobs at their individual systems. And now these systems have to actually meet with each other. So the first thought could be, I'm just going to give you my data and you just pull it into your system. Now, if I do that without communicating with you, there are a couple of issues that could come up. One is, I will get your data and I won't understand it. Or maybe I'll misunderstand what you sent me. So if you send me something that is called equipment code, and I have something called equipment code, I might think it's the same thing. But it may not be, right? And so therefore, because we didn't communicate, I'm pulling that in and then maybe six months down a line, I figure out, oh, wait a minute. Are you telling me that your equipment code is the same as the equipment code I have when the same company? But you know, one person may have taken it for one system and one from another. So that's common understanding of data, right? And so we came across that issue. But the big problem was the teams did not want to meet. They didn't feel like they had to meet. And you also wonder whose responsibility is it to know. You gave me this with the equipment code. Should you put a definition in there before you send it to me? Should I have to come to you and figure out what the data is? It's your data. You just told me what it is. So it was very clear. All those things come up. But the problem is the company really needs to know, right? The company that needs you to figure it out and the reality that we came across was the teams did not want to meet. So I literally had to get on a plane and fly and meet with people, maybe even go to lunch. And this is something I brought up in a previous conference when we had this conversation. You know, these are the people skills that you don't necessarily talk about when you're talking about how we're going to do data governance. By coming down and sitting with people and making a personal relationship with them. I'm not saying a deep personal relationship. We're not doing Thanksgiving or Christmas together. But just letting somebody realize that you're a human person. And, you know, now when they look at you, they're saying, oh, that's Sean with it. No, the two kids, Cheo and I, she's there in sports and one is acting. I mean, now you're a real person. And then maybe they give you the benefit of a doubt when you're talking about, I need you to meet with this other group and realize that you can't solve the problem without meeting with them. And so in this case, we had two different properties. The way lease administration works is the property on the lease administration side has to be what's on the contract. It's just the law. And on the property side, you're going to put the address, the real physical address. So I'll use an example. I live in a place called Lavrock. And that's what we call it. We have a sign up that says, welcome to Lavrock. However, if you go to any post office system, it will say it's Glenside. So the people in the town call it Lavrock. The post office system will resolve Lavrock to Glenside, Pennsylvania. And that's just fine. If I mail your letter, it'll get there as Lavrock and it'll get there as Glenside. But we have two different addresses. So if I go into a contract for a lease, I'm probably going to put Lavrock. I'm the homeowner. I'm leasing out my home. I'm going to put Lavrock there. The post office, when they put the system down and they go through something like address doctor or something to figure out what the real property address is, they're going to put Glenside. Same property, two different addresses, two different systems. Now I've decided I'm going to integrate these two systems. Now here comes my problem. I'm in the lease administration system and I'm trying to look up this lease to see if I want to add a new one. And I type in Lavrock. It goes to the property portfolio system and see, do you already have Lavrock in there? Does address it Lavrock? No, it doesn't. Turns into Glenside, creates it, comes back. Sends it back to the other system. The other system says, okay, I have the address for Glenside. Now I go to look for it again. Lavrock, let me look for it. It looks in the property portfolio system. So it still doesn't see it. It just keeps changing it. And so that's the problem we had. The two systems had to change the way they operated. However, they each saw it as the other system's problem. We were able to break down the barriers, have a meeting. Everyone saw that it was a shared responsibility. We were able to store the addresses for both systems on both sides. So now when you do a search, it'll search both systems for both addresses and it resolves correctly. So again, it was really just a case of getting everybody in the room. Everybody involved was highly capable. Very, very skilled professionals. It was just getting them to see that the problem could not be solved with just one side. Just breaking the silos down. Classic example of being able to break the silos down. The next part would be data standard consensus. Maybe when you're starting your organization as we were, we had to introduce the concept of data stewardship groups. This was already being done informally in the group. And so what we were talking about was creating formal data stewardship groups where people across the different parts of the company would come across, come together, and they would make decisions on data stewardship activities. We wanted to come up with company standards. We wanted to understand which industry standards we wanted to bring in. They didn't exist. Maybe we actually become part of boards and start creating them, right? And then what reference data we wanted to bring in. Reference data, being systems that have context from the perspective of an application or some specific part of the organization. When you're thinking from an application or a third-party data, we could say that to be reference data that you would kind of map to a standard that you have inside your organization. So getting deeper into data stewardship groups, what are some of the different things that we had? What was chaos in our organization? One, people weren't used to working together necessarily in data stewardship groups because they were in silo parts of the organization. I might not care what standard that you had in your system if all of my personal and management incentives are all from my line of business, right? I don't care what value you use. I don't even care what standards you use. I know this is the value I have to use for my system and when it comes down to make a judgment on whether I did my job or not, they're going to judge me on what I have inside this system. Furthermore, if you tell me that I'm wrong and you go around telling other people that I'm wrong, you make me look bad and I know I'm not doing a bad job. So some of the things that we really had to be careful was one, the message that we were putting out is we said somebody was not using a standard and they should be. We had to make sure that the message was clear that maybe they had a reason why they weren't using a standard. If we wanted them to use a standard, you don't want to throw anybody under the bus. So you're building relationships back to that people's skills part. And so we brought everybody in data stewardship group and I'll be honest, when we first started, it was very quiet. I would host the meetings, you know, people across the world. So inconvenient times for some people. Very new concept. And it wasn't so much that they didn't want to participate. Maybe they just didn't know how. And I just know it was very quiet in a lot of those original meetings. What do you think about this? We're going to use this as our standard for country. We have this property type. We have this subtype. And here's where we're going to feel like this subtype maps, like maybe castle maps to entertainment, multi-purpose building. Does everybody agree? And you get silence, right? So you're not actually getting people to participate. What we had to do, again, going back to the people's skills, was build trust. And sometimes that was sitting down, flying out, meeting with somebody during the day, maybe all going out to lunch as a group, just to talk and get to know each other. But it broke down a lot of those barriers. And then once we realized, we're not trying to throw you under the bus. If we're telling you about data governance or data issues, we're all trying to make sure that we address them, but in a way where we're not trying to make you look bad. I think we all know that our data is not perfect. But we don't want to come off as if we're these savers that are coming in and you've been doing such a bad job, because that's not the case. 99% of the time, that's not the case that people are doing a bad job. It just needs to be a little bit more redirected into a common focus. So that's what we came up with. So now we have a data stewardship group program. And it's successful. It's running and people know their roles. We know who our stewards are. We know who our subject matter experts are. We know who actually is like the administrator of the system. And we do use Calibra for our reference data. I'm doing that. You feel okay saying that we are using them as a system for mapping our reference data, kind of managing our data stewardship activities and our approvals. Data quality being the next one. It's different ways you can do data quality inside your system. You can buy a data quality tool. Or you can build a data quality tool. The important part is being able to have the business rules and the validation rules that actually will power your data quality tool. In our case, we thought it would be better if we built a data quality tool. So that's what we did. We actually won an award inside of our organization for the data quality tool that we built. We wanted to build it ourselves because we wanted the flexibility to be able to do certain things. There are a couple of issues that come across. One is license. You know, if you buy a tool outside, can you have other companies as your client? Can you actually give them that tool? Now, those are things that we came across and had trouble doing with other systems, but if we built it ourselves, then we don't have that same limitation. Being able to customize it towards a different company. The larger company is building it across for everyone. So it depends on what you need for your data quality tool. You decide whether you would build or buy. In our case, you decide to build. So to kept us agile on our feet and able to do the things we need to do. But that's also one of the kind of things that we'll all have no matter if you buy or build coming up with business rules and validation rules. So you need to again bring your approval groups, your stewardship groups in, and having them to be able to understand, okay, these are the business rules, the validation rules. You have your critical data elements. You have some kind of initiative, as you should have some type of initiative to identify what your critical data elements are inside the system. So these are the data elements that people use to make the important business decisions. And your business rules and your validation rules to definitely be, definitely in line with your critical data elements. Therefore, knowing that the data element that you'll be using for crucial decisions inside the company have a high data quality. And then again, then furthermore, your data quality tool is telling you what the value, I mean, what the quality of that data that you're feeding into it is. We probably won't have 100%, but you want to know that you're directionally correct. You're directionally good enough to make decisions off this data. So just throwing up some numbers, I mean, presentation has to have numbers, right? So what is the business loss of bad data? So Gartner says the average financial impact of poor data quality on organizations is about $9.7 million a year. And that was said at a point in time this year. However, you know, that's going to keep going up as we understand how important data is to making decisions, right? And to open resources, 30% of revenues, poor data quality, poor quality data is costing businesses at least 30% of revenues. So just putting some numbers out there to give people understanding. There is an impact, right? These are the numbers that you can tell people that we don't have good data, and data quality knows costing us. Most people at this point understand this point. Who are we as data governance, right? And so I'll give an example. There's a common thing that we all go through as data governance professionals, of where do we sit inside an organization? Are we part of the revenue-generating portion of the organization, or are we part of the cost part of the organization? Anybody who has been in line with the cost part of the organization knows that every year you will go through some type of cutting process. Cutting costs have historically always been a goal of most companies. How do we cut costs? How do we cut costs? And so if you're in line of that cost-cutting organization, I'm pretty sure you have dealt the loss of team members, right? Materially, the team members, but also maybe systems, maybe resources. And so let's re-look at ourselves. Like, are we really here? Do data governance really cost just a cost-part organization, or is it revenue generation? And we have the opinion on our team that we are part of the revenue generation, and we have a very good discussion about it. So if we talk about the sales and the marketing teams, right, nobody would ever dispute that sales and marketing are directly part of the revenue generation part of the organization. Sales is going to go out and make sales. The marketing is going to actually educate the market, the customer, even build the market. So if we look at the example of an iPhone, right, they're going to go out and let everybody know what an iPhone is, how great it is, the different functions of teachers that it can do so that when somebody goes out to do sales, they know exactly where, what we're talking about. The sales team shouldn't have to teach you what an iPhone is, right? They shouldn't have to build up a market to say that these are the people who should do want to buy an iPhone. That's probably done by the marketing department. So they're hand in hand and look at, you know, this is what's going to generate our revenue. However, let's say the data, the quality of the data that is used is bad. Let's say the marketing team got a list of people that they actually want to use to send out, to build the market, right? And the data they have is bad quality. So it tells them, send all the iPhone marketing out to, let's say, my mom. My mother, you know, is not really into the latest phones. I think she has like the iPhone too, something like that. I was plugging the charger in yesterday and I couldn't even believe that chargers still exist. But that's the phone that she's happy with. She doesn't want the big fancy new phone. But my daughter, you know, every year she's telling me she's eligible for upgrading but she's not because she wants the new phone, right? And so let's say the marketing team sends all the iPhone X marketing out and it all comes to people like my mother and her peers. And then the salesperson goes out and tries to sell the iPhone X to my mother. She's going to turn them down flatly. However, my daughter is sitting over here and she never got to any kind of marketing activity. It didn't come to me, you know, so she could pick it up out of the mail before I got it and come back to me and tell me to go buy it for her. Right? And so the sales team, listen to the marketing team, they start pointing fingers. So that's why I say, you know, if we look at it all like a family situation, the data governance can be looked almost as the family therapist. We are the little man, right? We can actually make sure that the data is correct. We can talk to the people about here's the data that you have that's coming from this system to that system. Here are the issues. We put the processes in place. We put the standards in place that actually will prevent them from having similar errors occur, right? And so that's data governance. So if you look at that way, we're directly in the family of revenue generation. Right? So that's just the point. Something that people can take that, and they tell you your part of the cost. How do we escape chaos? So the key point here, I think, is to look for low-hanging fruit and try to bite off too much. And so where is the low-hanging fruit? Data quality is one of them. You can start taking just one person's data and keep data to their business rules and put them into an cycle algorithm and figure out what the data quality is and provide that to them. Another would be standards. They can go out and get ISO standards or some other organization to bring them in, have a discussion with people about whether they'll stand just sit or not. If they don't sit, come with your own company standards. Reference data. So reference data is from the systems. Bring the application system in. We use Kaliber to just bring data in. Just bring it in. Keep bringing it in. And then we'll see how it fits back to any kind of standard with a mapping project. Approve projects. You own any project. So you've been approved. So it has funding. You can put data governance initiatives in to one place and then take it out to show other people what you've done so they can see the viability for their different areas. But you already have an approved project that's based on standards. So that's just escaping chaos. So what does harmony look like? What does our endpoint look like? What integrated teams, people that work together, that know when to work together. They know how to work together because we have defined data governance processes. We know what the voting looks like. Two-thirds of the people need to vote on it for it to be approved, for example. So we have defined processes to have to define people as part of those processes. We have defined workflows for approval of the data. And so we use Kaliber for workflows as well. And people can go in and we know who's going to and it'll automatically send it. If you have some paperwork flow application, it could be anything, you know, that'll automatically send from one person to the next person and then go through the approval process. It's very helpful for approving data. Reference data, map to the standards. And everybody can't adopt your standards sometimes. It's just reality. So therefore, we have a process whereby we reference map or reference data to a standard. We have an understanding of the data. So we have some type of business class resolution that's going to give us that transparent data quality. So some type of data quality tool that's telling everybody on a daily basis where they stand as far as they're matching up with validation and business rules. So I'll tell everybody, it's not going to be easy. The real honest answer is doing a successful data governance program in the towns, you're going to take a hit. I said that in the last time when I spoke about this. I laugh about it, but I personally did take a hit doing the proper thing, which was to bring organizations, people who didn't want to work together together. But it took time. It was costly. I had to get on a plane and meet with people, and it kind of stressed out the timeline a little bit. So then when we actually got to where we got to, we had to look back and say it was a portion of the time that didn't seem productive. However, it had to occur. We had to get these teams working together. However, that won't show up on your bottom line, that you now have these two teams that know when to work together and always do work together. They won't see that. So I took a hit a little bit as the manager to say, no, this project should have taken less time. It should have did this, right? Okay, but that's not taking into account the fact that there was some people portion of it that needed to take place. There won't show up when you're deliverable. However, the company will benefit from it going forward. These two teams not only work together now, they know how to work together. They only know how to work together. They do it well. And that wouldn't have occurred had we not gone through that process. So you may take a hit, but the company benefits in the long term. And sometimes, like I say, they will be rewarding, but it's not going to be easy. Just some parting thoughts before we go to questions. Just think about what are your objectives for your data governance program? Is this your first attempt? If it is, like I always tell my kids, there's a better way to learn things other than necessarily doing it yourself. So maybe look at other examples that are out there, people who've gone through things and learn from their experiences. What are your core competencies? What are you able to do within? Maybe you're not that technical. So if you're not, maybe that's something you put off a little bit of other outside people to come in and help you with that piece of it. How do you sell data governance inside your company? It won't sell the same in every company, so that's something you're taking into account. And then finally, how do you measure success? So how will you know that you're successful inside your organization? Is it a number of programs that you put in? Is it a number of people that are being involved? Is it a fact that you have a stewardship program, a metadata management program, a certain program that you wanted to have in place? Just have it in your mind, know how you're going to measure that you have a successful initiative. And so I'll, at this point, open it up to questions. I see some have come across. Thank you very much, Sean. I do have some questions for you, and as you were saying, I think changing the culture, you know, it's very difficult and it does take time. And I do agree with you that going out and meeting people in person goes a long way, so hats off to you for doing that. One of the questions we have is how do you balance command control with autonomous governance or shared responsibility in a structured way? You know, balancing between the two. Okay. Yeah, so if I understand the question, I think we're still talking about being able to mandate that people do, and let me know if I'm wrong about this, but being able to mandate that people follow certain processes and things as opposed to using maybe their own type of data governance type of things. Is that what we're talking about? From top down versus bottom up? I'm not sure, because somebody posted that question. So it didn't come from... Well, let's talk about it from that way, and if it's not, then somebody else can clarify for us. But I would look at it as... That's difficult, because I remember us having the conversation, the standards. Everyone has to do it. They have no choice in the matter. And the fact is, they do have a choice in the matter. It'd be nice if we could force everybody to do what we want them to do, but the reality of the situation is that we can't and we couldn't. And so therefore, you don't want to make yourself look too bad by saying you have to do this and everybody's like, okay, you're not in the real world. We're not going to do it. So you just kind of realize what battles that you actually want to fight and then allow them to do the things that they have some data governance. Figure out how that may work. And maybe it's a gradual thing. So now you want to adopt our standards. Let's figure out what your barriers are. Why can't you adopt our standards? Is it beneficial for all of us later on for you to adopt those standards? And then let's try to make a path to get there. And that way it's not coming down so much as telling you what to do, but we're partners and we're working towards this end goal. So I hope that answered it. Okay, thanks. Yeah, that's good advice. The next question is, what is the commonality of interest in each data stewardship group that you have? Are the groups by line of business or are they by data domain or how did you segregate the groups? Excellent question. And we went across data domains. So we went across applications to data domains and we had people who had interest inside of those data values. And when we met, we made our coach on how, he actually, when he first came in, you know, one of the things that he had to do was go around almost like on a tour around the company, introducing himself to people, meeting people, finding out who in the company could do anything, those things I meant to say, and what the responsibility were so that when he could come back, when we had questions of, you know, we're about to deal with property data and we're about to standardize property data in the fields that are inside of our property data. Who should be involved? We had somebody who had a road, not a roadmap, but a map of the company, of people who deal with property data, who probably would be interested. Who is responsible for the lease administration? Who is responsible for it in our master data situation? And so knowing that, now if you don't have anybody that went out and filled out that map, then your challenge would be to be able to find out who those people are inside the company. But it was definitely across domain, it was across region. So these people don't have the same responsibilities and they really don't have any responsibility to us. And so therefore you have to make sure that they understand the importance to them that they're part of this conversation. Okay, thank you. I know that you had a slide on sort of industry guidelines on metrics. Have you been able at JLL to identify any business value metrics for your organization? Have you been able to go there far yet? Business value metrics. Yes. I don't see no, we haven't gone there yet. You got my industry standard to say these are the business value metrics that we're putting out. I'm going to defer that one. So maybe one of my colleagues can put that back out there and some other larger discussion. But I would say we haven't gone there yet. Okay. All right, thank you. JLL is a very large organization and I know we talked about it that you actually traveled to meet people face to face. What other methods of communication did you find worked the best for your organization? I was thinking for anyone out there and other big organizations, do you have any lessons learned about how you were able to, you know, form a cohesive group and work across all those multiple locations? Yeah, because it's a global company so I'll be honest with you. I did not need to leave the United States to go visit anyone. And I had a very hard time with the mobile part of it. I worked at a company that was, I guess I could say I was already set up already, worked at Comcast. And Comcast was very, coming to the office, meet face to face. That's just the way it worked. And so now I went to a company that was very remote and everybody was talking on the phone and I struggled a lot on how to build these relationships with people that I'd never saw before and I had no opportunity to jump on a plane and meet. And there was a specific situation where something I said came off, not how I meant it, and it really made the person very upset. And I knew I didn't need that way, but they didn't know that way and I felt like they probably had written me off. So how do you overcome that situation when you can't get on the plane and go meet with them and sit down? What I did that actually worked was I decided what can I do from a remote situation. So I can work in their time zone. It's not convenient to me. It's five in the morning to me, but if I make the meeting very convenient to them, at least they can see that I'm reaching forward. That I'm really probably not that bad of a guy that I really want to try to make this work. So it's kind of the same concept, but it's a different way to do it. Another thing is, I was used to, if you did a meeting on the phone, it was straight to business. We didn't talk small talk, no personal talk. We just went straight to business because it was on the phone. That doesn't really work in a remote environment. And so we did have to start spending portions of the meeting when the meeting began. How are you doing? How's the weather up there? I got to be watching the world cup. Some people may think these kind of things are silly, but one thing I've learned through my experiences is that these are the things that make teams work. You don't do those things that your team doesn't really work. And it falls apart at the smallest things. Somebody doesn't do something and you just don't like them or trust them. And so you're just extra critical about them and they put scissors and cracks inside your teamwork. And so just caring about the other person, I basically have to do that by phone as opposed to in person. Okay, that's good. Thank you. There's a couple of questions sort of related to the Clube of Software. Sorry, I think either one of you could probably answer these. The first question is, is it two different software packages? One that addresses the data catalog and one that addresses data governance or is it one software application? I'll take that one. Culebra is a single platform that's able to handle both the data governance team as well as a data catalog and what we're calling a catalog of catalogs. Of course, there's different functionality that's brought on because in the beginning, when you're establishing governance, we're not going to turn on every single feature because of the fact that there's just kind of steps in place to get everything organized from what we call a nine-step prescriptive approach to it. We really want to really work and partner with our clients to make sure that they get the most out of the platform and are able to step up depending on their needs and challenges the most. So I hope that answers that question. Yes, it does. All right, thank you. And last but not least, the other one was how does the data quality metrics populate in the lineage piece? How does the data metrics populate in the data lineage piece? Yes. Yes, so we talked about metadata and metadata is a very big topic and I definitely feel like metadata is something that everybody should be doing inside the organization. However, metadata is tough. Metadata is one of those things that once you tackle, we can ever get it right. If you've ever satisfied everyone and the answer is probably no, right? So if you won't. So to a certain degree, we've got to punt it on metadata. I'm just going to be honest. But everybody, we do realize the importance of it and being able to get back to data lineage. So as you talk about the metrics, being able to trace that metric back to where it actually came from and that's kind of, you know, just definitely what, you know, kind of trying to go with it. Sometimes difficult to do inside the company. So depending upon where your team is and how much stuff you have, metadata is not the low hanging fruit. So we haven't got there. It's on our radar. I'm actually responsible for it and we will get there. But that is a difficult part to be able to chew off. And there's a couple of reasons why it's difficult. So if you think about your in-data metrics and then you're tracing it back to where it comes from, a lot of times when you get to your ETL scripts, there will be several procedures that kind of obfuscate what is actually going on to be able to get it back to that source. And so, you know, there's a bunch of different vendors out there that you can work with to try to, first, engineer to get back to that. But it's a very difficult process to be able to go through. So I would definitely say everybody should do it, but it's just tough. Okay, thanks, Sean. We're out of time, so we have to wrap up, but just want to thank Sean very much and Erin as well. And just a reminder, we will put this recording out on the members only section of the DTPO website in a couple of days. Thank you both. Thank you. Turn it over to you, Shannon. Thanks, Michelle. Thanks, everybody, for the great presentations and thanks to all of our attendees for being so engaged and all the great questions coming in. We just love the engagement. And we hope to see you next month. Thanks, everybody. Thank you, everybody there.