Alrighty. Let's get going. Welcome. You are at an Intoworks webinar. We are going to be covering BI three point zero in practice. So how do we go from the current tools that we've got to really take advantage of AI augmented analytics? We're going to be talking about that in some deal detail today. I'm Robert Curtis. I'm the managing director for Interworks looking after Asia Pacific. I am based in Melbourne. A very it's a nice day today, but it's been pretty cold the last few weeks. I've been with Interworks for around twenty years leading our business operations over in Asia Pacific for, I guess, the last ten. So I've been here for quite a long time, had a pleasure of working with thousands of customers on their data and analytics journey. It is a pleasure to meet you if this is the first time joining one of our webinars and a big hello for those that are returning. A little bit about who Interworks is. We do basically three things. We do data strategy solutions and support. So if you need ideas on where to go, how to get there and what to do, once you're there, we are the company for you. A little bit more of a detailed look at what we do. So starting at the top, we do strategy services. Those might be assessments. Those might be accelerators, evaluations, scorecards, blueprints, spec and selects, all sorts of things. If you then go down to the next layer, we help you build the foundations that might be cloud. That might be other platforms and infrastructure. We help you build your data platforms, build the pipelines to get you highly curated data sets to your users. And we also can assist you in building the governance, whether it's the policies and frameworks or the actual implementation and governance tools or platforms themselves. Another layer deeper, we can help you solve those problems. So once we have our data and all of our foundational things set up, we can help you build analytics, reporting, advanced analytics, AI solutions. We can help you with your data science efforts. Once you start kicking goals and you're looking to build and sustain and continue to grow, whether it's a community of users through centers of excellence or things like that, or individuals and building their skills or supporting the applications and functions and tools that build and drive all these things, we can help you with all of that. It's important to note that we can meet you wherever you are. So if you've got aspects of this covered, but you need other things supported, consider us a Swiss army knife or puzzle piece into fitting in wherever you need us. Unlike a lot of other consultancies of our size and sort of our focus, we've been business for more than thirty years. We founded all the way back in nineteen ninety six. We started in the States. We expanded all over. So I think we're in ten, fifteen countries, something like that. So we've got a tremendous amount of experience. Seventy five, I think it's closer to seventy seven if memory serves. So the Fortune one hundred have been or are our customers. The biggest names that you can imagine, you can go and read about those case studies on interworks dot com if you wish, but they are the name brands globally that are driving amazing results using data analytics, AI technology. And we have tons and tons of customers all over the world across every vertical and of all sizes. So we've got a lot of good stories, a lot of use cases we successfully implemented, whether it's an energy, mining, financial services, public sector, you name it. Something that would encourage you, and a lot of you might know us through this, we have a very rich and detailed and expansive blog on data and analytics and platforms and all kinds of stuff related to this vertical, this industry. We get around three and a half to four million page views every year just on that blog. I am shocked and surprised even after twenty years at Interworks, going to conferences or going into venues for other trade shows and things like that, and people seeing my name badge, Oh, you're with Interworks? I've read your blog. It happens dozens of times anytime I go to any of these places. And it is amazing just how much work we've put into it and credit to our marketing team. We've received a lot of awards. I'm not here to brag about the awards, maybe a little bit, but somewhere around twenty to thirty partner of the year trophies across analytics, ETL, data, you name it. One of the ones we're really proud of is Forbes put together a list of small giants, twenty five small giants. This was a couple of years ago across all different verticals and Interworks was selected to be one of those. So maybe a team of three hundred, three fifty consultants globally, but we punch way above our weight. And hopefully, in your experiences, you can see why. I wanted to call out that the Snowflake world tour is going to be in Sydney on the thirteenth of August. Oops. That year is wrong. I looked at this at least a dozen times. I'm gonna fix it right now. And always something slips through this year, not last year, this year, we will be there. So if you happen to be in Sydney at the Snowflake World Tour, drop by our booth and say hi. We've got a lot of team members, technical people, salespeople, strategy people, all sorts of folks. So we'd love to have the conversation with you and in, in supporting the opportunity that snowflakes present into going into a future state, looking forward in terms of what's possible. We're doing a very robust empowerment strategy, a series of webinars and a white paper to help get you guys thinking big ideas for what could be next for you. The white paper, which I wrote is based on the semantic layer, how it is now, a load bearing structure for AI that is available now. So you can actually go to interworks dot com and sign up and receive it. And then we'll have all of these webinars, almost I think there's another one in there that we're still planning on, I think, September second, but there'll be one almost every week for the next five weeks, not including this one. So tons and tons of opportunity to upscale, to learn, and to strategize and plan for what would be next for you. If there is more content or you wanna share this webinar or others with your friends or colleagues, they're all on into works dot com. We record everything and we throw it up there for your use for free. So hopefully you find these useful. We certainly enjoy getting to talk to you. Alright. Let's get in here. So we're gonna talk about BI three point o. But first, let's talk about a little bit more about BI. So I have a whole webinar that I did on this topic. So we're just going to summarize really quickly, but basically we're three waves of BI, including a pre wave. And they kind of grew into the types of questions that you can ask and the way that you can get those answers. So the PreBI is, wow, we have data and we can present it. We can find it. It's not lost in a database. Wave one, 1990s to 2000s is really what happened and when did it happen. So that's your reporting looking backwards. Wave two, which we've largely been in for the last fifteen years or so, is the how and why. And those are tools that were that whole BI two point zero was really started by Tableau. But other tools have come along and joined the mix, like a Power BI, for instance. Very, very highly visual, self-service. Some of them are a little bit more self-service than others in terms of the ease of use. You could get better answers than you could say with the previous iterations of BI. And then of course, we'll talk more about what the future is, which is BI three point zero. If you've been to any of the webinars this year, you'll know exactly what I'm going to talk about. Now let's do a little bit of an inventory autopsy review retro on BI two point zero. It set a very specific goal and largely it was very successful in achieving that goal. But I think now that we've got a new future, a new paradigm at our doorstep, we can see it kind of missed the point. So the goal was that everybody can build a report. Well, everybody, but everybody can build a report. That's what BI one point zero was. If you want data, here's a report, but only IT people can make it. Now, everybody can make one. Everybody started using BI two point zero tools to varying levels of success. Everybody can search and start to visualize these questions or or almost everybody. Every question really, though, meant dashboarding. It might not mean a new dashboard, but it certainly meant I have to go modify dashboard. I had a filter. I had a parameter. I had more data. Or I build myself a new dashboard. So if the goal was everyone can build a report almost, well then that was successful. But again, was that the point? Was that really the ultimate goal to give data driven insights to business users? Well, no. Not really. The goal the real goal should be that data insights are easy to get. They are efficient to get. And the problem with BI two point o is that, as I just said, every question meant we had to do dashboarding. Every single question. There wasn't really a lot of enterprise level standardization or planning inside of the product for how to best discover these dashboards if we ended up with a lot of them. And boy, did we end up with a lot of them. Or how to retire them or flag, hey, this needs to be refreshed. And so dashboards piled up, people left the organization, so they were now ownerless. There was no life cycle of when and how they became useful and then stepped back out of the limelight and got archived. And honestly, no real easy to tell which one was the good one. Everyone started inventing an overlay of process to overcome these challenges to varying levels of sophistication and varying levels of success. So this in terms of what the actual goal was, was largely a failure. And as more and more people leaned into BI two point zero, they started to encounter more and more of these problems. And the biggest problem is this idea of dashboard sprawl. I did several webinars on operating models, BI operating models, that kind of thing. What I'm talking about here where this gets really bad is in the wild wild west, which is everybody doing everything and potentially with multiple tools. No governance, no structure, no strategy. But even in highly regimented deployments, you'll still see this sprawl. I see it all the time. I work with a lot of customers that are dealing with this. It is the inevitable outcome of BI two point zero. Let me ask you guys a question. We've got a chat. I want you to throw your guesses in here. I'll give you a little bit of time. Can you guess the average enterprise dashboard footprint? So for the average enterprise, let's say five thousand employees or above. What do you think the average number of dashboards they have when they reach maturity? Let's see what your guesses are. And I'll tell you that the range I'm about to show you, I have seen companies 10x the numbers. That's a very specific guess. So first person put one zero seven. It's very specific. Jack. Oh, hello, Jack. Old friend. Two thousand. We got one thousand, twenty thousand, five hundred to one thousand. Lots and lots of numbers. There's one person that's probably closer than the others. That number is five thousand to ten thousand dashboards on average. Total analytics dashboards, worksheets, reports, you name it. I've seen companies with over a hundred thousand dashboards. That is insane. Those are all assets that have to be supported, managed, updated. They take up server space. They take up time. And when you have ten thousand dashboards, you effectively have zero. Because imagine a user trying to find the dashboard with the right answer and the right business logic that they need out of that sprawl. So you get to this for anyone that took the Tableau training, get to learn how to do the Pareto chart, Alfredo Pareto. This is the rule. Twenty percent, these are numbers that you can pull off of industry studies and things like that. Twenty percent of dashboards drive eighty percent of the usage. And I bet you that in most cases, it's more like ninety ten. So there's just this ton of other stuff there. Why? How did these other dashboards end up there? Well, the zombie dashboard effect is probably front of mind. I had a one off analysis I had to do where I was doing it for a friend. It ended up in the sandbox. And gosh, golly, I never went back and deleted it. Who deletes dashboards? You never know. There may be a second question. I don't want to start from scratch. So there it sits like the walking dead waiting for another victim. Ad hoc sandbox dashboards. I guess the zombie dashboards, let's put another context on that. These could be also dashboards where somebody created them and left. So there they are just orphaned. They could also be slightly different numbers because the legacy data systems are different questions. Just these dashboards that are there that don't really have a purpose. And of course, we already talked about the maintenance overhead when you're talking about hundreds or thousands of things. And so if something upstream changes and a lot of these dashboards have built their own business logic, a field name changes, it breaks everything downstream. So there's a significant amount of overhead. So when you've got thousands of dashboards, who's in charge of it? Who builds it? Who manages it? Well, the answer are data analysts. And data analysts in the BI two point zero world because dashboards are the common language, the lingua franca, the unit of measure, the common currency. Data analysts are the load bearing structure to make all of this work. Yes, you'll have automated dashboards that pop in your inbox every morning. But as the data analyst through a combination of some centralized data sources, but a lot of work in the workbook and maybe some extra stuff in the worksheet is actually stitching it all together to get you a product. Well, if you've got ten thousand dashboards, how many data analysts on average does an organization have? Well, it depends. A little bit on the operating model. So if you're highly centralized, meaning you've got IT or a hub that's doing all the analytics, which is quite unusual. That's the minority more nowadays. I mean, you see that more with Microsoft than you would say with Salesforce. Then you have on average around a hundred to two hundred. They build the reports. There's long queues, but at least you can centralize, but there's still quite a few. Because again, there's a lot of dashboards that have to be built. If you go the other direction where you've got more of a self-service model and a federated approach, then you end up with a lot more. And quite frankly, I've been in organizations that have a lot more than this. And sometimes to their detriment, they're spread across even more tools. They've got Power BI. They've got Looker. They've got Google Sheets, they've got Tableau, they've got a finance tool inside a TM1 or SAS or SASSA. Everybody has their own reports that come native with these SAS applications and everyone's using them. So these numbers of data analysts can get quite high. And again, they're there to support your ten thousand dashboards. So sprawl compounds the more you have it. Inevitably, they're going to be duplicate metrics everywhere. Duplicate in name only sometimes. A lot of times they might be slightly different. And the effort that it takes to build these things again and again, and this is the whole, how many lines of custom SQL does your workbook have? Mine has four hundred. Oh, yours is six fifty, you win. That happens all the time. Even in very mature data organizations, analysts are making these things work in the last mile. Conflicting definitions. What does revenue mean? What does sales mean? What does customer mean? What does act an event, action, ticket? All of these things might mean things that are slightly different. If the analyst controls the definition, the definitions are going to fork. They're going to diverge and there is not going to be the benefit of shared definitions, which means siloed reports. Dashboards frozen in time. Still sitting out there probably collecting the random view. Someone's like, what was this answer for profit? They go look at this dashboard that was made for a point in time and they make a decision off of it. Again, no way to tell if this dashboard is irrelevant, stale, super useful, impossible. So what does this mean in practical application? So let's say we've got three similar dashboards, all sort of tackling similar metrics. But dashboard number one, its key metric is a four point seven. Dashboard number two, the same quote unquote same metric comes out to five point three. Maybe it's sales, maybe it's the number of customers, maybe it's products sold, tickets, whatever, safety incidents, whatever it is that you're interested in analyzing. And dashboard number three is four point nine. Three similar dashboards, three different answers, all of the logic abstracted behind pretty charts and graphs. So you can probably see that there's actually a greater problem here than a lot of analysts building a lot of dashboards and IT and technical people having to maintain. It's trust. The real cost here is the business does not know what's the right answer, thus they can't make the best decision. And when people look at these and they see different ones, they don't say, well, which one is right? Which is the assumption one of them is right. Because they're different, the natural assumption is they're all wrong. I'm flying blind. And they don't make a decision based off of any of these numbers. So far more than the cost of licensing hundreds of creators or power users, and then the next year of explorers and visitor or viewers or whatever, whatever the model is for that particular BI tool. It means that data which was meant to be this lifeline to great decision making is now quite the opposite. It's confusion. It's distracting. And we're right back to making intuition based decisions. That's the cost of two point zero. So the solution is obviously making all of this more efficient, making all of this easier, getting back to the original goal of making data insights, the generating of answers, easy, simple, efficient, which gives us BI three point zero. This is the goal. Now of course as we get into this there'll be complications and things that don't quite work perfectly but we'll adapt we'll adjust and there'll be a BI two point five or BI three point five as the next big iteration to make all of this easier. But this is going to be a major step in terms of shifting the paradigm. From pre BI, BI one point zero, BI two point zero, the answer has been reports. It's just the reports have looked different. They used to be monochrome reports in a spreadsheet, then they became full color reports. Now they're beautiful visualizations with all kinds of pie charts and spider graphs and all kinds of stuff. Wave three is completely different. And we get to this idea of conversational AI or AI being the power user at my beck and call versus me having to go over to Doug's desk and say, hey. You really know how to use this tool. Can you help me? So let's talk about talk to data, pun intended, also known as conversational AI. Ask your questions in plain English So long as you have a curated semantic layer where everything is nicely consolidated with context, context would be your unstructured data, augmenting that that data, then you can get instant answers and you can ask multiple questions. So you're using natural language. I don't need to learn SQL. I don't need to learn Python. My answers are instant. I don't go to a queue where some power user or technical expert in my reporting tool builds me my answer. It is genuine self-service for everyone, not just for the analysts and engineers, and then they help the people that can't help themselves. If the data is great, faster and sharper decisions because the user will be able to ask multiple iterations of the question to explore and shape their answer. And even better than this, it can be embedded into your natural way of working, whether that's in Teams or Slack or whatever tool your organization use. You can use any sort of like a separate channel or a slash hashtag, whatever that sort of cues, hey, AI that's listening, waiting to be helpful, I have a question that's coming. And then in some places, it's already there. So what does this look like? Let's say I've got a little AI chat here. Maybe this chat is built straight into a chart that I look at, and then I can ask my question. My question might be, okay. What were q three sales by region? And maybe I'm looking at by country. Well, then it would here's your answer. And it'll prompt me as you've probably seen with Gemini or ChatGPT or Claude or Perplexity, hey, would you like to look at Q2? That's the future. There's a lot of work that needs to happen behind the scenes which why we've been talking about AI readiness for two years. That's your strategy, governance, data, and people pillars that make AI possible. But once you do those things, there is a new reality that is actually ready to start doing things today. When we're talking about this last year, it's coming. It'll be here soon, six to twelve months. Well, guess what? It's here now. And you could do these things with Snowflake, Teamwork, co work, they keep changing that name, co work, and you can do it in all sorts of other tools too. So as we're starting to frame this, what questions should be a dashboard and which ones should? Well, there's some easy ones. If we're doing a one off comparison, how does this quarter compare to that quarter, this region to that region, or why did these seventy five couches sell in Geelong? One off questions are perfectly suited for an AI chatbot. We don't need a dashboard for that. We're not going to have the same question. That answer has been given to us. Why did this change? Root cause analysis is also really good for drilling down question by question by question. And every question you ask adds to the context that the AI is helping you with and you can get down to those answers quite quickly. New and anticipated cuts of data. What what if I had eighteen months worth of data instead of twelve? What if I had fifteen? What if I only had this region? This is where these dashboards start to really iterate because now sales wants a cut for this and this sales manager wants a cut over here and, oh, operations wants their cut over here. You don't need to do this. You just let AI in the prompt. Everyone just like we learned how to use Google to search for stuff to what is it? Twenty years ago? They'll start to learn how to do the prompt engineering to ask the first question the right way and get the best result, which is also the most efficient way in terms of costs. Lastly, just one more. Can we add a filter here for business unit? Oh, I'd like to add a parameter. And you end up inevitably, anyone that's been this business from within a year has seen these dashboards with twenty five filters and thirteen parameters and a whole bunch of little click actions in the middle of everything. The one dashboard to rule all dashboards, every answer you could possibly want we built in here, which means it's a dashboard for nothing. That extra filter, let's let that be a chatbot next to a fairly generic chart. And that way we don't have to build every conceivable filter. The AI, the talk to data function next to that chart can take those exceptions. So when you're thinking about what we've got, if you wanted to use some numbers, some metrics, to figure out which charts are the ones that we should keep, which dashboards, reports, whatever are the critical twenty percent or even hopefully ten percent, five percent, two percent. Well, there's some ideas that I've got for you. Interworks can help you with this. We've done this exercise quite a lot lately as people are moving off of this two point zero paradigm with thousands of dashboards into something far more consolidated and sleek and more efficient. Dashboard to active users. Start looking at the ratio of sprawl towards people actually looking at stuff. If it's ten to one, five to one, you've got too many dashboards. If you've got a lot of users, I've worked with companies that have seven hundred fifty thousand employees. They're gonna have a lot more dashboards than somebody that's got five thousand users. So let's understand what the ratios would actually indicate. And the other thing to think about is, do we have too many metrics? Are there forty five metrics for each business unit? Are those key performance indicators? By definition, are they key or critical or are they just flavors? Are they noise? Are they distraction? This is a we'll talk I have a slide for this, but human beings need to make these decisions in terms of actually getting down to the brass tacks of what matters. And there can't be like Oprah a KPI for everybody. You get a KPI, you get a KPI for every person in the organization. They need to be key because they're key. The average age of a dash dashboard. I've done a recent exercise looking at some Cognos stuff and these reports are twenty years old. It is long overdue to rethink how we use that data and to do it in a way that is far more efficient and effective. We don't, when we move, whether it's from BI one point zero to two point zero and hopefully to three point zero, we don't want to just lift and shift. You're missing the point. The point is to embrace the new paradigm. Just like what we said at very start of this. The point is not everyone can build a report. Even if that were true, and it's not, almost everyone can build a report, that's not the goal. The goal is to get people answers. So we don't wanna rebuild old reports. We wanna reenvision why they were built and then answer that. Monthly views. This is very simple. I bet you if you took the top twenty, top fifty, or maybe even the top one hundred and just look at the degradation from the first report, the first ten reports down to the bottom, it would be a significant drop off. What I've seen is generally there's four or five really, really used reports. And then everything else is a couple of people using them a lot. Down in the twenties and thirties in terms of the number of the ranked reports. You can really see that pattern when you look at monthly views. Or if you want, if you've got a lot of quarterly reports or annual reports, you could do it ninety days, hundred eighty days. But you'll see really quickly. These reports are critical. These reports are have high concurrency, lots of people using, and these reports are fairly niche. Good place to start. And then start flagging those reports as ones, could we retire this? In the effort and goal of making everything streamlined and efficient for our new future. Everything else is probably sprawl. Last use is another metric. This report been opened in three months? No? Probably not useful then. Another way to think about this is the types of questions. So if you do get more questions so we've talked about questions that aren't. That shouldn't be a dashboard. Let's put some context on the types of questions that you might get and where they might land. So if you have fixed manage your reporting or you have a complex story that you're trying to tell with your data, that's probably something that's really good for a dashboard. It's not when and how and these sort of one off questions. I need to explain let's say for instance utilization for my mix of full time staff and contract staff for all my health centers. And it's a very complex story and there's a lot of nuance to it. AI is probably going to struggle to capture all your context in a prompt. And particularly if this is something that's managerial, and the example I gave certainly would be, you'd want to spend the time with human beings really working this out so that it was nicely, tightly designed and told a very specific story to give people the insight to do what they need to do. Any sort of operational reports or combination of executive pack, those things are all really good managerial reports. So I'm not saying dashboards need to go away. There's famous campaign that says dashboards are dead. They're not dead. They're just overused considerably. But there's still a place for reports and dashboards. But let's be specific. On the other hand, it's these one off questions. In the moment, never quite the same. Maybe it's the selection of data. Maybe the question slightly varies. Maybe filters parameters and things like that. Just the way we wanna cut our answer should be talk to data instead. Instead of a ticket that we have to send over to the IT people's dashboard designers. This opportunity also better facilitates second, third, and fourth questions. If you've ever built a dashboard for somebody, inevitably you will show them and they'll start to say, well, I don't understand how this works. You have to explain it. You have to teach them how to use their own dashboard. They use it for a month and then they come back and say, okay, you didn't quite get what I wanted. I think this metric's wrong or I was actually trying to get this answer, and so you gave me close to it, but can we fix it? And even in the best scenarios, like this report is great. I have more questions. I wanna expand this report, which just, again, goes right back into the queue and creates more dashboarding work. AI is perfect for these types of things. Let them work it out with a dedicated power user in the form of an agent. So if we look at how many we have and how many we're targeting, I said five to ten thousand. Five thousand to ten thousand is about what we have. So we'll go on the we'll on the side of smaller, five thousand. This is the typical number of dashboards you have in the sprawl of analytics catalog. Again, most of these are one off, one meeting, one request, one moment, retired, never removed, owner left, abandoned, old data, stale data, but there they are existing. On the other side, when we actually go through and do the audit of who's using it, why are they using it, what answer are they trying to solve, And narrow it down to a tight group of dashboards that are operational, managerial, very complex stories that we're trying to tell, the goal should be about fifty. If you have a humongous organization, a hundred thousand employees, seven hundred thousand employees, that number's gonna change. But for most of you, in that thousand to five thousand or less, that number fifty is probably bang on accurate. And if you're smaller, twenty five. The recurring decisions the business makes, highly curated reports that have high concurrency. But I really want to emphasize, this takes time. And I'm in a project where I'm doing exactly this right now, helping folks narrow five thousand dashboards and reports into the smallest number possible so they can prepare for the future of this new paradigm. The challenge is actually not doing this. This is administrative. This is tedious. The hard stuff, the really impactful stuff is actually getting together to agree on what these metrics should be and what they mean. And I had AI generate a little funny photo for us. This little punch up is actually where human beings decide what the business is going to agree on. What does a sale mean? What does a customer mean? What does a patient mean? What does a patient outcome? How do we measure success? All of these business rules are super, super important and human beings need to do it. When you think about how AI is accelerating data and analytics, AI can generate a dashboard for you. AI can generate answers for you, as we've talked about through this entire selection. When we hop over and think about AI on the data side, if we break it down into medallion based architecture, I had this conversation literally today with a client. AI is really good at BronzeLayer stuff. It can do the API stuff. That's very precedence based repeatable patterns that AI is good at. AI is getting better at silver. So we're talking quality, integration, relationships. Human beings do need to help, but it can be trained. AI is weakest at gold, weakest at platinum, weakest at semantic layer because, again, these are what the business needs to decide are important. AI can't tell you what revenue is. You need to tell AI. And then now that it has it, it can do stuff with it. So this is honestly the hardest part. Human beings getting together and sales and finance agreeing on definitions for financial metrics. One's for sales targets and variable compensation and bonuses and things like that. The other one is for how we report our business to the street, to our CEO. Different, but kind of the same. Don't underestimate this part. Okay. So three things must be true before conversational AI, BI three point o, is safe and scalable. These are super important. You have to have a semantic layer, a real semantic layer. I'm gonna talk about what I mean in a second. Just because your dashboards work does not mean you have a semantic layer. Governance that travels. So when you ask a an agent a question, the governance has to be through the entire throughput of what that AI answer can be. In your semantic layer into your unstructured data, so we're thinking information management, we're thinking RBAC in terms of am I allowed to ask these types of questions based off of my user role? Governance needs to provide the safety framework and it has to be pervasive. Data quality and lineage. I think this is a great way. There's all that saying, I don't know. I can't know what I don't know. And same thing is true for agents, but we have to tell them as closely as possible. We don't have this answer because if you ask an agent a question, it will do its best to get you an answer. It won't say, that's a judgment call. That's that's your it's really for you to answer. Or I don't know. There's not good data. It will give you an answer whether it's true or not. It's designed to give you the best closest answer to your question, and it can be garbage. And neither you nor AI know it is. So data quality, the curation of it, visible lineage back to source systems, very important. This is how you're gonna get the best answer the most often. So let's go into this idea of a real semantic layer. I have a whole webinar where we talked about AI, or rather, let's say this. Have a whole webinar talking about the preeminence, the importance of the semantic layer. And if the data analysts were the load bearing structure for BI two point zero, the semantic layer is the load bearing structure for BI three point zero, because we don't just have human beings consuming our data. We have agents, have AI consuming our data. And human beings can patch and fix because they kind of have an idea of what good looks like. AI consumes. So AI, or rather semantic layer, supports BI, AI, ML, apps, products, data shares, data exports. And inside of that BI, there is reporting analytics, advanced analytics, augmented, all of that stuff. The semantic layer in the new paradigm is critical. So let's assess your semantic health. Are you ready for AI? I heard someone say, well, yeah, we are. We we we did all this effort and energy and all our reports have right information and they're automated. Okay, great. Let's see where that data comes from. Everywhere on the diagram that I'm going to show you, green means semantic. You've got business logic in that container. So we've got Snowflake, yay. We've got a lot of great semantic layer in there. Got a lot of business logic rules and definitions, relationships, all that stuff. In Snowflake, high five. Yay for us. Okay. Your analytics. What do you have in there? Oh. Oh, yeah. Have TWXs that we published as extracts. And then we've actually custom logic built into some of these workbooks. And actually, we've done some definitions in the worksheet. Okay. So your business logic is spread into your analytics tool too in varying levels and varying complications. Okay, where else? Oh, we have SharePoint. And SharePoint is the land of ten thousand Excel sheets. And all of our finance data is in an Excel spreadsheet. There's a couple of people that pass it around and they prepare all of our monthly reports. So actually we've got business logic in Excel spreadsheets too. Okay, starting to get into dangerous territory. Oh yeah, that's right. We have that SQL Server that IT runs and they run that for, I don't know, our inventory team. It's this legacy thing. It's got very old proprietary software on it, but it's just too complicated to recode it and rebuild it. So we've got a bunch of actual stuff on there too. And oh my gosh, there's all this stuff that's on network drives around people's desk tops. And I whenever I build my report, I use my own personal Excel sheet that I maintain, and I blend it in for my report. Oh, okay. And we use SAP, and there's a bunch of business logic on there. We haven't quite gotten some of those tables to replicate into Snowflake. And finance uses all these old Cognos reports, and those Cognos reports are built off of Cognos packages or cubes. So it's actually there's quite a bit in there. And we just got Salesforce. The Salesforce is a little bit of a system with Data three sixty. And, my gosh, we've got a whole bunch of business logic in there. You can start to see how disparate, how scattered your actual semantic layer is. And your AI is looking at this like, bro, what am I supposed to do with this? How can I get you good answers if everything is everywhere all at once? This is why it's super important to have a think about how you're building your data today. Consolidate data into a semantic layer. And you can go look at the AI COE website webinar that I did, I think, July first. We talk a lot more about this in terms of building semantic layer partner with context, which gets you a great AI consumption layer. That doesn't mean you have to do all of this at once, but you should be doing this by domains. So if you wanna build a chatbot for sales, you've got to do your best to consolidate sales logic into a single place of consumption. The good news is is that once you get your your your head around the semantic layer and you could start downsizing by orders of magnitudes all those dashboards, what do you want to do with all these data analysts? This is where our data analyst community starts to get a little nervous. But I don't want you to be. Because the answer isn't fire all your data analysts. You still need them. You still need people to build and maintain dashboards, not as many, hopefully. But all the people that understand your data and can do analysis on it are really valuable. They understand the context of your domain specific knowledge. Most of these data analysts are embedded in business units. Most of these analysts really understand your data. So there is some proportion you should convert into full data engineers because if the semantic layer is now the load bearing structure, the speed at which you can build data products must accelerate. Not just keep your head above water, but if AI is really going to build you a significant impact in helping you make decisions and automate and be efficient, you need more data. You need more curated data. So some of these analysts should be converted into engineers. And because these data analysts are embedded in your business and they've got so much useful context of what's happening there, Let's make some of them into analytics engineers. Or another way to think about this is folks with good data transformation capabilities, but not the full skill set of a data engineer. But they trade off how to build a bronze layer, silver layer, focusing on gold and platinum. They trade off that the lower level stuff and lower level in terms of where it is in the medallion layers for domain specific expertise. So your analytics engineers will understand data transformation, but there'll be experts in the way marketing thinks or the way risk or inventory or supply chain or finance think. There's specialists in data that also specialize in that business unit. The data engineers are largely going to be centralized, but the folks in the business units and the spokes, those can be your analytics engineers. And then you have the semantic layer being built up from both directions. Now you have to coordinate. Your architects and your engineers need to be setting best practices and pathways to be successful. And your analytics engineers are following those paths to then build domain specific business logic at an accelerated rate that a centralized team would never be able to keep up with. This is the idea of data mesh. And with AI, if we do this correctly and we empower the business units, I think it can be quite powerful. So what does this mean for our end user? Well, before I have a I have a problem, I have a question, I need a data insight, I go and fill out a ticket to my BI team, my IT team, whatever. Let's say they're looking for a particular thing like a dashboard. Well, before that hundreds or thousands of similar dashboards and whatever means in which you organize them, Interworks built a product called Curator as a portal to sit across all your BI tools to help facilitate that. Because again, it was a problem that was unsolved. So we like we've tried to do, we build a product to solve it. But now that we're looking at BI three point o, the number of dashboards is gonna be so tight and narrow that they'll be very easy to index. They'll be very easy to categorize and put metadata on so that the right dashboard can be discoverable. And and, again, right next to those dashboards should be that AI chatbot so they can ask follow-up questions. The ad hoc questions, follow a ticket, get a request, go to the analytics backlog, and wait for somebody to get to you. Again, you can see where this is going. I could ask my hot questions directly to my agent. And it could be the agent build to the dashboard or it could be my little personal agent like a ChatGPT or OpenAI or whatever. What is happening? Hopefully it's right there in Slack or Teams or wherever it is that I'm doing all of my normal business work. The analyst times, again, they don't have to maintain these massive set of dashboards. They don't have maintain or build rebuild the same business logic in the dashboards, in the workbooks to get to the basis where they could start answering questions again. But the analysts can do, the ones that are still analysts. They haven't been made into a data engineer. Perhaps they've got analytics engineering capability. But the seventy percent of time the data analysts use trying to wrangle data, which means creating it themselves, trying to find a good data source, and just patching it together with duct tape and hope. The rest of that time, that efficiency they get back can be spent thinking of better innovation in terms of how data is used, ideas within the business domain in which they're embedded, as well as better partnering with their constituency, their stakeholders, the downstream users of the stuff they're building. That's the stuff that's going to drive real innovation. That's the stuff AI can't do. Let's go look at four critical next steps. So run an honest honest audit of your dashboards. Usage, ownership, opportunities for consolidation, business critical, is regulatory, whatever. Does the CEO use this? And just get a sense of criticality, frequency, volume, ownership, all of those things. Those that have standing decisions that are used daily, weekly, monthly, or whatever, mark those as managerial and then think about how to reengineer them so that they're using new tools, new functionality, and embrace the new paradigm. Everything else you should probably retire, consolidate, or reformat into a a a format that's gonna be more useful. Be ruthless. The semantic layer and governance. You cannot do AI while you build these things. There leads to at least even if you do it domain by domain or use case by use case, your semantic layer and governance need to proceed your analytics products. It doesn't have to be all of them all at once and then only then do you get to your analytics but you've got to have a plan on your data, your semantic layer, your governance and then the value you're going to get out of it. If you patch together the data like you did your dashboards, it's going to be much harder to do what you're trying to do and it's going require far more overhead and management. Pilot agentic access. So again, like I said before, do this by use case or do this by domain. The sales folks, the marketing folks, the finance folks, somebody is gonna be pretty data progressive, and they're gonna be eating up a lot of time of data analysts asking questions. Questions that are fairly simple in nature, but very important and urgent. Build those folks the, the BI three point o pilot. Monitor, assess, and then expand. The good news is is Interworks can help you do all of this. We do this stuff all the time. Let me give you a a couple more pieces of advice. There's a couple ways that this can go a bit pear shaped. These are very common mistakes that people make, not just with AI or BI three point zero, but really with data and analytics generally, in particular governance. Treating the solution as buying software. We have a governance problem. We bought Calibra. Now we don't have governance problem. Calibra is a fine tool, but again, user adoption, use cases, that's how you determine value. And all of that is human beings making a plan and then the tool helping you automate the plan. Super, super important. Think of the outcomes, not the platform. Doing AI before you have governance, before you do your training, before you do your architecture modeling and pipelines. You it's exciting, and we wanna get into it. We wanna start kicking goals, but you've gotta do the foundational stuff. We have a assessment. We call it DART, data analytics review and tactics. And the whole premise of it is to score you off of five technical domains to give you a sense of how ready you are to operationalize enterprise level AI solutions. You have to be good at those other things before you can be good at AI. Consolidating without fixing definitions. If you just take everything and dump it into a pot and mix it, you're going to end up with catastrophe because you've got to spend the time. Like that slide of those two people fighting it out, team pie chart versus bar chart. You've gotta spend the human being capital, the effort to actually make decisions on how we think about these metrics, how we standardize our business rules. Again, it's very exciting, but do the prework. It's like the whole thing with a carpenter. Measure twice, cut once. The prework is super important. Good news is we can help. Interworks, is a a multi multifaceted long running business with lots and lots of customers. We think about this from a strategic standpoint. We do tactical implementations, foundational use case specific advanced, and then we can help support you and help drive success, whether it's by your entire community, uplifting them and giving them ideas and empowerment, individuals teaching them specific skills and managing a database, building data pipelines, working with BI three point o tools like Sigma, supporting your application so that you guys can focus on business value and not keeping the lights on or pressing buttons every day. We can do all these things for you. Any or part or all. Happy to help. If you have questions, you can certainly put them into the chat. We've got about five minutes, but I'd really encourage you to scan this little QR code and reach out to us. This will take you right to our contact us form. We've got a whole bunch of people specifically designed to answer the phone and help however we can, based off whatever data need you've got. So if you have questions, please throw them into the chat. Otherwise, scan the QR code. And if you don't do either, I still thank you for coming. And, again, keeping in mind all the cool stuff that we have coming up, in line with the snowflake world tour in Sydney, we've got a whole bunch of cool stuff that we're gonna do. If you stop by the booth, we have got really, really fun little giveaways. So we hopefully will get to see you there. So I got a question here. What do you think the fallout from BI three point zero will be? I think there's probably a couple things. I think it's so I already mentioned some ways that these can go pear shaped and that your data is not ready or you haven't put the thought into what and why you're doing it. The other fallout that I see is a lack of governance on cost controls. And you see a lot of stories in the last couple of weeks of all sorts of companies burning tons of AI dollars. And I think I saw, an analogy or a video where it's like, you've got a tricycle problem and you're using a Ferrari to solve it. So again, let's be mindful and purposeful, which is why I say start with a pilot. Start small. You can make sure you get the good results, but you can govern it. Govern it in terms of the answers that people are getting as well as a sense of cost. Obviously, there's a huge component of how good your data is, how much effort and energy you put into polishing that semantic layer that will determine the success. So if you don't do that, you'll end up with hallucinations and all kinds of silly stuff. The last thing I'll say on that one and we've got another question. The last one I'll say on that one is every successful project involves, people, processes, and platform. And when it comes to data and analytics, most companies don't think about people. So if we're going to get the right results from using a Talk to Data type functionality, we've to teach people how to use prompt engineering and all this other stuff. There is a science. How to build context in a question? All of these things are important. Thanks for your question. Sam, how do you convince an organization to move to BI three point zero if they feel that two point zero is good enough? I I have fair amount of experience in doing this, and I think there's two I've mentioned this in previous webinars, but I'll I'll repeat it here. There's two ways to sell, whether it's selling a solution or selling an idea or whatever. It's this idea of value. If we do this thing, it will create value for us. It'll be useful. It'll benefit. And people get excited about that, but they often don't spend money on that. So I can say, hey, if we build this BI three point zero thing, it'll be better than two point zero and here's why. The other way to really incentivize people to buy into an idea is selling risk. If we don't do this, bad things will happen. They don't need to be unrealistic. You don't need to make stuff up, but BI two point o has severe limitations. There are certain types of questions it is not tailored to suit. There are certain solutions that BI two point o aren't good at, or it would take a lot of time and energy to do it. And the easiest thing to do when you're selling three point o versus two point o is to talk about the AI paradigm. If you go back to my very last webinar, which is AI building an AI COE, I've got all these beautiful quotes from just titans of the industry, the CEO of Microsoft, etcetera, etcetera, etcetera. And they're saying stuff in there like AI is as impactful to the human race as the invention of the steam engine. And if you don't do AI, you are immediately becoming out of date, out of touch, and your marketing advantage your your your market share, your market differentiation diminishes almost immediately. You don't wanna have to be catching up because that's how significant AI is. And we're talking about AI in terms of accelerating data insights, but it's everywhere. And so BI two point o is the land of dashboards. The goal of BI three point o is to be the land of answers, to be the land of insights. Elaine, you asked a question. My colleague Carol has graciously answered that. I'll answer it for everybody. All of the replays are on the interworks dot com website. If you registered for this event, we'll send you an email letting you know when it's up. Very happy for you to share that with your friends and colleagues. How do we manage the issue of got two minutes here. How do you manage the issue of model learning degradation over time after implementing BI three point zero? Adding more data on a daily basis. That is a fairly technical question. So I'm going to give you a I'm not gonna give you a technical answer because we've got a minute now. But I would Tamela Rasan, hopefully I said your name right. I would recommend you scan this QR code and we can get people that will give you longer and bigger answers. There this would be part of your data DevOps cycle. So as you introduce more data, and as you introduce all the rules around in terms of quality and things like that, I think training these models and making sure that everything is fresh and up to date is part of the process for bringing data in. Our friend Jack offered an opinion. I don't disagree. I think scheduled reviews, evaluations, and things like that. But that's a part of building data products that we just now have to factor in to everything that we do that we were normally doing for BI two point zero. Great questions. Thank you so much for joining. Hopefully, you found this useful. Reach out to us. We'd love to talk to you. Otherwise, keep an eye out for our future webinars. We've got lots and lots of cool stuff, that we're preparing for you. I hope you have a lovely day, and good luck with your AI and data. Thanks, everybody. Bye.