Welcome to today's session, Intro to AI Apps in Sigma. I see my clicks are a bit delayed. There we go. Today, we'll talk about what an AI app actually is, what it takes to build one that holds up once real users get their hands on it. So that's really the core goal here for us today, and we'll do this at a fairly high level, to give you a strong intro. My name is Robin. I'm a senior analytics consultant based in Amsterdam, The Netherlands. And I have with me not just the lovely Vicky that you just heard, but also James Austin, our MAS Services Director who has supported many companies through their JDAG journey and transformations. He'll be hanging out in the chat in the background of this session, and I'm sure he'll chime in with some interesting insights as well throughout. For those of you who may be unfamiliar with Interworks, welcome. We're a global data consulting firm working with companies around the world on their toughest data challenges. We specialize in data analytics, data engineering, and AI, and we partner with what we like to think of best in breed platforms. So Sigma, but also Snowflake and Databricks and many others to make sure we can build the right solution for you. This webinar, as you may have seen on the first slide, is the first of four Sigma webinars this month. So three more sessions are coming up soon. We'll have the QRs for registration at the end again as well. And together, I think they give a really good starter for Sigma and how to think about it. Okay, so feel free to go into the chat and Q and A and everything throughout. We'd love to hear from you. And today has two live demos for you. Fingers crossed, they all go well, but that also means I'm very excited to dive right in. Where do we start? Let's start with where we are today. In the different waves of BI, we ended up through dashboards at self-service BI to unburden the data team. People can explore insights themselves. It put dashboard building in the hands of a lot of different people. And to me, that's a good thing. Dashboards are great for KPI monitoring, for historical trends, for exploring the data and understanding what happened. That's not going away and I'm definitely not here to talk you out of dashboards, but there is a catch. As more people build more of these dashboards, the actual workflows and decisions of these dashboards often still live somewhere else. This may be a meeting where we look at the dashboard and decide that can still happen. It may be a select thread somewhere or multiple people have multiple workbooks. It could be someone's manual spreadsheet that is rebuild regularly because that's what they trust, but only one of the team can access it. Or it may be a one off solution built for this specific problem that someone was trying to solve. So the dashboard tells you what happened. It doesn't capture what you decided to do about it. And although it's a good single source of truth, if multiple people are building, it could be spread out. Let's look at an example. Revenue forecasting is one that happens in about every company. So it's an easy example for us to take. The dashboard will show what is currently in the pipeline, the totals for each stage. Maybe it uses the historical close rates of the opportunities that you have for the things that you have going on. What usually happens next from this dashboard that shows the current state is someone takes it away and starts modeling in Excel or something they build by hand. What if this big client lands? What if this piece of funding gets taken away? What if this other thing happens? So business users often want to assign some sort of probabilities to different opportunities, things they are sure will happen. Maybe even things that weren't quite updated yet in the data. They adjust the factors behind the numbers, try to compare the scenarios. We are forecasting what will the next months look like. A dashboard just can't do that. It can show you one version of the truth, generally the past, but to build in multiple versions, you're going deep into some level of data engineering and it's not as easy to adjust. An app can do this. So we are talking today about AI apps or just apps in general powered with a little bit of AI. An app can do things like this. So one place for the scenario, the assumptions you're making, the comparison using your actual data, but also with others input. So let me stop just chatting about it and let me show you what this could look like in Sigma. Let me make sure I get to the right demo for us. There we go. So we have here our pipeline forecasting app. And what you can see is on our overview, we have a few filters for geography and for product. We are looking at live version. That's already our hint. There will be multiple versions. We're seeing four different products of this company comparing to the target and our forecast currently is going to 100%. We're seeing, we're looking at the months, November, December, January. So from our October, we are looking forward three months and we are comparing our forecast against targets by region, by product in the months that we're looking ahead. This has some, this is a classic dashboard for now. It has some interactivity like a dashboard. For example, if I click on East, the whole dashboard filters to the East region for me. Typical dashboard expectations here. I have a tab here that says create versions. And in this tab, we see an overview again of filters, but also our KPIs and then a list of opportunities, a very long list of opportunities we can adjust. So this table down here is an input table. And I can say, actually this Horizon system deal, this one actually fell through. So I can manually exclude this and it will adjust my forecast. Now I can say I am also very sure that this OmniWorks one is going to come in. And I'm also super sure of this next one as well. And so I can walk through a list of opportunities and include and exclude things that weren't quite caught by the normal probabilities. Very flexibly. This is written back to our database. If we want to, we can save this up. Or we can also adjust in batch. We can say, okay, we are looking at a summary. We haven't made any adjustment yet. This is our forecast, but we know that in the month of January, in the North, we are going to be taking a hit of a million. That's a 100,000. That's a million for us in software. We know something's gonna go back there. We have been warned. Maybe there's new regulatory measures that will cost us money. I can add this bulk adjustment. And you see the adjustment that I've made here. And I can create a new version out of this to put into our comparison. Says choose a name first and I know that if I say a live version that this version already exists. Oh, must have been typing it slightly differently, but it says name available. If it wasn't available, it would also warn me for that. But I will say North rules as a version name. And then at this version, we added a little animation here as that's loading. And you see in the background, it's updating our dashboard to the new select version north rules, and you see, we no longer make it to 100% of target. That north bar has really gone down. And if I select on north, then actually we are now doing a lot worse than we were expecting to before. So I can play with the different variables behind my forecasting. Now, if this forecast is something that I want to get approved, I want to submit to others. Well, we also have a tab for that. We have a compare and submit tab up here where I can compare the versions to each other. So the new north rules version, the target version, and maybe I want to compare this to the CRM baseline. And I can see what these different versions turn out to. I can see an overview of the different versions I created and I can see that my version hasn't been submitted yet. I can say this version needs to be submitted. I tick the box and I can click save. So in the background of this, we can attach all sorts of actions to this that sent this information somewhere that write it back to a database or don't write it back if you don't want it to, but we can play with it in the dashboard and under submitted detail, I should be able to see that now also my North rules forecast has been submitted. I can even allow people to download this version then as well. So this takes care of a whole workflow of forecasting, playing with variables, comparing, submitting for review, all in one place with the dashboard there for information, but also the actions that follow on it. So when are we building a dashboard? When are we building an app? And this one is a great one to hang up our little framework on, because this dashboard app actually meets our four requirements for an app. This is a little test we use at Interworks for questions. And that is going to tell you, are you building a dashboard or should you be building an app? The four are input logic views and roles. And let's go a little bit through each of these. First input. We're looking at a process where users enter data across specific fields. They're not just filtering or viewing what's already there. They are inputting data. This is our input table where we add include and exclude, where we select which ones should be submitted. Second, the logic. Rules and calculations run on this input, transform it into an output. If you adjust something, the app recalculates it in front of you and you can compare. This doesn't go through a loop of multiple people or files sent around or something that's rebuilt every quarter. There has to be an underlying logic that is decided on when you built. Views and roles are the third and fourth. Views. So the output is presented differently depending on who's looking. You could also think about this as depending on the part of the process. So multiple steps of the process are involved here. Multiple people are involved here and we can lock this down for different people. So some people can only adjust the forecast. Some people can submit, other people cannot. And that goes very hand in hand with roles. Different users holding different permissions and they may see different functionality. So as an example there, the rep can adjust assumptions on their own deals. The leader that can approve the number that goes to the board in the same app, one source of truth, different access. That one source of truth is important. Everything stems from the same data coming right out of your cloud data warehouse. And here's why that matters. The forecast app you just watched isn't measured by how many times someone viewed it. It's measured by, did we make the decision? Did we get the number we are standing by? Did we understand each other's predictions and that we discuss which one we're going with? So we're tracking active users rather than usage, the feature adoption rather than how fast it loaded, and especially when something has a lot of handovers from one piece to the next. Did it function? Did it help us along? So did this genuinely help us get the job done? This isn't just useful for revenue forecasting. So I'd like to show you a completely different second example before we go into a little philosophy of how to build these. So the second example I want to show you is of a hiring pipeline. So your hiring dashboard shows you how many candidates are in each stage, how long have they been there, But it doesn't quite show you which ones deserve a closer look today. That might happen in email threads or interviewer notes that are in different places or a recruiter that builds the instinct across all different pieces of information. So instead, can we move that all into one place? So the idea is one place for candidate details, interviewer notes, and we'll add an AI assistant that summarizes it and clarifies which candidate needs your attention. So I want you to watch for how text heavy this workflow is. And also that even though we will be using a little bit of AI in here, and that's the wrong word, we are still very much having a human making the decision, a human in the loop. There we go. Now, I have a custom view. Let me make sure to close that. We are looking at our hiring app. We see our total active candidates and please be assured that this is demo data. We have candidates awaiting interviews, the average days of pipeline. We even have a sneaky little bar chart of the different stages that we also see below. And then we have each of the candidates And under each stage, the candidate has a little view candidate window. I can filter this down to a specific job posting, but our board is pretty calm now. And let's take a look at how someone moves through this pipeline. Let's take Olivia today. So if I open up Olivia, I can see her contact details, her current role, where she is, and also I can attach a PDF here with the resume. Now this is a sample resume, so it won't be for her, but sample resume can be attached here. I can get it downloaded. All the information is right here. And if I'm someone who evaluates this first resume stage, I can look over this resume and say, actually this is a good fit. I will approve this candidate. I get a little pop up that HR has been notified and you see Olivia has moved into our second stage, into our HR interview stage. Now, if I do the same thing here, I again get the base information of Olivia. I also get the prompt to fill in a scorecard. And here I can talk through Olivia's HR interview. So if I've taken the HR interview with her, I can come in here and say these are good answers. And I'll just give this a little bit of data. Why are you interested? Heard about us through our our interworks blog, world famous. And she was looking for 90 ks. I liked her. She's definitely someone that I want to hire. And I can go ahead and submit this information. This fills data in a table. This is linked to an input table in the background and feeds that into kind of our overall information. I said, definitely we will approve Olivia. She moves through to the technical interview. And again, people are notified that she's moving through. If I took the technical interview with her, again, there's a scorecard. Greatly technical. Workbook was outstanding. Presentation skills were okay. They can do zero jumping jacks while singing. But sure, we'll move her along. And I can go ahead and move through the pipeline. Hiring manager interview. And here's where it gets interesting. So for our hiring manager interview, we have a little AI assistant that says, which candidate would you like me to summarize? And I can say, summarize Olivia and make a recommendation. And what this will do is it will take the scorecards and the pipeline history so far. So this AI assistant has access specifically to the previous scorecards. So you'll see exactly what data it has been pulling and that is data we've given it access to. We have also given this assistant some instructions. And let me actually make this a bigger screen for us. It says only two scorecards exist. They've been mapped. So we can see who did which review currently sitting at the hiring manager interview. No scorecard. Both scorecards are positive, consistently praised on deliverable quality. Hey, it is only one interviewer. Be aware. And it says, advance Olimia with cautious confidence. However, that's still my decision to make. We didn't get AI to make this decision. It's still my decision to make, but I get a good summary of everything that's happened so far all in one place. So if I... And I'm being blinded by the sun a tiny bit here. I probably should have added a scorecard here, but from this point I can either approve or reject and say that we approve, she will move into either hired. There we go. Or if we reject, they would end up down here. This functions almost like a full hiring platform. Like a full software that you would buy somewhere. And I say almost, is a dashboard, a demo, and of course I have the powers to see everything. But it shows you some of the incredible possibilities here. I'll take us back to the slide deck just to show you some similarities and how some of these things were built because these things were built from the same features. These both demos that I've showed you were built from the same features. Input tables, layout elements, and actions. I'll take you through each of these with a bit of a screenshot there. So you know what I'm speaking of. The input tables could be forms. It could also be the table in the beginning where we included or excluded. And we've seen this as scenario parameters or status tracking input tables are governed right back. Users can add or update data along your warehouse data under the same permissions as the rest of Sigma. And you decide what that looks like in the front end. Is that a survey? Is that a table to update? A very important decision that we'll come back to in a bit is whether the data appends to your table or whether it can overwrite what is there. Typically we append so we can track who adjusts what over time, which is what you see over here. That matters. We'll come back to it, but that's our element one input tables. Some other things you've seen are the layout elements. We can build different landing pages, tab containers, pop up models, little disclaimers that pop up, but also boxes with additional information, a side panel that showed you the details on each candidate. It allows you to build a step by step flow from one thing to the next, to the next, without having to show everything at once, which can be really overwhelming. So this is really important for a user experience how easy you can make make it for people to interact with your app. And then our third element is actions, and AI chat will add it here as well. The things that you input in the input table can trigger actions. The different things you click can trigger actions and on the right, you see a little action sequence. If this thing happens or you click this thing, then clear this box and pop up this other box and make sure that this is written into this table. That's all something that's within your control of how it works. And the AI chat can be an element that you talk to on the side, but we can also give it permission to actually have it make the decision of approve or disprove, hit the buttons for us based on the analysis that we give it. It's within our control to say, you can do this, you cannot do this. And AI could take over parts if you wanted to. Now that we've covered the nuts and bolts of how it works, let's think about how to build this in the first place. Take a step back. What ties this all together? Because knowing the pieces isn't the same as knowing how to put them together in the right order. Take any Lego set. For those of you with a software background, Sigma renamed the parts. But a lot of this will start to feel like software development. The model is the input tables. The view is the layout elements. The controller is the actions. So you might have been familiar with this in a slightly different way before MVC is what it's called in software development. So some of this may be familiar to you. The build framework is Sigma's recommended approach, and we agree with it or we wouldn't be telling you. That runs in order through the business objective, the user path, the input model, the look and feel, and the development cycle. This is an ordered set of decisions. One happens after the other, skipping ahead or skipping a letter completely, hustling them around is an easy way to guarantee that you'll have to rebuild your app by the end of it. So we recommend to design in this order, starting from the business objective, the business outcome. And of course, I will walk you through after I take a sip of water. We start at the end. We start at the business objective, not objection, we hope. We start with the business objective. Every good app traces a straight line from the main indicators that you're looking at to what the business cares about, and then also to action. So think of the value that you're trying to get out of your process. What is really the end state of things? So connected through indicator, the value, the financial metric that gets this on your roadmap, but start with the objective of what is the decision being made? What is the process that is involved here? This is kind of what that four question test was asking rather than looking at a set number on a dashboard, what makes this different? Little five tests for your user path. Is there a workflow here or it says a report wearing a costume? Who are the personas touching this? What are the steps that each actor performs? I found in my Sigma project so far, it's been really useful to map the process. What process is this a part of? How much of the process can we get into this app into one tool that you can use to handle all of it? What are the statuses throughout? Where does work move from one hand to another? Who should be notified? How do you know that it's really, really done? And this is the one that people get wrong. It's not done when your manager puts it in a slide deck. It's not done when someone reports the number to another person. When is the loop actually closed? When is the decision made? When is the outcome really getting to us? It's like the views and roles from earlier, like who should see what, who should be able to do what, but made more explicit here and really mapped out before we built. The input model, what is being input here? And then what should we do with this input? Should we append it? We keep an audit trail of who adjusted what. That's generally the recommendation, but sometimes overwrite makes sense. So conscious choice makes a big difference. If you go to overwrite, you might lose data if that was the wrong decision and you might not have data on your audit trail. So default to append. And then we can choose, do we make it a big table and we grid edit, or do we make this a form like in our HR hiring app? A form is a bit more slow, but we can also really lock down how people input things. And it's also something that's familiar to people as a way to input data. So it might be easier for them to understand. This is what the input tables are to ask about. The look and feel. In a real app, we usually mix several of these, but let's look at all of these axes. Are we inputting a single record or are we bulk? Are we going by bulk? We gave both options in our forecasting app as individual lines that we could include or exclude or a bulk adjustment. Are we having all the information kind of ambient around the place or does it pop up in a model for you to focus on? Are we looking at one shared object that everyone sees, say that we gave everyone access to the whole of the HR pipeline dashboard, everyone could see, or if you come in as a hiring manager, you only see parts of this and the technical interviewer sees other parts of this. So is this going to be part by part? Is this everything in one place? Is it locked down by roles? And then solo versus multiplayer, is there a handoff in the process here? Is there someone to notify? Are there actions we can build in? And some of this already comes from previous stages. We mapped who is involved, what are they doing. Here it's about thinking how that might look and feel. Do we need to hit a button to notify people? Is that something we take care of automatically? And last but definitely not least, and I find... I lean on this more and more as the most important one, the development cycle. This is the easiest to skip past, but very important because a good app keeps developing after you launch it. The questions worth asking, who tests this and gives early feedback? Who owns this long term. What does success mean? And will we measure it? How will we measure it? Where can AI be layered in, in a way that we find helpful rather than strapping it on in the beginning, wherever it might fit. This is where I've seen Sigma projects as very close to software development. Work with an MVP, work in versions, work in sprints to really see this as an app and to move piece by piece. But whatever piece by piece you move, again, move in the order of business objective, user path, input model, look and feel, development cycle. That's our build model here. Let's take a look what happens if you skip a letter. I think I already mentioned, this is why all of this is worth an extra hour upfront to plan it out well, not just a nice to have. This first one I mentioned, when you overwrite your facts, then you lose your audit trail for good. You might lose some of your data. If you skip validation at the entry point, so people can input any sort of data, you will get that data in your backend. It's already in the system. So best design exactly what data is allowed to go where. That's in your input model. In your look and feel, a common reflex we see is build one big table. And that kind of recreates a dash dashboard instead of an app where we consciously walk through the process in a flow. Under user path, if we model this after an old dashboard, we might have to rebuild this thing twice. Every single one of these is a rebuild waiting to happen, not a style preference. When you build your dashboard, that one's close to my heart. I've built lots of dashboards, but when you build a dashboard, you're building with the limitations of the dashboard. And maybe you design your process around the dashboard, or maybe your dashboard lift to the side. It was a point for information, but not a point where the decision was made. So at times I've seen our clients rebuild their process and have the app take over several parts of this process for a much smoother experience overall between our objective and data and getting to that decision. So it's worth thinking about the process behind things, who is involved? What should it look like? What is the art of the possible in building this app before we open up the tool and start dragging things around. An app can help you in more places and will be useful if you give it that amount of thought. When I said our HR app was almost a functioning HR system, not quite yet, but it's also not crazy far from it. And systems are used for many years, encompass many parts of the process usually. So your apps don't have to be different. They don't have to be replaced a lot if you built them with enough thought. I'm a big supporter of dreaming. So go see the art of the possible and ask what could this do? What could this thing be? Zooming all the way out, that was our build business objective, user path, input model, look and feel development cycle. How do you pick a first app to build? You didn't just watch a webinar about a framework and then two unrelated demos. You watched an example of this framework twice, and then we broke down the different steps for you. What we did to choose our demos was look at things that fit these three requirements. Is this something repetitive? Or you could say, is this part of a process? Is there a human involved? Human in the loop, a person makes the final call. We can use AI to draft or prioritize. But is there a human in the loop? Is this a text heavy process? Is there value in someone explaining things? Is there value in summarizing things, whether it's with AI or not? Both demos you saw today meet all three of these, which is why they were good candidates to build in the first place. And I believe we have a poll for you somewhere. Because I'm curious, do you already have a First AI app in mind? Maybe you've already built one. So then you can just answer yes and it's defined. Please take a moment to answer. We do find these incredibly useful when we tailor our content or create future content for you. I think most people have asked, you've got about 50%. So I think there are a few more people that potentially could make an option. I'll go ahead and stop that poll, Robin, and share the results with you. Yeah, a few ideas are not yet prioritized. Nice. We're dreaming. I like it. On screen is our good one to help you choose. To help you choose the first one, you can always start light, build an MVP, build from there using the build framework, pun intended. Nice. Then I have a little recap with you, which is if you take anything away with you today, is that first four question test, am I building an app? Is there input involved? Is there logic that runs from that input shared source of truth logic? Are we maybe building different views for different personas and do different roles of people or different roles of people involved? And should they handle this app differently? That is when we are building an app, not just the location for information, but something with input and multiple people involved. And then the build framework we walk through. Start from your business objective, map out the process, the user path, who does what, who is involved, what should input look like, and then what should the app in general look like to guide people through our process, and how do we keep this moving forward? How do we keep this working well? How do we keep it helping people? So that we design something that people will keep using. Where do you go from here? Well, I hear you already have a couple of interesting ideas. So explore which one of those you can go with. You can also go through the Sigma app library. They have some pre built patterns that you can learn from. So if your app happens to be similar to one of theirs, that's a really interesting place to start. The framework from this webinar came from our interworks blog and we have a lot of other good content on there as well. And if you don't already have Sigma, Sigma has released Sigma public where you can play around with Sigma AI apps yourself. No setup required. Play around, see what kind of things it can do. And of course, come to us. We are happy to chat about Sigma. We're happy to help you explore it and to think about your use cases.
