Name: Operationalizing CoEs Through People, Products, and Funding Models
Uploaded: 2025-06-16T16:30:51.094Z
Duration: 54 min 8 s
Description: Operationalizing CoEs Through People, Products, and Funding Models

Transcript for "Operationalizing CoEs Through People, Products, and Funding Models": Page. Okay. Hello, everyone. Happy Monday. Welcome to today's session, operationalizing centers of excellence through people, products, and funding models, part of our ongoing series on building the next generation of COEs. If you're working with scale self-service data or integrate AI into your business workflows, today's session is all about how to operationalize that vision and make it sustainable. We'll cover what really takes to bring these efforts to life across teams, tools, and budgets. And as folks continue to join, feel free to say hi in the chat and let us know where you're tuning in from. Today, we're joined by two fantastic speakers. If you could go to the next slide, John. Our constant, John Tudor, director of business architecture at Dataiku. And today, we will also be joined by our first guest speaker, Rodell Schwartz, regional VP of services at Dataiku. Today, they'll make sure you walk away with a clear view of how to structure your COE team to scale, how to prioritize and fund data products that drive adoption, how to turn shadow IT into governed reusable tools, and also how to support what you scale without needing to grow headcount. Before we dive in, a few quick reminders. Please use the chat for general comments and thoughts. Feel free to drop any questions in the q and a panel. John and Verdel will answer answer some as we go. And if they don't get to it, we'll also save some time at the end for more. And, yes, this session is being recorded. We will be sending the recording and slides your way after this webinar. And with that, let's get started. John Burdell, over to you. K. Awesome. Thanks, Renata. Good morning, good afternoon, good evening, everyone. John Tudor here, director of business architecture at AIQ. Thank you for joining in here to another session if you joined our first two. And if not, welcome to your first session here as part of our COE series focusing how to scale self-service and AI agents. As Renata mentioned, we'll be focusing primarily on operating model today and also be joined by, Verdell Schwartz, who's our regional VP within global services. With that in mind, as Renata mentioned, please feel feel free to ask questions throughout the, presentation here. We'll look to answer them. So jumping to our first, topic here. How do we think about building a self-service team focused on a CoE or scaling a self-service and AI thread organization? So, importantly, when we think about scaling this, you have to really focus on how do you focus on enablement. How do we empower the business to drive their own outcomes? And this really lines with this idea of, you know, we have a data of a universal AI platform. How do we look to drive AI universally across the organization? And we tend to look at that across really three kind of vectors or parts of a team. So the first of that is really the CEO team or the core team to this type of function. First of all, this is a product owner. This is the individual who actually works out and reaches out across the business to really build that vision and strategy and make that come to life. They manage the backlog, work directly with the product day in, day out, and directly work with users in order to bring in new ideas as well as share those ideas and communicate them across the organization. Much of what we talk about in this series actually focuses on this type of persona. Another type of role is a, platform architect. This is someone who really focuses on the administration and architecture of the platform. How do you design it correctly? How do you ensure that it's governed appropriately? And how do you make it so the platform functions, you know, in the right way to support the overall business? And then finally, you have an applied SME. This is the type of role where you have expertise with individual or subject matter expertise, such as a data engineer or data scientist, who's able to reach out across the organization and work with those individuals to help make them successful on their journey with cell service. Later today in the presentation, Brendell will talk about some of how we staff these unique roles within Dataiku. It can help you do the same within your organization. Another type of team vector we look at is the extended team. Now those individuals who work across the organization, they could be within the business, they could be with another IT team or part of the COE team. Two of these key roles are really the trainers and outreach. So So the individuals who actually train across the organization and perform outreach to help upscale those individuals, help build a culture around data and AI. Another key kind of role is operational support. So think about these individuals who take calls day in and day out to get that consultative support to help the users grow and build more capabilities. This is a very important function that helps you scale out those skill sets across the organization. And then finally, there's really the business team, who's really, really focused on this idea of how do we help the business grow and scale across the organization. In this case, doing it through the business itself. Two key roles we like to talk about here are, one, being ambassadors. So those kind of power users across the business who really help drive the vision and strategy, but also provide feedback directly into the COE organization. There's also champions, and these can be looked at as executive level level leaders across the business who take a role of actually helping drive that vision and strategy and drive capability around data and AI within their organizations. They may define certain kinds of roles within the group, or they may go through and define what kinds of datasets or assets organizations trying to build around data. And just jumping quickly to the question here on the left side that we got from John w. Yes. We can access our previous webinars and the link that has been provided within the the q and a. So kind of taking this idea of how do you build out a COE or how do you structure the correct, types of individuals. Once you set up the COE function, the next step is how do you really think about focusing on the business? How do you start to build this idea of internal innovation and really design thinking where you look at what people are doing day to day and try to find ways to support them in that work? Again, driving towards this idea of embedding universal AI across the business. And kinda key to this is that even though Dataiku and others offer solutions that kind of solve your goals as an organization, there's always gonna be more, and you're gonna know your customers best. There'll always be components of what you do that are unique to your organization, and that part of maybe a third party product. So as part of that, you wanna continue to focus on internal innovation to help drive success and really achieve, you know, the best outcomes across the company. Now my favorite way to do this is this concept of design thinking, which is really this idea of no extension of innovation, where you really focus in the singular problem statement and you try to focus on how do you build the design correctly to enable your users or customers, you you know, to work within that problem statement. So if you're not familiar with design thinking, there's really issue five steps involved in that. First is how you, you know, empathize. So how do you put yourself in the shoes of your users or customers, and how do you actually understand what their needs are on a day to day basis? Once you've got a better understanding of that, do they want to state those users' needs and really what their problems are? What are they facing? Right? What did you observe in working with those users? Once you've got a better definition of that, you then start to ideate. What are some assumptions you can challenge? What are some new ideas you can bring to the table? If you look at a user journey and you see that now 80% of the time, they're stuck on 20% of the items, how do you look to take those items and better tackle them so those users don't get stuck in those periods and they can be successful? Once you've done this, you want to start to try to prototype. How do you try out new ideas and implement new approaches to work? And importantly, try that out across the organization and see if it works in reality. This is a great point to bring your ambassadors, your power users, to try out new ideas. And then finally, you wanna try to test out these ideas at scale. Once you prototype, once you iterate a little bit, let's take these ideas out across the business and test them to see if they really work in reality. Now in terms of their approaches, first and foremost, I would recommend looking at an enablement problem statement around AI or data. Obviously, you can define your own, but enablement tends to be key to programs around self-service. The step model tends to work well within agile or scrum. As you define further user stories or pieces of work, you fill it into the scrum backlog and utilize that for execution. You also need someone like a product owner to really think about how you prioritize your backlog and align that with adoption goals, again, relating to the previous role from the last slide. You wanna observe how those users interact, so observation is key. Humans in general tend to tell you they do one thing, but then do something else in action. So it's very important, though, actually watching the visuals and observe and then take those learnings to make further decisions. And then finally, as mentioned, you wanna make sure you further iterate and test with those ambassadors. So continuing to evolve this idea of a COE, and as mentioned earlier, just this key concept, how do we look at support and operations? And, really, the biggest change that happens within this kind of environment, especially for traditional IT shops, is that you move from this idea of a break fix mentality. We're trying to keep your uptime as high as possible to more of a focus on consultative support. How do you actually work with those in the business, work with your users, and coach them on a day to day basis? And that can be a bit of a culture shift, especially for traditional IT teams and traditional support functions. So with that in mind, you wanna make sure the folks on that support team can do a few things. One, wanna make sure that they can actually support answering questions and challenges around projects and that they can coach and mentor. So, again, this idea of not just break and fix and push the user out, but instead how to look at enablement and empowering that user to make the right decisions. A very important one is this idea of unstructured spaces, such as open office hours, to really encourage open conversations. My find is especially true in the world of AI. Now as we continue to accelerate and the business does more and more of the heavy lifting around data and AI, it's important there's an open space where individuals can cross talk, get support either from the central COE function or from others in the business. But this allows location for community to really develop and for the support function to also evolve and help those users. It's usually recommended having these at least once a week, if not twice a week in your organization to help drive more adoption. Another kind of focus is this idea of quick and responsive support or say ITSM or ticketing processes. Many organizations that we work with have these ticketing processes in place and for good reason. It's how you run an ITSM. It's how you really focus on operational rigor. However, when the ticketing process gets in the way of the direct support for the user, you have a bit of a conflict. So the recommendation is to make sure you focus on that quick support. If you get a ping, if you get a Slack message, respond to that quickly. But then once you resolve that, make sure that ticketing is being tracked in the background so that you can support the user experience, but also get the data. Another kind of best practice is an idea of a tiered support strategy. So if you're joining previous sessions, we talked about items such as documentation. We also just talked about open office hours. But there's an idea as you structure your support strategy, you should be looking at different layers of support. Some of them being more kind of self-service oriented being, here's some documentation or maybe here's a chatbot to help you. Others being more people oriented, such as your office hours as you go up the l one to l four stack. But the idea is that you wanna focus on solving the most common challenges quickly and easily through repeatable tasks such as documentation or chatbot, and then focus on having your support team or your true technical team members, such as your applied SME, actually focus on those kinda higher level challenges that are impacting users and their projects. Going back to ticketing data, once you've actually got collected some of those data, it's important to review it and kinda look at where the major issues happening. So, again, the eighty twenty rule here applies. Most of what impacts the user journey is gonna be based off about 20 of what's actually occurring, and you wanna focus on that to address 80% of impact those users feel. And then finally, one thing you may want to consider, especially if you're a large organization, is how do you actually consider consolidating your teams across your broader enterprise architecture? And many teams start with having a support function focused just on Dataiku or just for self-service program. But as they mature, they may include support functions from, say, their visualization teams or their data infrastructure teams, maybe data governance and quality. But the idea is provide a single entry point that can then fan support out across the organization. This can improve your efficiency and importantly give your users a single place to go when they need support. Alright. So we spent some time here talking a bit more about those kind of day to day functions. Now how does COE looks? How do we start to think about working with the business through internal innovation? How do we build support? Another thing you wanna focus on is how do you actually collect data and give direction? And we tend to think about this as program management metrics. What types of data do you wanna track that'll help inform your decision making and tell you the direction that you need to go as a COE or as a central team? So on the left side here, you'll see some program metrics. I personally used all of these in the past, either, when I was previously a data active customer, but also now coaching our clients in these similar kinds of programs. We usually recommend kinda starting small, so picking two from the left. These are generally ordered in the order of kinda prioritization and the type of impact we generally see. The touch base on many of these, they tend to focus on things like your ROI AI or ROI. So what's the value impact you're getting, as well as looking at customer satisfaction, like net promoter score, or just looking at overall adoption and reuse. So So if you develop a new functionality or macro in Dataiku, is that getting adoption? What types of features are being used, etcetera? But the goal should be to align these program management metrics with your overall goals. And importantly, when you look at the metrics on your regular cadence, maybe over two weeks, every month, whatever that may be, that information should tell you what steps you wanna take next. So once you define a couple of those metrics, you wanna make sure you kinda think about how to track them. I'm a big fan of kinda smart metrics. Right? So making sure they're specific, they're measurable, something that can be reasonably achieved within the time balance constraints, and make sure they're kinda relevant. Right? I also believe they should always be automated. If you don't automate your metrics, you make them a manual exercise. People tend to fall out of the pros, the process of actually collecting those metrics. So it's important to make sure you automate them. Additionally, you wanna make sure they're centralized. So we talked a little bit about the value observability during our last, webinar series here. Same idea applies here. You need to be able to centralize and view those metrics across the enterprise in one place. They can't really be distributed or seen on people's local machines. How do you kinda get that single view? Importantly, you should visualize those over time and look for trends. So as trends change, that should change your activity. You should also look to embed into existing cadences. If you have leadership reviews, leadership calls, internal team meetings, that's where these metrics should be reviewed. You wanna make sure that you maybe have a reusable framework. So as you scale out your initiatives, the number of users, the number of product teams and see who is working on this effort, you might start to see some inconsistencies. So best practice is to actually look at how do you build a framework so the various teams can plug those metrics into one framework and have that holistically for the organization. And then finally, as in my own experience in many of our customers, Dataiku's capabilities allow you to capture those metrics and automate them across many platforms and systems. So as a best practice, we usually recommend Dataiku being central to developing us. And then finally, you wanna make sure you action your metrics. There's not a ton of value in just having them and tracking them if you don't do something with them. So, again, those metrics should be used to drive your team actions and backlog. They should be aligned with your strategic goals and review with the leadership of your organization. If you're working with our data active account teams, you should be talking about those metrics with those account teams, talking about your aspirations and where you wanna go and what you're seeing, then helping guide those teams. You wanna make sure that you're looking for those changes over time to guide the decision making. And then finally, you wanna make sure you evaluate your metrics. What was a good metric one or two years ago may not be relevant now. Maybe the strategy has changed. Maybe the underlying technology has changed. You're gonna wanna make sure you continue to evaluate those metrics and ensure that they're right ones for the outcomes that you wanna drive. So another common, question that comes up is this idea of how do I decide what data products or AI products should be partly developed on my kinda central data and IT teams or maybe those associated with the COE versus, you know, how do I decide which way these data and AI products should be developed by the self-service side of the house? How do we think about delineating these two? And importantly, the most critical outcome in your organization, while self-service is great for enablement, may not be appropriate just for that user base. You may wanna have truly critical operations being run by your AI or data professionals in the company to help ensure those products are really running at their best potential level. So to kinda set this up first is what's the idea of a central data and execution team? And, really, this is a team of data professionals, like you're a data engineer scientist, who tend to learn to work on data products across your business. Now a regular operating model is that a business line fund and the idea of building a new product, and then to assign those team members to executing that product, almost like a rotating bench. Now importantly, those teams can be part of a central team, such as a chief data office or a chief technology office, or they could also be embedded across divisions. Now it's very common to have those team members embedded in the lines of business, but focusing on that work from a data professional standpoint. So when we think about what work should be done by those professionals versus what work should be done in the business, one thing that comes to mind is how do you build a process around how to do this? So first and foremost, kind of going back to our internal innovation topic in agile and scrum practices, you you need to make sure you have an accurate process to estimate the level of effort or work, using the term story points, if you're familiar with agile. Without knowing this, you don't know how much effort your actual team can contribute and how much the kind of central data and professional teams can do in terms of work. And without that threshold, you have a very strong chance of overburdening those teams or giving them too much work. So you need to understand that baseline on what level of work can actually be done. Once you have that, you can then figure out what the predefined capacity is or what team member capacity is to do that work. And importantly, I would recommend having a budget transfer be in place to help enforce and make sure that the work aligns with where the money is coming from. Yes. To the question on the call, we will be sharing the deck, along with the presentation here. So kinda coming down here, once you've defined those thresholds and kind of thought about the budget a little bit, you also wanna think about, you know, how do you utilize self-service as an option when the COE isn't available? So importantly, if if the organization gets request for a 100 data products to be executed, but only 10 can be, the other 90 need a place to go. That's where self-service comes into the frame. How do you start to take those teams and individuals who maybe don't get their work prioritized, give them that option, which is much of what this series talks about. Additionally, you need to have very clearly articulating priorities and kind of, criteria. So ensure that that's very clear for when to make decisions and understanding around. And finally, from a functional standpoint, the best practice is to have a data product prioritization council or a group of individuals who represent the interest of the business and can talk more holistically about what the outcomes from these type of data products would be. A general recommendation is to have at least two representatives from each part of the business. They can speak to the value for their particular business unit and force rank requirements from those groups. And as these teams meet and make decisions around what should be the priority of a product, you wanna make sure you have really strong notes of recording that can then be shared out to the broader organization around your decision making. Because, obviously, you'll get questions about, well, why did you decide to say over this other data product? In terms of criteria, there's a number of them to consider. If you have a funding formal funding processing organization, such as an annualized budget, always recommend to use that funding as the first piece of kind of, defense or discussion. If the funding's in place, we should work on this. If not, it may not make sense at this time. Additionally, you wanna make sure you have full wide month of your business and IT priorities. What are the strategic imperatives? What is the company looking to execute? Is there executive sponsorship and support? If executives are saying, hey. I care about this or this is my priority, then we wanna make sure it's something we're focusing on. The expected and type of ROI is also important. Now ROI can mean a lot different things in organizations, but to me, if it ain't no impacts the bottom line, so your income statement or balance sheet, usually carries more weight than something that may be cost avoidance or something that's saying we're taking no efficiency out of the process, we'd rather focus on that bottom line impact. Another type of idea to think about is if you have an agent solution that's gonna support a truly critical business process. So this process is key to the entire company running. That's something where you wanna have that IT support directly on that product. Again, you wanna kind of focus on this idea of the prioritization council driving that business representation and making the decisions around what is a high priority. So if I have multiple requests in supply chain, I want my representatives from supply chain to help me pick up about what is truly important. That way, we focus on the right things. Finally, we wanna make sure the council overall approves of the data product, says this is something we wanna do. And then finally, any type of focus or work that's been decided to be worked on by the central Canada data execution teams, they should be regularly reviewed to ensure they were truly bringing value to the organization and not something that was a good idea that maybe has lost, with one in sales at this point. So I've got another question here. Sorry if I get the name wrong, but from Adraj. So how hi. How do you prioritize if the central team works across domain? How do the how the team prioritize between multiple functions? Yeah. So that's a great question. So So this is the reason we talk about this idea of a data product prioritization council. You know, at its highest level, when you do your budget setting for the year, ideally, there's a budget allocation across divisions, and those divisions have a certain amount of budget to execute on these initiatives. And generally speaking, I believe that should be the main driver about you have a certain capacity, prioritize within that capacity. However, there's this idea that especially over a time period of a year, that priorities change, business structures change, the outcomes never needed change. Right? And this is why you need representation from across divisions and having a council actually discussing this. You need to have a group of people who may represent your engineering function or your sales and marketing function, you know, supply chain, where that may be. And you need to give them a forum to actually discuss and say, okay. Here's what we think this is important. Here's why we think this is important. That dialogue could help you make a decision of, well, hey. Is something more important to focus on, say, in engineering than sales and marketing right now because we're seeing this as more important to the overall threat of the business? And, really, the only way to do that is to kind of force that representation from both those groups and then have those conversations to get to that outcome. So, again, I would say recommend focus on the budget first. But as things change over time, I would recommend having that broader representation discussions if you can get those cross organization decisions to say what is the priority. Great question. Coming back to our slides here. So pretty closely tied to a lot of these conversations is the idea of funding models. There's something I've heard in the past from few different executives is that, you know, the business gets interested in driving a program around self-service or growing something like this. And when that happens, sometimes IT or data teams are caught off guard. I've even heard the term, they're trying to escape the jaws of the lion because there's a lot of interest coming from the business. Then maybe IT isn't necessarily ready, especially from a budget standpoint. It's very common for those who are, like, in a CTO role, as an example, to have cost and initiatives, which can run a little bit askew to me trying to empower the organization with data, right, and spend money to do so. So a lot of this comes down to how do you think of venture funding. And, really, how do you balance across what I would call your COE, your kind of central team funding, versus your p and l funding or profit and loss center within the business. So if you're not familiar with P and L, think about that as being a certain business division, again, such as your finance team or sales and marketing team. They're a division of the company that may potentially have a profit or loss tied to it. So there's really four different models that we tend to see within organizations. Some being better for earlier in the journey in a self-service program. Some being, you know, more for later in the journey once you've gotten to more of a sustainment level and growth across the business. The first model here is this idea of a central COE funding the program and then also retaining the dollars. Now probably worth a little bit of conversation here on what funding versus retaining means. So when you make a purchase of a piece of software, usually in the business, right, that is a funding or the purchase order that you're making. So a particular business division will pay for something. That said, within the company, there's usually internal accounting principles that allow you to move the actual expenditure to different divisions of the company based on where the cost actually lands or where it should be aligned to. So that's what funding and retain your friends do here. Funding being who's actually paying for the purchase order or making the purchase, retaining being who's actually retaining the cost within the internal budgets of the organization. So this kind of first model where we have a COE funding and retaining, this means that the COE is both paying for the content, the licenses, the software, but they're also retaining those costs within the budget. And this is where many organizations start, and it's really good for the initial driving of a central strategic priority. Right? By showing that you're gonna focus on the central function, spend the dollars to do so, you communicate more broadly to the business. This is a priority, something that we really wanna focus on. And that can lead to more integrated growth, communicates a stronger message around that growth. It helps ensure there is no kind of cross organization funding misalignment. Right? So you don't have one group saying, well, I funded this so I get this. No. It's all funded from one location. And helps ensure that, you know, you don't have any, you know, issues with your p and l funding, not being able to support your program. And importantly, your your support funding is also very much included on one spot. That said, you also are missing your p and l growth lever. So you can only grow to a certain point as a COE, funding everything yourself. You can't leverage money from the business to grow further. And the that would be the biggest one here is that your spend is not necessarily tied to your user value. So you have one team paying for all the use all the content to make everything available, but you have many teams getting the use and value out of that. And that lack of accountability can sometimes be a little bit hard for the central COE team to maintain over over time. So moving over to the right here, where we have the P and L funding and the CRE retaining. This is not too common of a model, but it is one that you start to see happen more and more, especially when a COE has a constraint to how much money it can spend, but a P and L does not. And And this can be a great method in order to get, you know, additional funds for a PNL to help grow your program like this, but do so in a way where that funding isn't coming from a central organization. So for this kind of model, you do get growth levers across the PNLs. Your spend is more directly tied to use in value because P and Ls are actually funding it upfront and also enables the CUA to scale more indirectly through the P and L, which is unique to this scenario. That said, this can also stifle organic growth a little bit because ultimately, all the funding is coming from PNLs who wanna do that growth. If you're not in that group, you probably won't be able to have access to get what you need. This can also cause some cross organization funding misalignment and can leave an open question around who covers certain central costs such as a platform. Now on the bottom left here, we have really the central c v funding and the p and l retaining. And this is really the best practice that we see most customers land on from a long term perspective. And the reason is is because you now have the central kind of focus of being able to fund and fund a larger contract for the organization, retainment across your p and l's and divisions. Meaning, the work being done is being tied directly to the value being created and the funds being used to set up that value. So that's a really nice kind of long term model once you have that broader business buy in. So, again, a lot of the same value propositions are here, organic user growth, your spend being tied to use and value, p and l growth levers, etcetera. The one challenge you may have is that you could set up cross funding, you know, challenges within the organization. The best practice I will recommend here is that by setting your budget early, by doing this within your annual budget cycle, allocating licenses, and then looking at an annual basis to how you're going to do that retention or how you're going to do that assessment to the business can help you largely get around this. So if you follow this model, I do recommend long range planning and focusing on a retainment schedule that actually looks at historical uses of licenses to break out that budget spend. And then finally, on the bottom right here, it's probably the least common model we see, but it's one where the business directly runs a program and COE is not involved at all. This is where the P and L both funds and retains the cost. Again, this is where you'll have a good growth lever from the P and L, so that'll be tied to value, etcetera. The problem is is that you also don't really have, you know, this idea of a centralized organization or really controllership and ownership. So going to the third con here. Right? You have a significant kind of software governance risk because there is no IT or data team oversight. You have an individual business team running off on their own. This This can be a great way to kinda start a program, but ultimately, over time, we usually see these individual teams fold their ownership of the program into a broader COE that focuses on the business. So not a better place to start, but usually not somewhere where you wanna run long term. So I've got a few other questions over here, so I'm gonna jump back over to q and a for a minute. So first one, I believe, from Koichi. So, hi, John. Ideally, where should the COE live work wise? So as an example, under the CTO. So it kinda depends on how you structure your business. I would say, overall, I actually think it's the chief data office, but that depends if you consider your chief data office to be part of your CTO organization or not. I'm of the belief that your kinda lead data analytics leader should be someone reporting directly in the c suite, not necessarily someone reporting to your CTO or CIO. So if you're within that model, I would recommend that COE being within that data organization. That said, many companies kinda have that data organization, you know, within their CIO or CTO functions. So if it's within that function, I would recommend having it there, especially because many, CTO organizations will wanna manage the platforms within them. And, you know, platforms such as data, who will usually fall underneath that bucket. So generally speaking, it'll be the centralized function around data and IT, whatever that may be in the company. You can have CMEs in lines of business, but that can kinda hamper your ability to grow overall and across the entire enterprise, which is important for getting the most value of the data and AI. Mhmm. Alright. Great. Appreciate the good question. Come back over here. So our next one here is really, the idea of data and AI roles. So you may have seen earlier, we talked a bit more about the idea of the COE function or what are those kind of COE roles. This takes a little bit different view and says, okay. If you look at how we look at data and AI roles across the business, where are the right roles to really start building an AI literate culture and a culture that's more focused on the use of data. So how do you play these roles to the business? It's really a different take here. And you kinda see six roles presented here. So first is the owner. Now this is a person who actually makes the dataset or the owner of the IT application. Importantly, those owners are usually, you know, the ones who are the best to talk to about who should have access to datasets, so they should know if there's any sensitivity, privacy, things like that related to it. And they should also ultimately on the source data quality. If they created the dataset or on the system that creates it, then they have to also manage the quality because you wanna address quality as far upstream as possible. Another key role is really a steward. Right? And this is someone who has the subject matter expertise around the contextualization of the use of the data or AI product in the business. So they understand why they would use this here. They understand how it applies to the function. And as part of that, they're usually best of giving you the context around that data. They're usually individuals who do a lot of data catalog work. So putting in the metadata described, here's a description of the dataset. Here's why it applies to the company, etcetera. And I think importantly, they're also the best folks to identify quality issues. So if you can imagine a steward overseeing a dataset or overseeing a grouping of datasets and then seeing something that's usually off from a quality perspective, they can then take that quality finding, pass it upstream to the appropriate owner within the ecosystem, and that owner can fix that quality issue. Now you may ask, well, why wouldn't the steward just wanna do it themselves? Well, you wanna fix quality at source and not downstream. To fix it downstream, you may fix one issue and you may have 10 others. But if you fix it upstream, that one fix can then propagate to all 11 solutions. So ultimately, there's a relationship with our stewards and owners where quality is getting identified in datasets along this business context, and then you're fixing that quality issue upstream, which further drives the adoption of self-service and AI. Another key role we've talked about a few times is an ambassador. So this is someone in the business who is, I'd say, excited and passionate about building data and AI across the company. They can really help you with grassroots growth and working with the business and providing in contact support for those business lines. They're great for intro feedback, and they're really a good proxy for your user needs for building a closer relationship, understand what people are working on every day. You also have a champion, which, again, we've discussed earlier. This is more of that senior business leader, someone who can really help drive the domain data management. So what is a reusable dataset for the domain? What is the right datasets? They can be great for kind of reinforcing that data and AI strategy, and they're great for structuring data roles. They might define who are the stewards within my team, who are the ambassadors. Right? Who starts to think about that? Again, you have your trainers and outreach, which, again, we discussed a little bit earlier. They really bridge that gap between the technical and business sides, overcome the little gap, if you will. So helping people get to those first few steps. They can be the ones who help you conduct training sessions, especially if they're embedded in the business. They can bring an interesting angle and help users adopt from that training. And they're usually pretty good at scoping, you know, actual projects and what they could look like. And then finally is really the user, which as we like to say here, they kinda bring the data and AI story to life. These are the folks who are doing the work day in and day out. Importantly, once they start to create data assets, they move from this user group to actually being an owner within the organization. So you have to understand the responsibilities as they start to work with data. And in point o, they're also the SME and the business domain and bring that experience. And then finally, you know, ultimately, they're the ones who really make all this work. So our series is really focused on that persona. And then finally, last item we'll cover here today before I pass it over to Burdell, is really this kind of idea of how do we start to look at how do we take shadow IT or how do we take the things that we know are happening within the business and start to measure that and turn that into really innovation or what our focus is gonna be from a, you know, focus and project growth perspective. And one of the cool things you can do when you're looking at an ecosystem like this is apply this idea of observability or oversight everything's happening. Once you have that oversight, you can really start to drive decisions off of that and understand your data and product portfolio better as well as the innovation happening through self-service. And as we like to say, this is really a representation of how Dataiku can drive that AI universal, platform mentality because you start to see this grow across the business and the value being driven by AI, the business process adoption. So to kinda start, let's go over to the left side here. The first thing you'll need to look at is how do you understand the number of unique monthly users? So let's say we have, you know, hundreds or thousands of data products in the company. In order to determine the value of the data product, you need to figure out how commonly it's used. Right? What is the amount of adoption that's occurring around it? Is it being used regularly? Is it really impacting the business? And the way to do that is to measure how many unique users you have. So for the table, maybe it's number of queries. If it's maybe an analytic or a model, maybe it's the number of result queries or API calls against it. Visualizations could be views. If you do an ALM queries or AI agents, it could be the narrow prompts, unique processes that go through it. But importantly, to all this, you have to make sure that what you use are working with is a web based and not a desktop tool. If it's on a desktop, you can't see it. You don't know the activity is happening. And you probably wanna centralize data storage or mesh, for those who are within our second session. This ties back to those foundations for a self-service program from an architecture standpoint. That observability across a enterprise data ecosystem like this really allows you to kind of start to elevate and see this type of information. If we jump over to the right side here, I'll give you an example of what this can look like in practice. So we kinda look at this as like an innovation funnel, because you'll see it's a little higher you know, larger at the top and then kinda scoots down to the middle here. So if you can imagine having, you know, thousands of data products that you're evaluating, you can start to look at, you know, what's the amount of adoption we're seeing or unique users per month to understand the importance of that data product. So let's say we might call it a proof of concept if it has, you know, a non animated product doesn't run on a schedule. It's got five unique users or less. So we're just trying a brand new idea, proof of concept, no major commitment to it yet. Once we've automated that or started to schedule it, and maybe we see more users, so say six to 49, Now we're trying out this new idea. We're piloting it, and we're seeing, does this actually impact the business process? Are we getting the adoption and usage on a regular basis that we would expect? And then what we tend to see is really this kind of breakout point or where things really start to bring clarity and you see value. And Adi here is really a product. So this is where you've automated it. It's embedded in the business process, and we're now seeing 50 or more unique users a month. And, generally, if you see that much activity in that many users, that likely means the business process has been heavily adopted, and we're really starting to see value come from that. And then finally, you might have this critical product, which is the same as the product, but now we have an executive stepping in saying this is key to our organization, and we wanna make sure we support this. So it gets a little level of emphasis. Now in some of our customers and organizations, you may see maybe 15 to 20% of the overall work being done by end users get to this product level. So while there's value obviously in POC or pilot, the highest value is gonna be product. Right? And that's where you're gonna wanna focus on and see the biggest gains within the company. And importantly, we wanna focus on this idea of how do we manage those products correctly. Right? We don't wanna have something running, have a self-service user be out sick, something else happen. They can't run the process and the business is relying on it. So you start to think about how do you drive further support and operations for these new ideas. And That's where we get down to the bottom left here. Right? So the more data product is used, the more effective it is, and the more it's embedded in the business. So what you wanna do is make sure that you highlight those data products and the ones that you see as best of breed. Those are gonna be the ones you wanna make reusable and kind of shift to the rest of the company and say these are good reusable assets. You wanna highlight these. Now importantly, you wanna do some portfolio management around it as well. So if you have various IT departments across the company or data departments and central data teams, What you wanna do is take a look at these products and then decide, hey. What should I do with these products once they get to a certain level of scale? We usually recommend those 50 or greater users, but you can use whatever indicator you'd like. But what we recommend is on a regular basis, monthly, quarterly, meet with the leaders of those groups from the IT perspective and say, here's the data products we've seen from self-service that I've gotten adoption. And then you can decide to say, okay. Well, I'll keep it as is. So I'm gonna allow, you know, the business to continue to run this data product. We'll accept any risk of having maybe an individual or small group of individuals in the business running this. Maybe we decide to move it into IT. Maybe it's such a successful data product showing value that we wanna put the right support and operations around it. Maybe add 24 by seven support. So then we work to transfer that product within to the IT organization. Maybe you combine it. Maybe IT is working on a data product that's similar to the self-service user. You put them together. We build the best of breed out of that. Or in that, maybe you remove it. Maybe what's been developed is determined to be lower quality. Maybe it's something that's, you know, maybe a smaller initiative compared to a larger, say, ERP initiative in the company, so we decide to remove it. But what's very powerful about this is, one, it shows your business process adoption, how the company is changing from work that you're doing around self-service and AI. But, two, it allows you to connect the work being done by your data professional teams and IT teams directly to the grassroots work by your self-service teams. This builds an innovation pipeline to help further focus your data products in the company. So with that in mind, I'm gonna go ahead and pass the ball over here to, Verdel Schwartz, who is one of our, global services regional VPs to talk a bit more about how we can bring these type of services and capabilities to you as a data aggregation organization. So with that, Verdel, over to you. Alright. Thanks, John, and hello, everyone. So today, I just wanted to spend a few minutes highlighting how Dataiku's global services offerings can be instrumental in operationalizing AI through centers of excellence and ensuring scalable self-service and responsible AI agent adoption within your organization. So what does all that mean? Let's talk about it. So first, we'll focus on two key roles offered by Dataiku, the technical account manager and the data scientist in residence. These roles are designed to bridge the gap between technical expertise and the business needs of your organization, empowering your teams to drive meaningful results. First, let's talk about the technical account manager or RTAM. These are experts in administration, architecture, and support of the Dataiku platform within your enterprise. Their primary role is to provide ongoing technical advice regarding Dataiku platform security, configuration tuning, and optimization. Think of them as your primary technical advisors. They'll work closely with your admin teams, offering guidance on everything from reference architecture and deployment to platform configurations. Another key aspect of their role is mentoring the admin team foster ongoing knowledge transfer and ensuring your internal teams become self sufficient in managing the overall platform. Furthermore, they'll facilitate prompt issue resolution by helping implement configuration changes based on Dataiku best practices, recommendations, from the Dataiku customer support team, and ensuring the platform runs smoothly and efficiently overall. Next, we have the data scientist in residence or our DSIR. These are experts in data science, business analytics, and developing on the Dataiku platform. They're embedded within your team to provide ongoing technical advice, focus on best practices in data science, change management, and project operationalization. For example, a DSi can work directly with your data science or business team to identify a solution that can be implemented on the Dataiku platform. They're able to develop a proof of concept, demonstrate it to your team, and then instruct others on how to enhance and expand its functionality to fully operationalize the project. This means they're not just solving problems. They're also building capabilities within your organization and fostering a culture of self sufficiency. They're your go to resource for hands on guidance and accelerating your data science initiatives. So what does this mean practically? When Dataiku engages with your center of excellence, we'll bring a robust delivery framework that integrates the specialized expertise of both the DSIR and the TAM within an agile methodology. This approach is designed to maximize collaboration, accelerate outcomes, and ensure your COE is fully empowered to operationalize AI at scale. Our framework breaks it down into sprints, allowing for continuous planning, prioritization, and rapid adoption to evolve, to evolving needs. The DSIR and TAM work in concert, leveraging a shared backlog of initiatives to guide their efforts. The DSIR populates and refines the data science and business analytics aspects of the backlog, identifying use cases, developing proofs of concept, and leading project ideation. They also build the internal team's capabilities through hands on guidance and instructor led training. The TAM ensures the Dataiku platform is optimally configured and maintained, managing technical administration and architect texture act aspects of the backlog, providing expert advice on security, performance tuning, and issue resolution. This combined approach orchestrated through agile sprints and a collaborative backlog ensures the technical excellence and data science initiatives progress hand in hand. By leveraging the complimentary skills of the DSIR and TAM, you can accelerate the momentum of Dataiku and AI within your organization. And so both the data scientist in residence and the technical account manager are critical components of the global services offering designed to empower your COE and drive successful, scalable AI adoption. And by leveraging these experts, your organization can streamline operations, enhance capabilities, and achieve your strategic AI goals with confidence. And with that, I think we can open it up for questions. Awesome. Thanks, Purdell. And, I know we already have one question over here in the chat, but please go ahead and feel free to add additional questions. And we'll have q and a open here for about ten, fifteen minutes. But with that in mind, let's go ahead and jump to the question from Kathleen, which I believe is tied to the the previous slide before, you know, Bradel's slide. So how are we able to map prompts and queries to a data product for measuring? So let me come back here. I'll just put a little visual with this. So for those following along, this is kind of up here in the top left. So measuring these ID of the number of queries we have or prompts that are happening. So let's go ahead and start with the queries on, on tables. Right? So let's say your data product is producing a a dataset. It's engineering an output. Right? You're building an analytic. The way to look at that is simply to see how many queries does that particular dataset get. So let's go back to this idea of observability. Right? We talk about having centralized data storage or a mesh. So maybe you have a data lake house. Maybe you've got a mesh on top of this. In any of those methods, you're actually able to see the queries that are coming in through that lake house or through that mesh to that data asset or dataset. So So what you're wanna gonna do is actually track the number of times you see unique queries against that and which IDs are directly working against it. So, again, it's kinda highlights the idea of having observability here. You really need to be able to see the activity across the data ecosystem to understand what's happening. Right? If you, don't know where those queries are happening and you've got a particular dataset that 500 people are querying, you may not know how important that dataset is until it gets changed someday, and then you got a lot of people who are kinda grumpy. Right? So it's important to really track where that's actually happening and actually see those queries against it. Explain that a little bit further in terms of, like, prompts. So that really depends on how you've structured your prompts, your LLMs, your agents, etcetera. Right? But you should be able to track the number of prompts that go through, again, to kinda tie to something we'll talk about a bit more in our next webinar on governance. If you're looking at our LLM mesh product, right, you can actually direct all of your prompts and traffic through that mesh in order to ensure you're no destroying out toxicity, to ensure you're managing cost, etcetera. So through that same process, you could also track how many prompts or we'll call them queries are coming from users. Right? So how many prompts are coming from this particular interface or this data product? You know, are these being successful? Are they actually answering those customers' needs? So what you wanna look for, how many prompts or particular, we'll call it LLM queries, are coming from users either through the interface that user is using or if it's an automated process such as an agent, how many times the agent, how many times the agentic AI process is being triggered based off either a user input or similar type of automated process. Really, really great question. So do we have any other questions here either on the, within the chat? K. We got another one here. How do you reconcile the segment and nature of scrum, new story per time segment with sorry. This gets cut off. K. How do you reconcile the segment and nature of scrum, new story per time segment with end to end value and efficiency measures, especially on repeatable delivery processes? So, sorry. I just jumped on me there. So I think the way you would think about it. Right? There's this idea of end to end value. So let's talk about in the context of the COE. Because of the way that you look at scrum, you can apply scrum to the execution of data products, or you could also apply a scrum to the execution of a COE supporting, say, a data accrue platform within a company. So I'm gonna talk about it from that COE type of structure. Right? So the way to think about that would be that segment in nature of Scrum. So you're creating a new stories every couple weeks. You're prioritizing every couple weeks. Right? So to me, that's a focus on that iterative type of work you're doing. So if we go to those, program management metrics, if I iterate and build a new macro, a new capability, a new integration, that's a unique piece of value that I can potentially track. So that's for your metrics. Right? You wanna track and see how much you need work is happening against that. Now when I think about end to end value of, like, the efficiency measures of the overall system, they actually get more to those kind of broader metrics and looking at that overall value. Right? So we just have the example of kind of this innovation funnel. I'd recommend I'd just kinda say that business process adoption is usually one of the largest metrics that companies look for because they don't wanna just bring in data and AI products. They actually want them to change their business. Right? So using a model where you're evaluating the overall adoption and consumption of those data products is more of that end to end kind of efficiency measure and really even the repeatable value and delivery. Right? Because every one of those data products is following the repeatable process that you've laid out that the users are working against. So that's where I'd say the difference is is that broader measurement. You could also use, like, broadly measuring ROI or broadly measuring usage. So as an example, if I have a new capability in my scrum, that scrum ideally with that new capability will help me have more users or have more user adoption and retention over time. So what you wanna do is look at those small incremental changes from the scrum perspective and see how that changes your broader metrics over time for overall program efficiency and delivery. Awesome question. Another one here from John O'Donnell. So, John, different spelling, John, experience with IT audit teams and recommendations for engagement strategies. Well, what I would say is definitely join our next session. We'll be talking about governance. In the very first part of that section, we'll be talking about how do you align IT compliance and regulatory with programs like self-service. So we'll do a deep dive directly to that in the start of the next webinar. But generally speaking, at the end of the day, you have to kinda really focus on this idea of balance. Right? You can hear me talk about this in the next webinar, but it's kinda like running a playground when you have a COE hat like this. Your goal is to ensure that you're, you know, helping others have fun, do the best they can, but also keep them from hurting themselves or others. That's really that balance of self-service and enablement with the balance of governance around that. And what I find to be a best practice, say, your IT audit or compliance function, is that right up front, when you're designing the system, when you're creating what this is gonna look like, you bring them in, you map the controls, either internal or external regulatory, and you make sure you build the architecture and process in such a way that you're inherently meeting what's being requested by IT audit or by those organizations. Right? The concept we tend to call is architectural governance, which, again, we'll do a deep dive in the next session on that. But if you design things in the right way, it's the idea of making the right path the easiest path. So design the correct way to meet those audit requirements, to have the appropriate controls in place, but at the same time to empower users. And just to give a little spotlight, we feel here at Dataiku, we have a very strong value prop to enable that type of work and to empower you just to kind of balance those two items, which to me really ties to the questions from IT audit, how you meet those audits. The last thing I'll kind of share on top of that is that, again, observability is very clear here. So let's say you put your controls in place, you've been running for a while, then IT audit comes and knocks on your door. Well, you need to be have an idea of what is all my utilization of my data? Where is my data going? How are people developing with it? And, again, this is where this observability missed oversight, especially as discussed in the last webinar, comes into play. If I can't see what people are doing, if I can't track the lineage, I don't know the work they're working on, I have no way to respond to an audit either internal or external to tell people how my data is being used. And that's the surefire way to kind of fail that audit. So you have to build in that capability from the beginning and then make sure you track it so you can answer those questions. We got another one here from, I believe, Chant. Of what size are the companies you're seeing forming AICOEs? All the way up and through. I work with companies that have 200 to 300 employees up to companies with 300,000 employees, and we're seeing all of them do it. Now the way that they do it may be different. The smaller company may have less numbers in that COE. They may have a smaller tight knit community than, say, the 300,000 person company that may have employees all over the world. Right? And to me, I think it really highlights, especially when you get to that broader scale, the large organization, how much you have to rely on the business. Right? I've been part of programs in the past personally where 90% of the people are helping grow these programs. They're actually on the business side and not the IT side. The IT side serves kind of the waves, builds up the momentum, make sure the governance is in place. But the business teams are the ones out there doing that day to day work and helping that growth happen. And that's really important, that large organization, because you may not have people in all different regions around the world that the company works in. You may not have all those resources in place. So at least from my experience, I'm seeing it across the map and really all sides of the company as well as different industries. Verdel, I don't know if you have anything you want to add on top of that one or any other questions, but that's definitely what I see. Yeah. No. I think you hit it. I think the the key is that the fundamentals of what a COE does can scale. And so there are ways that we can that it that we've seen it implemented in smaller companies, which which creates best practices around how intake and output is generated for AI, as as well as how you would scale a large organization, have business units working with each other through essential functions. So, how you implement it is probably more telling, than the size of the company dictating whether or not there's a COE in place. Awesome. Awesome. Great. Well, I don't see any other questions here. Really appreciate all the great questions here today. It's been great all three webinars. And with that, we'll go ahead and pass it over to Renata, the curious out here today. Yes. So it looks like we covered all the questions for now. And to me, that's always a good sign that John and Verdell explained things very clearly. But if anything comes up afterward, please don't hesitate to reach out to us. We're always happy to keep the conversation going. And as John has teased a little bit, our next webinar in the series is just around the corner. It will take place next Thursday, June 26 at 11AM eastern time. In this upcoming session, John and Jacob will walk us through the governance blueprint so easy to use to scale self-service and AI agents. You can scan the QR code on the slide to register and or sign up through the link that was also dropped in the chat. If you're unsure on whether or not you can attend this webinar live, we still encourage you to sign up because as always, we'll be sending the recording to everyone who registers for it. Thanks again for spending time with us. We hope you found this session insightful and that it sparked some new ideas or perspective. And, of course, a special thanks to John and Verdell for leading the conversation. Your contributions and expertise truly brought the topic to life, and we couldn't have done this without you. Other than that, looking forward to seeing everyone next time. Have a wonderful day. Bye.