Name: Data Governance User Group - Mar 26
Uploaded: 2026-03-26T16:31:02.910Z
Duration: 1 h 4 min 44 s
Description: Data Governance User Group - Mar 26

Transcript for "Data Governance User Group - Mar 26": Good morning, good afternoon, and good evening, depending on where you're calling in from. My name is David Lee from Precisely, and welcome to the Data Governance User Group for today, 03/24/2025. We are live today with three experts on data governance from Precisely, and welcome to our new platform, Goldcast. You may notice I am not Matt. I'll be filling in for Matt today for our program. Goalcast is our new platform, for these events, and you'll notice a couple of different things. On the right hand side of your screen, you'll see three buttons, a chat, a docs, and a q and a button. You see should see some chats going on. We'd love to know where you're calling in from today. I'm in Fort Myers, Florida. And, also, my LinkedIn URL is there. So if you'd like to share where you're calling in from, drop your LinkedIn profile, and we can get start getting to know each other really well. There are some links in the docs section, and at any time during our program, you can, pop a question into the q and a field, and we'll take those as we go. If you're having technical problems, you'll notice on the bottom of the gear icon, you can adjust your audio and your video settings to make sure that you're connected. And finally, a brand new feature for Goldcast is our raise hand button. If at any time you have a question or when we call for questions, you'd like to raise your hand and join us on stage, you can ask your question live. We'll promote you to the stage, and then, you can go back and join the audience, and we'll take care of that at at the end. So we'd really love you to join us on stage and ask a question when we get there. You will also notice, when you join us on stage, you see the audience member. You'll see your your icon, and you'll see the speaker icon where you should see me. And then there's the leave stage button right at the bottom, and you can click on that and step off stage at, at the appropriate time. So welcome. We have a great agenda for today. We'll hear from Anthony, Steven, and Brian on some core components of the data governance program, contextualizing data quality. Brian will talk about the road map, and Anna will talk about announcing announcements and closing remarks at the end. Anthony, if you'd like to join me on stage, please. Anthony Verkamp is the manager of strategic services at Precisely, and we'll be talking about core components and best practices of data governance programs. Anthony, Yeah. take it away. Thanks, David. So my name is Anthony Vercamp. I work in strategic services. We're part of the consulting group working with clients, really agnostic from brands or or or systems or anything. We just are really agnostic and a proponent for our clients. So thank you again, David. We can go into and talk about some of the core components of a good data governance program. Do you want to go to the next slide? So we really want wanted to set a a background. We're really coming back into this program, understanding what this program is about and this particular, series is about for for the data governance user group. And we wanna set the backdrop and and say, okay. Well, what are those successful program, elements that drive every data governance program? And from our perspective, from a strategic perspective, really, it starts with things like a data government data governance framework, really making sure that you have all of the parts and and the puzzle to ensure the availability and the usability and the quality and the sustainability of those critical data elements, and it is connected to value drivers. And we'll talk a little bit about what that looks like, here in a moment, each one of these actually. And then also data metric models. Right? How do we measure the quality of the critical data governance that we're actually, performing and making sure that we have the tools and the ability for proper analysis and an in action. Right? And then the decision tree, deciding what we're going to govern. We can't govern everything, and everyone here knows that we can't govern everything. So the idea is how do we decide what to govern, what is critical to the organization, and ensure that we can gather govern that particularly in the organization and some of those elements in making that decision. And then finally, that operating model, the who, what, where, and when, making sure that we've got those processes in place, and the org structure in place to provide that structured and repeatable process for sustained data integrities. So from a data governance perspective, what is that? Well, it's taking all of the business policies, procedures, work instructions, systems, projects, all the knowledge think about all of the knowledge that, most of us work with, sites. The the knowledge that the sites bring to the particular governance and the data that they're using on the day to day. They're really those ones that understand what that data means and how it's being used and what the impacts of that data are. And then taking the systems that we have, building that framework out so that we can have an understanding and operating model, ownership, a process, all of the things that make it where we can build a data governance program that meets the e needs of the organization and is providing that value. And that really drives what that what that data government program is about. And here, you can see, much of that relies on a collaboration platform like Data Integrity Suite. And then critical data or governance decision tree. A good example is, hey. We need to add a set of commodity codes to enable sourcing strategies, category management, changes like that. And you always wanna start with whenever you're bringing this information in, you know, is there is there an operational impact? Is there a business impact? Does it does it actually provide value to the organization? Is there a compliance or finance impact? Those kinds of things. And you're asking yourself, do we wanna govern it whenever we have those questions and those those things that are coming about, bringing in those elements and saying, do, do we wanna govern? And then the next question is and it goes to can we you know, how should we govern it? What is the business process? How can we put it in? Is it point of entry? Is it predictive? Is it something that we can build into the process? Is it some is it proactive? Is it reactive governance where we're actually doing data quality after the data is being entered into the system? And then where where can we govern that? Right? What's the right process? Is it in a particular system? What is the source of record for this data? Do we need to replicate this data out? Those kinds of questions about how we can do that. And then, finally, who should we govern? Who in the organization has the decision rights? And this is particularly important because that really drives what we call good data and what are the implications of that data. And then finding finally, measuring that information that we got. And it really goes into these metrics are organized into three main level categories, business impact. Right? Things that are gonna drive business. Do we have, and we're gonna go through some of these examples in in some slides down below. But business impact, what does it drive? What it what processes can be enabled because of this? How do we measure it? What is the customer satisfaction? Those kinds of questions being answered. Or is it performance and value? You know, what what's the value and, of the data quality, the accuracy, the number of touches, the data errors, the cycle time, those kinds of things. And then finally, are we being efficient with what we're doing? Volume, number of counts, cycle time for building building these metrics, completeness, accessibility, all the things that make it important to understand how efficient we can be in these processes and dimensionalize these and bringing these about so that the organization can measure the the data, according to these metrics. Any questions? K. So the next idea is really connecting the dots going from okay. We're talking about things like, the data integrity framework, the data metrics model, business accountability, and decision tree. How do we put this together to understand what that means from a good successful data program? And you'll see this actual this actually through our slides, and and it really represents each part of the, core successful component that we are touching on as we discuss these. So we touched on this, but, previously. But giving focus to the data. Right? When we look at, critical data, what are some examples of that? Right? How are we driving that? Will the business going to build, increase growth, obtain cash, reduce costs, regulatory compliance. All of those things are examples of critical data, critical, business objectives that are driving, the need to identify critical data elements. Some of those critical data elements or payment terms, that's gonna increase your cash. Safety stock, that's also gonna increase cash and and, remove, additional cost. Something as simple as, like, weights and measures. Right? That's more of a compliance thing. Whenever we make sure on finished goods that we have the proper weights on those finished goods, whenever they go on a truck, we wanna make sure that we're weighing our trucks correctly. All of that gives you that value, right, on the right side here. Understanding you've got the confidence in the data, and you know that you're not gonna get a truck that's overweight, for example. It gives ownership, making sure we know who owns this data and can drive this data. Who owns payment terms? Is it finance, supply chain? Right? And then impact, being able to impact that from a revenue and profit and drive compliance based off of what the organization needs. And then finally, document, ability to know where the data is, what's the source of truth, why are we going to govern that, and really given that focus to understanding what the data is? So this really explains the framework and how we drive data alignment. Right? So, the goals are really, from the business organization. Let's think you know, the the organization says, okay. We want to increase cash. And that's our goal. Then we build objectives around that and metrics to to measure how are we going to do that. Well, there's critical data that we would we would actually govern to make that happen, and we're gonna go through that. But that's actually putting it in the catalog. What is that critical data element that we're going to to govern? How do we define that from a business standpoint? And that's the glossary. And then standards, processes, and rules. Right? So the standards, you know, is so, okay. We're going to, govern, payment terms to increase cash, and we're gonna put process, placed to do that. And the rules are that for for offenders, we're going to expect terms of, you know, net 30. And for our customers, it's net 15 because we want cash faster. Right? So we put that into to a rule, and then we would measure that in our metrics and objectives and eventually measure how we get to our goal and everything. So that makes it where that framework drives those goals really drive what we're trying to do from a, data governance standpoint. And just an example. So this really fits into is really an example. If you see where we have the the increasing the the payment or governing the payment terms there. Right? So if we govern the payment terms, and the corporate priority is improved cash on on hand, as I've been talking about, you have data assets, there in the middle, and it's managing the customer payment terms to net 30 and supplier payment terms to net 60. And that's really the on the left where the business leadership is driving that. But then we connect those dots, and we say, okay. Well, what is being impacted by that? Well, here's the thing. We've got business rules that we need to update active customers with net 30, active suppliers with net 30. They they mean they will probably need to change in order to make sure that we're aligned with that. Data dictionary. If we have, for example, SAP, it it's in both customer and vendor, and that will be actually in what's called Zterm. And then our report catalog, what what is our total active customers? What are our suppliers? Which ones need to be updated? And that's really gonna drive it over to the right data stewardship, the quality, and governance. Right? We've got quality pipeline groupings where we're building out the those data, centric, updates based off of, what we need to change and update for an accuracy and completeness perspective. And then working with business IT and operations, making sure that we have those technical assets defined, and we can build out those data integrity suite rules, in this case. And then, any kind of reference data. Right? Make models, data domain, functional data, main data, and reference list that we need to change. We may not have, that set up for, as a reference data perspective or net 30 or net 60 for those customers and vendors. So this really drives it all together here. Going to a little bit more in-depth, you know, what does that mean from a data quality remediation perspective? Some of the how do how do we get there? How do we really measure those rules and and put into place the things that we need to change? So some of the things that and these are these are not inclusive of all, types of data profiling, but just some examples of what we've seen, that really are working. You know, statistical data profiling, valued assignment patterns. So think about, if there's a pattern in the data that you need to identify that's that brings about that is different than the rest of the data. So, recently, been working with a customer and, their part numbers for certain vendors. Certain certain vendors and the way they've been entered in the contracts, they have dashes in them. Well, they shouldn't have dashes in them. So we're looking to update that and make sure that we don't have dashes in, across the the contracts for those particular vendors. And then we have things like value variations. And I think about things like this where, making sure that we're aligned across the organization of what what CA means. Is it Canada? Is it California? Making sure that we understand, what the the data means and we're aligned, across the organization and what those, values mean, and defining those in one one place. And then things like column completion percentages, making sure that everything that we have is complete and accurate. You know, think things like, well, even payment terms, if it's not accurate and complete, and if it's not defined, then that will cause errors within the systems. And then there's also rule based profiling. Think of broke broken relationships. This can be as broad as data lineage, thinking about things like, you know, we have a source of record of what customer as well. Do we have those relationships built correctly in, downstream systems or broken relationships even within the, in the integrity of the reference data? Think about things like, well, I mentioned payment terms, making sure that the payment terms are defined in reference data and can be defined within the system. And then do we have all of our obsolete records? This is absolutely key, making sure that obsolete records, are marked obsolete and are not used. This causes issues such as, bringing in bad data that hasn't been updated. And then duplicate records. There's a lot of, especially in the material mass master and SAP. Duplicate records cause a lot of issues in the fact that it you have you don't it takes away your ability to understand what products you actually have and what you're what you're procuring from. And then finally, contextualization. And I think, the next, slide will go through that, but contextualizing the data and, going through that, will be in the the next part of the presentation. So oh, and then, sorry. Missed the slide. The future, data governance plan sessions we have right now in May, we're looking at putting in the operating model, going through some of that, and what defining an operating model for an organization looks like. The data model for SAP, master data, we're gonna go through and look and see what that looks like from a customer and a material side and how we define that and some of the key critical data that really drives the organization for that. And then, DIS, replication of the data of the data model. And then August, we've got dashboarding. How do we build dashboards with the metrics to drive data governance? Deduplication, this is gonna be on a customer that we did, that's driving deduplication for the material master. And, artifact naming standardization, how do we, standardize naming, conventions so that they drive correct names for customers, vendors, and and materials. And then November, governance of AI. This is a key cop key topic in regards to how do we, build AI in the space of data governance. And then we wanna showcase something that we've done for a couple customers. We're looking to do for a couple customers is integrating MDG, DQM, and DIS. So making sure that you get your data quality all in one place. So this gives you the ability to understand, all of your DQM data quality, metrics that you're building in MDG and replicating that into DIS. And then in March, workflows, analytics, and in May, we'll, really focus on PII agents and a AgenTiC AI for, for data governance. That's what we have planned. Any questions? Thank you, Anthony. We did actually have one question come in. But for the audience, again, if you'd like to ask a question, you can drop it into the q and a, chat on the top, right hand side of your screen or raise your hand, and you can ask your question live to to Anthony. Anthony, we do have one question. What what role, ritual, or operating model best practice do you think has most improved governance adoption? Is is there something you can point to in. where you sit? yeah. Absolutely. The the first thing that really comes to mind is, defining the ownership of the data. That really is probably the hardest thing to do in the organization and making sure that people realize that they are owners of the data. But defining the ownership, one, you're able to identify the data, who owns it, and what those rules are that impact the business because those are the people that really understand the data and and the issues that they're facing with that data. And two, if they own the data, that really drives acceptance of the governance. If they're part of the the governance strategy, then they're going to drive that for the organization for you. Right? So they're already on your side. They're looking to drive that data and those governance practices. Great. If anybody has any questions that come to mind after we get done, we'll tackle those as we go. So Anthony, thank you very much for your presentation, and we look forward to hearing more from you a little bit later in the larger Q and A section. Thank you. Steven, if you would like to join me on stage, please. Steve Lindsey is a senior director of professional services here at Precisely, and we'll talk about contextualization. Steven, slides are yours. Please go ahead. Hi. So good afternoon. Good morning. So as mentioned, Steve Lindsey, part of the professional services team based in The UK. So appreciate that contextualized data quality to help drive value business value is a really snappy title, but it's sort of driven from conversations that we commonly have with customers, which is that there is a disconnect between the the data management activities, data quality in in this particular instance that are being performed and showcasing the value of those activities to the business and and how those activities are helping to drive value for the business. And so, you know, the purpose of this this session is to showcase how creating contextualized data quality source scores can help, bridge that gap. So let me just move on. Okay. So you may have seen part of this actually in in Anthony's presentation earlier. So the the standard sort of framework that we precisely leverage is centered around that sort of business grocery and, you know, the standardization of terms, understandings around the the metrics, rules, etcetera that, that's being used across the organization. In the context of this sort of session, what we're focusing on is the the data quality management and then the strategy map, aspects of that that business cross re supports. So on the data quality management side, we'll talk through how you can create those contextualized sort of quality rules to to assist with that sort of value identification and prioritization. And then we'll take that on further through just an example, use case of how, those those quality metrics and contextualized sort of rules can be aligned with the initiatives which are important to the the business, and so therefore, you can sort of showcase the the value that your that your activities are performing and and driving for for for the for an organization. So when we talk about contextualizing data quality, we're basically talking about tailoring the quality checks so that the the rules are focusing on fit for purpose. And so, yeah, it's not that sort of one one size fits all sort of, model. And so so why sort of contextualize this sort of, making sure that, let's say, that what you're focusing on is the sort of data issues that are most critical to the business and that any sort of remediation or other activities that you're you're doing are gonna really drive value for the business as they're aligned with, you know, what's of what's been deemed to be of greatest importance to to an organization. And so just generally accepting that a sort of not not all issues are equal. So that there is a a level of prioritization and, etcetera that comes with data quality. When we're sort of talking about, contextualizing quality, If you start from, I suppose, the traditional and if I take, like, a a Dalian architecture, for example, with the with, like, your bronze layer where you're landing loads of data, you know, typically, you're gonna be doing a lot of assessment type rules, which are, you know, standard dimension type things around looking at the accuracy, consistency, sort of value type conformance of of data. And and that's good to give you sort of a an initial sort of view as to what potential quality issues that you have. But, you know, those rules in and of themselves are not contextualized in the sense of, you know, there's no real understanding at that point as to whether, you know, a score of 95% is good enough for a for to support a particular business use case. So so the way that, typically, sort of contextualization occurs and the focus of, I suppose this session is really point two on the right hand side is, yeah, you'll bring in sort of, like, the sort of business domain owners or data owners that have an understanding of the data, how it's used in the business. And so, for example, you you may then come up with more contextual rules around that. Okay. Well, a first class airline ticket shouldn't be less expensive than a than a an economy ticket or, you know, the discount percentages shouldn't be should never exceed 10%. Again, you know, so so you've you've contextualized in in the rule, but, again, that that rule and what is deemed a a good enough score for the business for the that's for exactly the same rule could differ depending on how that data is gonna be used. So that's where the sort of point two on the the on the slide there at the bottom comes in, which is, okay. Now understanding the the particular use case for the data and therefore the importance of the rule, what what in that particular context would be deemed good enough by the business in terms of data quality? Is it 95%? Is it 97%? Is it 99% that's required? So let's say so the reason for contextualization was sort of really already covered on, but, essentially, what you end up with is, you know, when when you do that sort of discovery and you're you're running a a vast number of rules against essentially your entire state in whether it's Snowflake, Databricks, any other system is that you it's basically very difficult to see the the wood from the trees in terms of what's truly important to the business, where should I focus my my activities, etcetera. And so what you tend to end up with from a data quality and remediation perspective is see where issues are filtering into, like, the the the sort of presentation layers, whether it's the reports, etcetera, or applications. And then when issues get raised, they're working backwards to to fix the issue. So so very reactive and, obviously, not ideal or cost effective way of resolving issues. So so the way that you can start to contextualize quality rules, If you almost think of that sort of running those sort of discovery rules, you know, that the metrics against, say, for example, your data that you landed into a bronze level is sort of, like, level zero. The first level is and and Anthony spoke about data ownership is, you know, the the owners of the data are having an understanding of what's important and therefore adjusting the the the sort of criticality of various rules against data. Yeah. And we typically leverage a sort of a a five level score from one being very low to five being very high. And then you'll adjust the, you know, the the rack status. So So in you know, from that sort of as a data owner, what would you deem to be a a green state for for this particular rule? So that sort of adds a level of sort of data owner piece, but it's still not contextualized from perspective of, you know, usage of the data. So so then you let's say we discussed, you know, maybe the the business owners bringing in that sort of maybe using the same rules, but designing additional rules which are, you know, maybe aligned with those those identified critical data elements and bringing in again the, you know, what's what's this rule criticality, what's the what's deemed a good enough score or the, you know, like, the green threshold, if you will, for for the rule. But, you know, that that same for levels one and two, those same rules can be used to, or or the data that those rules are being applied against can be used in multiple different use cases, each of which may have a different requirement in terms of what what is a deemed a good enough level of quality for that, for a particular initiative, for example, to be be a success. And so that's where the sort of level three contextualization comes in, which is, okay. I I have a set of rules that are running. I have a baseline set of thresholds around what we think is good enough or what we think the the criticality is generally. But now in order to support a particular initiative that the the business has and for that initiative to be successful, now, you know, the the the the criticality of this particular data takes on much more relevance. So maybe rather than being a medium criticality rule previously, it's now a highly highly critical rule. And let's say, rather than 95% threshold of quality being acceptable, you now need 99.5% threshold quality for it to to be a a successful or the the outcome of the initiative to be successful for the business. So let's say that sort of level three sort of identifies what matters and what's good enough, but you still you know, you have sort of any any organization and team has limited capacity. And so it's so the next question is where where should we focus our activities? And so I think that the main thing to point out here is that, you know, I and and so Anthony pointed out, was like, you need to understand, you know, from a business risk perspective, what's the impact if the if the quality isn't good enough. And I think it's important then from that prioritization, so when you're reworking out what the criticality is and what the good enough score is is that what you want is the prioritization of your activities to be based on the risk to the organization, not just based on the, you know, the defect count. And so the way that, you know, we've typically introduced this within precisely services with customers is the the concept of our risk weighted quality score. And that risk weighted quality score will use those raw, you know, pass fail count percentages, but it will take into account what what the the criticality or the business impact is for that rule based on the the the usage of the data and also what they let's say, what is deemed to be the good enough score for for the for the the data quality in in the particular usage context. And the way that we sort of create or calculate that risk weighted score typically is using a sort of a Fibonacci based approach. And so the the benefit of this is that, you know, business business risk, isn't linear, and this sort of, approach basically lends itself to a nonlinear sort of progression in terms of the the importance of or the the potential impact of poor data quality based on the based on the criticality of the rule. So you can see here on the right hand side, you know, based on those five criticalities, one, two, three, four, five, we sort of applied an a Fibonacci way with the the very high criticalities being given a level of sort of Fibonacci weight of 21. So Fibonacci scores basically are infinite, but from a perspective of, I suppose, usefulness in terms of creating a risk weighted score for for quality, going much beyond 21 doesn't make any sense because you end up with basically, everything is extremely important, and you need to, you know, you need to address it with some urgency. So we we typically, assign the the weights, as I said, with the the highest criticality that you're using, so five with a with a Fibonacci weighting of 21. What you then do is you take your raw data score and what's, being the, good enough score in for the particular usage context. So in step three here, you can see a prime example. So for example, if your current, level of data quality so when you run your raw data quality rules, you say you've got an 88% pass fail pass rate and and your green sort of status, your good enough score is 90%, then you have an attainment level at the moment of 97.78%. So, you know, your you're you're 97% meeting the requirement of what is deemed good enough by the business, which is that that 90% score. What you then do is leverage the Fibonacci weighting to to risk weight those and to adjust those those scores upwards or to to accommodate, you know, the the criticality or the business impact. So in this particular case with a, you know, the 88 raw score against a 90% requirement and you've measured the the rule as a as a medium, which which we typically give as a a 13 sort of score, then you end up with a Fibonacci or a score of 98.63%. So this represents essentially an attainment score. So you're, you know, you you're 98% meeting the minimum or the expected requirement of the business for for this particular element of data quality for an initiative to be successful. And I've just put in here a couple of examples worked out. An important thing, I suppose, at the the top just to understand is that if your raw score is in excess of the target, then you're gonna be at a 100% score. So you've a 100% achieved a a level of quality which is deemed acceptable by the business for the particular usage context. And so, you know, spending time and effort to try and address those additional percentage points of the from the raw score is gonna add very little value to the to the process. And just to point out with the scores here, I've done different scenarios. You can see with the first one's going through scenario six. The achievement level is 9094.44% in terms of 85% score, based on a target of 90. And what what you'll always see with the Fibonacci one is that the the highly critical ones, so the ones with that weighting of 21, will always end up with a score, an attainment score, which represents that achievement level, so 94.44%. Everything else is adjusted upwards based on the weighting. So how does that sort of get reflected in a meta model and within the sort of precisely products? You have, your data quality rule definition, and you're gonna have your standard sort of rag rate rag, ranges established by rule, the default level, and what the default criticality is for the rule. And so when you execute that rule against a particular technical asset, you'll have a quality rule result. And so that quality rule result, let's say, will have the rule score for the the rule executed against your table, columns, whatever it happens to be, and that and a base of level risk weighted score. Then when when you sort of the business has various initiatives and they decide that particular data elements need are needed to support that, you can align that quality rule result with those with that initiative. And at that point, you can do an override on you know, when you establish that relationship to say, okay. In this context of use usage for this initiative, this is actually the good enough score, and this is the business impact or the criticality. So then at that data initiative level, we can show an adjusted risk weighted score based on the the context of usage. And just bringing it all together very quickly into a, sort of a use case, which is probably fairly common to a lot of people at the moment is and so we wanna become an AI first organization that reliable uses data driven intelligence to automate decisions, personalize customer experience, and improve operational efficiency at scale. And so within the the the precisely sort of framework, we would capture that strategic ambition at within an asset type called strategic ambition. And then from an organization perspective, they're gonna come you know, the business will come up with a number of objectives or initiatives that they want to that that will support the the achievement of that strategic ambition. And so I've just put a few down here. But, again, within the precisely meta model, those those objectives will be captured within an asset type, which is the business objectives and as and and associated with the strategic initiative. So the one that I'm gonna focus on in the next slide is this initiative one, which is an intelligent customer engagement. So in order to to deliver on intelligent customer engagement, you know, the business and the organization that the data teams have identified that we'll need an initiative which creates a customer intelligence feature store to enable real time AI personalization models. And the the main thing of point out here at the bottom, the last stop point is that this is gonna be used for, you know, with without human review. So, you know, that's that's the critical thing to understand in terms of, like, the risk profile that's coming on in in the, or that's been brought in by this particular initiative. So, yeah, the next step is, you know, identifying those those critical elements of data and then the associated quality rules, which are gonna support, you know, that initiative and allow that initiative to be successful. So, you know, you might identify that we've got the you know, based on the data that's required, we have these five rules currently, and their default levels of criticality and good enough scores are as highlighted here. And we've got to sort of picked up on the rule number four, which is the customer consent for that is populated. So just here, so they were like, historically, that sort of criticality of the rule being medium and a 95% score being good enough has been acceptable because, you know, you had that you know, any gaps you could, handle with sort of manual handling. But now with this AI first initiative, all of a sudden, you know, if if, with without a sort of a human in the loop, you're starting to introduce risks around, you know, regulatory breaches, reputational damage, automated misuse. So, actually, in the context of, this, AI sort of based initiative, the, you know, the the role and this this data around the consent flag rather than being medium criticality, which it historically has been for this particular context of use, it all all of a sudden becomes very high, and I've got 99.5% required here. You could probably argue it becomes 99.9% from a consent perspective, but, you know, they it it changes. So so now it's okay. Right. We've identified what the initiative is. We've associated the the rules and what the good enough score is and where we currently sit in terms of attainment of those good enough levels of data quality. How can we bridge the gap from where we're at at the moment to what the business deems necessary. So the way that the the governance platform supports that is that you can separately and independently capture the issues in a issues asset type. So and those issues will be, you know, over time will be related to the various rules that that that maybe are picking up on those issues. As you do the, as you identify issues, you're gonna be doing a root cause investigation. And so, again, you can capture within an asset type the root causes. And so those root causes may well be process related, technology related, governance related, etcetera. So, again, you've now got the root causes associated with the issues, which are associated with the quality rules. And then finally, it's you're gonna be doing as you identify what root causes are, you're gonna be capturing what the potential solutions are, and those might be quick fix things that you can do in weeks, shorter term things that are gonna take one to three months, medium term, yeah, three to six or more strategic. So so you've got a full flow from your data quality rule through the issues, the root causes, and what potential solutions exist to address those problems and, you know, maybe a T shirt sizing in terms of what the cost would be to implement those those solutions. And so when you look at it from a a perspective of showcasing the value of your quality activities to an organization, you can see here those the purple in the middle, the rules associated with your initiatives. So now you've got your your quality rules associated with your initiative where they've got a risk weighted score, so it's really showing you what's of true value and where the product should be. You'll because those rules are associated with the issues, root causes, solutions, you can, I you know, outline what it's gonna take to get the quality of data to a sufficient level that's gonna support that initiative? That information will roll up into the business objective and then into the strategic objective. So whether it's your walk in executives or management through this within the context of the governance solution or from dashboards that you've created, you can clearly align your quality sort of initiative or your quality activities with the value to the business and the the reason that you you're asking for certain levels of money to to remediate the problems. So just very quickly finishing out on the the main dot points of this is, you know, fit for you know, contextualize basically means fit for purpose, and you should prioritize, you know, your activities by by risk, and not by defect count. And one way to achieve that is via the use of risk weighted quality scores. And with that, I think I'm finished. And any any questions, David? Or else, we'll hand over to Brian. We haven't had any come in, but there's still time for the audience to submit them. Steven, thank you very much. We may have one come in toward the end. Brian Link is going take us through the product road map and the path ahead. Brian, over to you. Thanks, David. Good morning, good afternoon, good evening to everybody. Really excited to talk about some of the the road map here with you guys a little bit, kind of give you insights of where we're headed from a strategic perspective, and kinda give you, hopefully, that kinda aligns with your strategy, and we can talk a little bit more about how we, how how we cross pollinate those two things. So I will take a few minutes just to talk about the the the a three sixty government roadmap. You know, while while this product is really kinda entering a stability and kind of I don't wanna say complete maintenance focused phase, but the our commitment to our customers are still strong in this product. These kind of three investment pillars you see here, performance, security, and stability, are really gonna be the focus. And, you know, these kind of ensure that the platform remains dependable today. So we don't have any there's no sunset date. I wanna talk to you a little bit about, I I thought this was good to have some context around it as we talk about kind of the future and the Suite governance, which is what we've been calling V2. I'll talk about that from a road map perspective so you can see where our investment kind of is is is heading in that direction. So, you know, while while this enables kind of, you know, the dependable product, you know, supported migration path, which I'll talk about today, including dedicated tooling support, kind of enables customers to move to next generation and and modernize governance capabilities in the data integrity suite whenever they are ready. Alright. So all of that, I'll jump to, the suite data governance road map. So let me walk you through really kinda how we're thinking about the evolution of data governance and kinda how this directly helps you operationalize trusted data across your organization. So but before I kinda walk you through the road map, I wanted to kinda anchor on the use cases driving our strategy here. And so we focused on three kinda core areas. That's the privacy and compliance, business led governance, and governance for analytics and AI. I think Anthony and and and Steven actually kinda touched on on a lot of this stuff, but I think these are, like you know, the thought here is that we need to do some foundational elements. There's some core competencies that that we wanna really, really excel at. We really kinda wanna have this business led, lens on the things that we do. And, obviously, everyone's talking about AI, and and how we're gonna incorporate that into the product. So those are kind of the three areas. And I think, you know, across all three, all these obviously, these more, strategic things you'll see in the Nounx later, buckets, are are are all kind of pointing at the same goal and touch across maybe some some or all of these use cases. But, really, the goal is to really kinda operationalize governance. So it really comes become comes how work gets done, not really kinda something separate or, you know, an afterthought or manual for that matter as as we talk about AI. So I'll talk with I'll start kinda start with the foundation kinda and and parity, which is the the now bucket. So really kinda completing the foundation and sharing kind of full use case parity right now in in this in the suite. This really kinda includes, you know, not we've expanded on some things. I know we talked about this modernization as we talk about there's a I I really kinda talk about it more of the modernization versus a migration. Yes. There's a migration aspect, which I'll talk about after this, but I think the idea around this is that it's an opportunity to do both. Right? So with this, we're we're trying to make sure that the the use cases, the core use cases that I mentioned before, are really available in this v two product. And so that we've also haven't expanded on it. So, obviously, ownership was in v one, but we're wanting to expand upon it. So we're gonna do, we're gonna incorporate a domains construct into the product, some more first class citizens so that we can easily assign ownership in those kind of elements. So you can kinda see the the the baseline elements of kind of that core construct that we need, but we're also elevating those things through the modernization process as well. Things like scoring, governance scoring as well. Right? Steve just gave a great, a a great use case around the need around that. We're obviously gonna be doing things to support, things more, natively in the product to do all the things that he had just mentioned in there. Obviously, through analyze, you can do a lot of those things already, but, we wanna kinda have those things natively in the product as well. So that we're we're working on some of the the governance scoring elements and being kind of more transparent about those things. And then the business and technical metadata alignment. This kind of touches on a lot of different things. AI, semantics, kinda automatic classification of CDE, PII, and and really kind of the auto association of business to technical assets. So a lot of that manual, like, stringing work that I like to call it, we're focusing on how we can accelerate that, and and really kind of, reducing the amount of time that, our customers have to spend on those kind of components. So that's really kind of the the now aspect. We're wrapping a lot of that stuff up. The next kind of few things in here is what I'm really, really excited about. And this is really kind of, you know, the next phase here is where we start really kinda operationalizing governance. Right? So then the idea when I say that this is kinda where we make a meaningful shift from governance or being something you maintain to governance becoming something you kinda actively operate within your environment that actively operates in the environment. Excuse me. So the the one of the first thing we wanna talk about here, and try to be quick about, all these things and kinda give you guys a a picture about it, but, I'll kinda talk about these things and kinda what it is and what it enables. So the kinda first I'll I'll talk about the actual governance visibility. So this is kinda, like, role based dashboards and surface things like ownership gaps, policy coverage, and governance activity all in one place. This is kinda going back to what Anthony had mentioned as kind of that core foundation fundamental element of governance. And, really, you know, what this really kind of enables is instead of governance kind of being hidden reports or spread across tools, you really get a clear real time picture of where attention is needed. There's a lot of noise in a lot of these things. And the idea around this is to really kind of surface things that are specific to the user, and what needs action, so that they're able to get in and get out, so to speak, as as quickly as possible to to not only, rectify anything that needs remediation, but also we're also talking about how we can improve your government program. Right? What are some recommendations we might make to, to have to have better ownership around things or whatever it may be? So they can think of this as really kind of like a control tower. So you're not just collecting information. You're really kinda actively monitoring, directing where action needs to happen. The automated flexible stewardship. So, this is really kind of the ability to assign and manage ownership dynamically. We kinda have one element right now where we're we can assign ownership through domains, which is the eighty twenty rule is about the 80%. But we also understand there's different use cases and needs around this as well. So assigning owners based on policies or dynamically or just manually setting up ownership, that's kind of the the aspect of this is we're expanding on, on the assignment capabilities of that ownership. So think of this as kind of instead of signing everything manually to defining rules of responsibility in the sin the the system keeps things kind of aligned automatically. The next really kinda cool thing is the metadata rules. So what this is is really the rules that really automatically update metadata relationships and governance states as data changes. Whether that's new assets, schema changes, or updates in pipelines, that's kind of the the larger vision of it. Obviously, we'll we'll we'll we're gonna deliver slices of that. That's really kind of the vision around this kind of automated, metadata rules. And, really, what this enables is it ensures kind of governance is accurate and up to date without really kind of requiring constant manual intervention. Think about setting a rule around, like, if this, then that. That takes a lot of the work around kind of the manual touches that are required around some of these, you know, staying compliant around some of these things. So think of this as, setting up guardrails. Instead of, you know, directing traffic manually, the system keeps things on track as, you know, even as the environment evolves. Hey, The, other kind of on yeah. to the later, there was a question came in. Could you clarify, Oh, is this roadmap for the DI Suite only or also for GovernSAS? yeah. Great question. That's why I kinda started at top of it is that this is for this is for the suite version. This is the government's roadmap for the suite. As I mentioned, the roadmap for d three sixty is really kind of focused on those three pillars of stability, performance, and security. That's kind of the the path that we're taking from that. So anything related to those things, we'll be we'll be updating the product for. But beyond that, kind of the innovation in that space, and I'll get to this even in the migration phase, slides that I'm about to get to. You'll. kinda see the the the how. How do I get this Right? I think that's one of the biggest questions is how do I get how do I get to all this cool stuff that you have in the suite? I'll talk about that in a second and part of the migration conversation. Great. Thank you very much. Yeah. Of course. Okay. Where is it? Oh, policy. So I'm also really excited about this one. As someone who's new to the industry and governance in general, I really kinda felt like this was, a a really good opportunity to really differentiate and really kind of expand and automate a lot of the things around governance what governance needs. And and, you know, this policy management enhancement, like, I think there's kind of two tiers of this. You see one and then next one and then later. But I think the vision of this is to really kinda, you know, a more structured and scalable way to really kinda define and manage governance policies so they can be consistently applied across domains and use cases. So what this does really kinda creates a strong centralized framework for governance. So policies aren't just defined in isolation, but can be applied systematically. I think, like, the the first part of this is kinda creating that construct or foundation around a policy, setting up the the details around it so that in the later stages, we can have this, the the automated execution piece of this. Right? And so have it automatically understand when things are out of compliance and surfacing those things to the dashboard. Right? And really kind of having that having that piece be really kinda automated and circling that up back to the dashboard where people will be looking to see what needs, you know, what needs fixing and whatnot. That's kind of the piece where this all kind of pipes up. We're gonna have an anchor spot in the dashboard, and we're gonna start feeding things in, policies and and automated elements about policies so they can service things to the dashboard. So they're all kind of what I'm getting at here is they're kind of related in terms of the the policies and the dashboard, but I think I'm really excited about the the policy aspect of this is kind of the automated piece that really seems very, very manual. It's very just documentation right now entering how do we operationalize, really, to use that buzzword again, around the policy side of things. So and then kind of the next, you know, the turning point on some of these things, on the later is really kind of, you know, we're trying to build on that foundation and scale it across the organization. So this is kind of where governance becomes more intelligent, pervasive, and tailored not just to present, but deeply embed across domains and teams. And so a couple items here I'll touch about, like, advanced dashboard. So I talked about the baseline. There'll be some out of the box things that I think most people will want to care about from a governance perspective. But that's not to say, hey. Maybe I wanna create my own customized widget right here. I want I think this is important for this business data steward. Right? Great. I can create that and tailor that for them. Or we can have a couple you know, we can go different ways of this, but the idea around is expanding upon dashboards and making that even more valuable. And and even to kind of piggyback on that, again, it's, like, more persona based experiences. Right? Like, I've talked about it a little bit earlier, but there's a lot of noise in there. But if I am able to see a dashboard, for example, that has that has the things that I care about as a as a data owner, that's gonna be the best experience for them so I don't have to sift through the noise and all the other stuff that doesn't really matter to me in my role in my day to day. The other kind of piece I'm gonna talk to test on is embedded in collaborative governance. So, what this really is bringing kinda governance actions, approvals, assignments, issue resolution, all those things kinda directly in the collaboration tools like Teams or Slack where where people are already working on their day to day. So this kinda becomes governance becomes part of the daily workflows, reducing kind of the handoffs they have and speeding up kind of decision making. So, instead of, like, creating our own thing, the idea here is that instead of, you know, forcing people to use our own our own communication comms, just embed into the flow work that they're already that cut that you're, that the users are already doing. So overall, like, the road map is about kind of this clear progression of establishing a trusted foundation, activating governance through visibility and automation, and ultimately scaling across the organization. Again, with all of one goal in mind, operationalizing data governance. And so moving something and what I mean by that is I mean moving from something more passive and reactive to something more active and proactive across the business. Okay. So now that we got all that great stuff on the suite, you're all probably wondering, well, how do I get there? Right? And I think, what I kinda wanna set this up is really kind of with with two parts. You know? First, why customers are choosing to modernize governance, and second, how we make that transition, structured and as low risk as possible. Right? And so, before we get into details, there are four things to kinda keep in mind about this migration modernization. It's optional. It is structured. It is supported by Precisely Services, and it's really kinda, again, designed to minimize disruption. So Y Suite governance here. I'm not sure how much time we have to go over here. I know we're at we're at time here, David. We're I don't I'll over. a a little bit if you wanna take like, finish this slide out, and then we'll wrap up. Yeah. I think, let me, there's obviously some day to day improvements. The way that it's kind of broken down is operational improvements. These are the immediate things that you'll see in the suite from, the operational side of it. There's the platform advantages, of being integrated and, you know, deeply integrated with data catalog, governance, quality, and observability. There's so there's an advantage at that level. And then, obviously, the future innovation, this is where the the, the AI stuff and all those the the future groundbreaking stuff is where we're putting that into this product. These are all kind of the why you might wanna move to Suite governance. And I think that I I really kinda rushed through that, but I think, hopefully, you kinda get a sense here of of of if you're looking for a good reason to, there's obviously, we can talk more about these things in general if you have more questions around it, but I think these are kind of the general high level of the why's we get rents. I will just jump to the next slide, kind of this journey because in case you're wondering, how do I start this? Right? This all looks great. I want all the stuff that you just talked about, Brian. Just talk about the journey really quickly. It's like, one, once you have this interest level, great. Raise your hand. I think we're gonna have a a if you are interested, I think there's a button we're gonna put up here, and you can kinda raise your hand through this through this meeting. But, ultimately, there's an assessment period, which is really kinda crucial because this part, is where product and services really kinda understands your workspace. Yes. There's a quantitative aspect to this, so understanding what connectors you're using, all those kind of things. But there's also qualitative aspect of it, understanding your kind of bespoke integrations, things that you're working that we wanna make sure that we cover and we have an answer for so that we can give you a complete readout on. This is what work. This will work. This is this is different. This is available, but it's done differently, or this is something we we we don't have. Right? And so this assessment is really kind of to be transparent with you, the customer, to understand where you sit and if you wanna proceed or not. Right? Obviously, if you do, great. We get into project planning, then you get to see more of the detailed things around timelines, milestones, all the things we'll create a specific migration plan for you. And then there's the migration itself. Right? And I kinda put this into two there's two slices of this. One, there's the utility and the kind of the content aspect of it, and moving things over, like, all the relationships, predicates, all the things you've created in v one. All those things get moved over, automatically. And then there's, like, the services side of things where, you know, hey. Great. You we we didn't we didn't take rules, for example. All my rules are still there. Well, that's because rules operate very differently. And, again, this kinda comes to that modernization aspect of we're not just lifting and shifting everything to a new scan on this. There is there is efficiencies and improvements that we've made in v two that don't make that mapping from a migration perspective make sense. And if we could do it, it probably would, you wouldn't be happy with it. So the idea here is that we also have the services layer, with Steve and his team who are already doing a great job with this, is really to kinda take that of, okay. I've had eight rules here to do this. Great. In the new system, I only need one. So here's how we're gonna modernize this and really kinda take what you did before. Let's get the same outcome, right, in terms of what you had in v one, but really kinda do it in a more efficient way and lean on value and the functions that is available in v two. From a timeline perspective, really quick, I I this is really high level and really generic. It's not necessarily specific to your instance. But, again, those those phases and and I have details for each one of those that I'll I'll skip for right now. But, well, generally speaking, like, depending on how complex that you are, you can take, you know, anywhere from two to to five months. It's really kind of the general time frame we're looking at, and you kinda see that journey is mapped out about those months up above as well. So, I I know that I'm being I know I'm rushed here, but I I know that there's a lot of good stuff that, you may have questions on, and I'm happy to, continue these conversations on you know, if you wanna raise your hand, that's great. We can start having those conversations. If it's if it's been we can determine if it's the right fit for you for right now. Great. Thank you, Brian. And. if you are interested or if you you if need a little help or would like a little bit more information, there is a button at the top of the screen that says data governance service. If you click on that, it will be a little form that you can fill out or get some more information, and we'll be able to help you along. We are out of time. We are running up to the top of the hour. So we'd like to thank you on behalf of all of Precisely. We'd like to thank all of our customers. We can't do what we do without you. So we'd like to thank you for your time and interest today and your your input and all your comments on the back end. Thank you very much, and we'll see you next time. Have a great day, everybody. Thanks, everybody.