Power BI’s Top 5 Challenges – From Frustration to Insight

Good morning, good afternoon or good night to everyone. My name is Johnny Girardi. I'm Data Sales founder and CEO. As you can tell here on my license plate that reads Data Geek. I am a big data geek. When I showed my license plate to my daughter for the first time, my teenager daughter, for her to see what I meant and she read date a geek and I cracked up. Ah, that was not intention. Yes, I'm single, but no, it's really data gig. I've been doing this, you know, business intelligence for small and mid sized companies for over 20 years. I was a software engineer. My early career became a business person and since 2005 I've been leading Data Self as a company, helping again. Mid sized organizations, small mid sized organizations do better with reporting. I'm excited here to do this presentation with Jordan. Jordan, would you introduce yourself please?

Yep. Thanks, Johnny. Hi, my name is Jordan Schneerman. I'm an analyst here at Data Self. I'm responsible for assisting with the development and the build out of the Power BI solution. And I'm excited to go through a lot of the cool stuff that we have under the hood and just, yeah, inform everyone with some of the cool Power BI stuff that we have.

Pardon. All right, so first of all, let me just go to the next slide here and we have some polls to kick off. We're going to spend about five minutes with a quick introduction. We'll talk about the business benefits, the business challenges and how we can help from a business standpoint. So if you're more business focused, the first 20, 25 minutes is what really you want to stick around to learn. And then on the last part, Jordan's going to kind of open the hood and talk about in more detail challenges that people have with Power BI in how we can actually assist or how you can learn new things, new tricks and new techniques to address those issues. Just before we, we launch into the, the presentation, I would like to see if you guys can go through a poll, see if I'm, if I launch the poll. Is it launched?

Yeah. Yep, I see it. Thank you.

So if you could please, you know, answer the questions quickly and then press the apply button.

15.

Seconds. All right, I'm going to end the poll. Results are still coming in. Thanks for sharing your thoughts. So let's go to the next slide here. As I mentioned originally, you know, we are in the business of empowering businesses, mostly small and mid sized businesses, with ways to get your data from your systems, your ERP CRM, Point of sales inventory system, Payroll, Google Analytics, no matter what your data is to help put into a BI solution in Excel doing so, the focus today is Power bi. We have been helping companies doing any kind of bi. And as Power BI became an amazing tool for the past 10, 15 years, we have embraced it and we also augmenting and also running to many of the challenges that people are facing out there in helping solve them. Especially if you're trying to get data into Power BI from erp, CRM, payroll and whatnot. There's a lot of challenges in the process of doing things from scratch that today you're going to be seeing why you might be facing some of those issues and how you can do better. We'll talk about that. The first exciting news on the Power BI and the overall BI journey is so exciting. If you're a data geek like Jordan and I and every day when you read the news, what Microsoft is doing, what the Power bi, the fabric and all the tools around the ecosystem is like being in a candy store, kid in a candy store. Oh my God, there's so many features. What can I use? Which one should I use? And sometimes they take it away, they kill the toy that you just chose and then you have to choose another one. It's exciting, but sometimes also a little bit overwhelming. But overall, it's an exciting time to be in this business. Microsoft has been saying for a long time, power bi 5 minutes to wow. Usually if you are already in the Power BI journey is because you were wowed by how amazing Power BI is. I usually tell the first five minutes is just wow, wow, wow. But when you decide to embrace and make you work across the company, usually five times later, five hours later, once you have the WOW now, you need to know what you're doing, you need to know your systems, you need to know how Power BI works, you need to know data models, security or refresh. There's a lot of things that a company needs to do really well for Power BI to continue to WOW across multiple teams, across multiple areas successfully. So five minutes is the initial while, but it takes some sweat and tears many times to really expand the while in the long run across everything. And it's completely possible to continue to out and not be too demanding in your resources. I tell people that nowadays some of the biggest challenges of making Power BI excel is people you know, finding the right people. The people that know you, know your data, that know Power bi, that know how to model, that understand your business problems, know how to solve it. Finding these people is not easy in Keeping these people doing Power BI is sometimes challenging. Sometimes they are promoted, they get too busy or they change jobs and then the project might hit a wall. And sometimes you hire someone else or you bring someone else to the team and sometimes this other person doesn't understand what the other person did or the other people did and then they start from scratch and they break things. So part of the challenge is just human nature. It's people having people that can actually maintain your Power B project successful in the long run, knowing what you need and how to do things. AI is coming all over the place to help with this process. And part of the challenges is amazing having AI as an aid to facilitate. But AI is not a magic wand, hopefully never will be. Hopefully we'll continue to have our jobs and you'll have to continue to rely on people that knows a lot of things, including Power BI to make the journey successful. The other challenges is technology changes fast in every day. You know, probably you're changing your systems quite frequently. If you're using Microsoft Stack, good luck. You know, pretty much every day, every quarter, every month they have new things, better things and they change the direction sometimes. So it's challenging. No matter if it's Microsoft, all the vendors, they always changing. So keeping up with the changes and how they affect your system is challenging. And sometimes if you don't have an expert assistance to help your internal team to keep up with those changes, that's also challenging. One of the most challenging things if you have been doing BI for a while, is just building your own custom model or data modeling around your reporting needs. Pretty much by default, the majority of the companies out there, when you're doing your data modeling is we call a custom data modeling. Whoever started and whoever is working, they are doing the way that they think is best and it's quite often is very personal, is very unique. And if you don't document things properly, which many people don't like to document, if you don't follow necessarily best practices, the modeling become tends to become a spaghetti noodle, a spaghetti code in the long run and we call the spaghetti model. So it's not unusual that if you are in Power BI three years into the Power BI journey and if you're getting sophisticated, if you that have not been involved in this process and you open the hood, you want to see the modeling, it is freaking hard to understand how the model works. So it's very common to become like a spaghetti model and very complex because we call this a custom made modeling approach. So we're Going to be talking about more about that and Jordan will open the hood and discuss some of those details in the last thing that to me has been my personal journey from 20 plus years is should you embrace a data warehouse or when should you embrace a data warehouse? Tools like Power BI and you look at competitors like tableau looker, domain, whatnot, they all claim that no, you don't need the data warehouse. We have enough ETL in our Power BI that you might not need it. So don't worry about it. Well, I tell people worry about it because one of the challenges is if in some point in your future data warehouse becomes a requirement and you didn't start from scratch, it can be a nightmare for you to untangle the customer noodle or spaghetti you built in your model into data warehouse 1, 2, 3 years down the road. So you should tell people if you find a data warehousing solution that is inexpensive, easy to use on day one for your Power bi, start with it. Because Power BI and data warehousing together are awesome. And in the long run you don't have to recode, you don't have to break your model to restart. And that's part of our journey. We help usually companies to see you can start with the data warehouse from day one or whatever the day that you're doing already your Power BI attach a properly designed data warehouse along with Power BI and make Power BI journey even more successful. So we'll talk a little bit about that as we go through this webinar data cell. Specifically from a business value, we have three main business values. The first one is just as I mentioned, we bring data warehousing framework and we have our own ETL tool. It's called Data Self ETL plus ETL stands for extraction, transmission, loading. Power BI has ETL functionality, yes, but Power BI really excels at data visualization and it does etl. Oh, you know, fine, it does fine, but it's not an ETL tool. It's in some of the problems that some of the data problems that people have. If you don't solve them with a data warehouse, Power BI is going to be clunky, it's going to be slow and it's going to be complicated to address. So usually in the long run Power BI will benefit from having an ETL data warehouse to complement. It can be your own data warehouse on premises, your private cloud can be Azure SQL can be eventually into the fabric no matter where you put it. But a data warehouse is usually a big part of your journey in the Long run. And we absolutely have tools to help with the data warehousing problem. That's value number one. The number two is in 20 years, one of the things that Data self has learned and put together is not a custom code modeling but, but a module, a product that we call dft. Dimension Fact and Time is actually a well thought out, a clean and well organized way to bring your raw data from your systems, like your erp, your CRM, your payroll, whatever it is, into a layer called DFT where you put dimensions in the proper dimension, structure the facts under the proper fact structures. There's time to help with the Power BI time analysis and this layer usually isolates the uniquenesses of your source systems into reporting. And why we do that for two main reasons. One is because we're separating the plumbing from the analytics so people who know plumbing, they can focus on that part of the problem to bring the raw data into the DFT layer. While the business analyst role, which is usually not necessarily a database person, is more of a business analyst person. They don't need to understand the uniquenesses of the data source. They just look at the dimensions, facts and times in the DFT layer if they can do their job without knowing specifics of the data source. Once we show this to you in more practical terms, you'll see the big value of this splitting in. The second main reason is because small and mid sized businesses, they are always or frequently changing their digital systems. Sometimes they change the ERP from, I don't know, QuickBooks into something more modern or something bigger like you know, Netsuite or Sage or Microsoft or Acumen, whatnot. Then when you change. Now if you have built your Power BI for Your, let's say QuickBooks and now you go to Microsoft Dynamics, you have to do things all over again. The DFT layer eliminates a lot of that overriding of your Power BI modeling because it isolates again the uniquenesses of your source system to the reporting layer. When we, when Jordan shows that what I'm telling you is going to make sense. But the DFT layer is also a big value that we add for clients. Third is long term BI expertise and support your team and data self. We have, you know, in the course of 20 years we have a, today about 35 people. We're all mostly data geeks that every day we wake up excited to learn to, to help companies like you guys to do better. And we can be a augmentation of your BI team. Sometimes we can be working with your team on an ongoing basis or we can be here to train you how to do better, how to use best practices, then we get out. And if one day your team or some of your people leave and you need to get someone else to help until you hire someone else, so maybe you need to train a new person, we can be here to assist you with ongoing BI expertise and support in Power BI in data modeling, in data warehousing, if you choose to choose data warehousing as well as in data sources, reports and dashboards for mid sized companies. So BI expertise is a big chunk of why many companies use this help to help the Power BI project to be more successful ETL that I'm showing here. Like any ETL tool, we can bring data from all data sources. There are more than 400 data sources. That is a no code approach. You don't need to write Python, you don't need to write any code to extract the QR code on this page. If it's not here, where is the QR code? Accidentally I deleted the QR code on this page. But we'll send by email later a link to our page where we list the 400 plus sources that requires no coding to bring data into the data warehouse and into your Power BI project. As I mentioned we support Power bi but we also support many other products. Some of our clients, not many, but some of them they use more than one analytics tool. So we support more than Power bi as I call the lipstick of the BI solution. I'm going to give a very brief tour in our DFT layer. The DFT layer, the dimension tracking time, you know we take data out of the box pre mapped pretty much on day one. If you're using some popular systems in the mid market system such as erp, CRM, whatnot, we take a lot of the tables from those systems we automatically through ETL plus put into your data warehouse, then we model them into the DFT layer and eventually connect to a Power BI semantic model and eventually into the Power BI reports and Dash dashboards. We have more than 5,000 Power BI reports and dashboards as a library. The idea is once you we provision your data self solution with your Power BI on day one. Once we have provisioned on average 80% of starting from scratch, your Power BI journey will be done on day one. 80% of the extraction, the fine tuning, the, you know, the keys, the primary keys, a lot of things are ready on day one. And what I'm going to show you now is just where you can go and learn more about this library in here we have the QR code. If you take a picture, you can go to the same place where I'm going to show you next. So if you go to that QR code, you're going to go to our knowledge base page, to this particular page here where you have the Power BI templates at the, at the workbook level showing reports and dashboards. If you choose the Enterprise is the one that we have the most reports and dashboards. And you can keep on picking, choosing. Some of these modules are going to be able to see a list of reports and dashboards. Let's say if I click AR Aging, we have multiple, pretty much any ERP system that you use. We can quickly connect this DFT layer to that erp, let's say, to do AR aging analysis. And if you scroll through this, you're going to see some screenshots as well as a list of the reports and dashboards available. So there's quite a few for ar.

Johnny, are you, are you sharing your screen?

Oh, you're not seeing what I'm showing.

I don't know if it's just me or if everyone else is. Mine just went away.

Let me stop and reshare it.

All right, Let me know if you.

Can see it now.

Yeah, I see it.

All right, perfect. So just going back a little bit. That QR code that I, that I showed before goes to this page here. And if you choose the Enterprise, you're going to go to the list of modules we have ready to connect to ERP in CRM systems. And if you choose a module like AR Aging, then you're going to be able to see a list of reports and dashboards, including some screenshots. And as you can tell, there is a lot of things included. As I mentioned, there are more than 5,000. If you choose Cash Flow Projection, for instance, same thing here, you're going to be able to see the list. If you go to inventory planning, which is also pretty popular one, you can see descriptions, screenshots and whatnot. And just one more here, Sales is the most popular. Many companies are looking for Power BI to do a better sales analysis. We have more than 1300 reports and dashboards in this library. And some people say, you know what I want, you don't have ready. Why would I need such a large library with 5,000? Think of it of being a library of. You don't need to read 5,000 books. Nope. When you go to a library, you want to find one, maybe two books that you want to, that you want to Read, you need to have a library with, you know, notebooks. Then every time someone has to build a freaking book for the reporting dashboard. If you have a library within 5,000, the odds are most likely what you're looking for. There's already something done or close to and if it's sometimes if it's closed with a few tweaks, you can fix it. So what we have found is many of our clients, when they use this library, the main point is decision makers will find a lot of their questions ready to go, answered ready to go or close to. And it's 5,000. You know, it's not all of them, it's not a million, it's not all. But the 5,000 have grown out of a list of clients asking us for reports in every time we have seen that the report can be generic for other users, we add to the out of the box. We started with this vision 2007 with only a few dozen reports and over the years it grew to actually 8,000. We have, we're building even more and the main idea is to accelerate break time to make more informed decisions and to help decision makers be more self sufficient. So the library usually is a big chunk of the value. Having said that, now for those of you want to learn more, the how and the why, Jordan is going to open the hood and give some more details on the technical side.

Jordan thanks Johnny. Yep. So we're going to start here with before we get into under the hood and the modeling, I think it's good to start with the top the main challenges. There's five that we see across a lot of Power BI projects. So the first problem and challenge that we see is companies relying on manual refreshes. This, there's a lot of reasons why you don't want to do manual refreshes, but the main being it reduces the efficiency and it also raises risk while adding a dependency layer. Since your semantic model has to be manually refreshed, a person has to manually do it. So that's a dependent dependency that I think every, every firm out there wants to mitigate. The second this is one of the most common challenges. Slow refresh times and refresh failures. This is, this is a result of a lot of different things. It's most common result of a poorly designed model or as Johnny mentioned earlier, Power bi. The back end of Power bi. It's like power pivot to what a lot of clients do is they'll connect to a data source and then they'll do their transformations in the back end of Power bi, renaming columns, changing value types, that type of thing. That, that's one of the worst things you can do, especially if you want your model to scale and refresh efficiently. Because every time Power BI goes to refresh, it's going to go to the table that has all those transformations and it's going to run it row by row. So this is the second challenge, again, probably the most common. And this is kind of where the database and ETL comes into play, pushes everything upstream, and then Power BI is just going to read from the model. The Third is inconsistent KPIs across multiple reports. Essentially what this means is there's no single version of truth. It's common for a lot of companies to have. For every Power BI report, there might be a different semantic model. For each report, one user will just have two, two people. You can have Jim and then you can have Carla. Jim might be building a report to get some sales invoice numbers for you. Carla might be doing the same report. The issue of the approach of having two different reports with two different models is Jim is probably going to do something his modeling one way. Carla is going to do the same. When it comes to actually calculating the measures and the metrics in Power bi, they also are probably going to do some things a little bit different. So standardizing your KPIs and having a single source of truth for all of your company's data or just segmented, you can have a data set for your invoice data, your sales order, either, or we're going to get into that after. That's also best practice. And then the last two are, the first one is limited ideas for KPIs. So as I'm sure a lot of us are aware, BI projects are a big initiative. They it often takes another slide. We say days, weeks or months. It's usually months. There's a lot of work and effort that goes into actually building your Power BI semantic model, structuring the data, how it needs to be structured for Power BI to run it efficiently. Then the last layer, once that is done, is actually building your reports in Power bi, which takes a lot of time, a lot of effort. When it comes to KPIs, there might be some limited KPIs that a business is using. Whereas with our approach out of the box, we have, we have thousands of KPIs, so there's most likely a KPI that you've never thought of, might not have heard of, but a lot of our out of the box models have all of this. Built in. So that's another big feature that we solve. And then the last point is just the frustration that comes with trying to connect and blend data from multiple sources. This is this point specifically. This is where ETL is going to come in. Okay, next slide, Johnny. Okay, thanks. So with the challenges being addressed, this is where Data Self comes in. We have an extensive selection. Johnny mentioned it earlier. We have way over 1000 pre built reports and dashboards. This spans across a lot of different areas, accounting, sales, operations, just to list a few. And then the other thing that the other benefit with our pre built Power BI reports is these reports and these dashboards, they're all very easy to be customized. They're ready to use right out of the box. And then there's also templates, QA templates that can be customized and just help before you go live with reports. There are templates designed to validate your data and make sure that the numbers and the metrics are matching the source system that we're pulling from. And then the last two points, just some benefits, accelerated insights. So once, once ETL is set up and the data is populated into the data warehouse, that is where our Power BI model comes in. Since the model is already preconfigured, I'm going to show this, I believe in the next two slides from now. Since it's pre configured from day one, once the data is deployed in the database, the reports and the model are ready to launch. It's as easy as connecting it to the server in the database and then having everything refreshed through and then the reports are going to connect to it. So the real benefit that you're going to get from that is quicker time to value and reduce development efforts. As I mentioned before, with BI projects it often does take many months, whereas with this approach it's days to go live. And then the last benefit is just improved decision making since everything is going to be streamlined right off the bat. Once it's deployed you're going to be able to get data driven analytics and insights. Next slide, Jeremy. Okay, so we covered just an overview. Now we're going to get into ETL Plus, I'm not going to go too into depth, but this is, this is the starting point for our entire model. Without ETL there really isn't. We have all the models but ETL is the, it's the concrete and it kind of holds everything together. So it all begins with etl. ETL is optimized for Power bi. What ETL is doing is it is handling a lot of the ETL process, extract, transform, load. It's bringing in the data into a data warehouse. For Power BI specific use cases, we recommend Azure SQL. The primary reason for that is Azure SQL is a Microsoft product just like Power bi. Is that being said, there's a smooth integration between the two and there's no need for data gateway. Typically when depending on the source, when you connect Power BI to could be whatever data warehouse it might be. Depending on the permissions you may need a data gateway. It's common gateway goes down, your report isn't your model and reports aren't going to refresh. So again that's another dependency that that we could have from not using Azure SQL. You can see we have this slide is just going over some of the reasons why Azure SQL eliminates the gateway. The first one being its native cloud integration. As I mentioned before, it's Microsoft, it's integrated very well with Power bi. It's a cloud based service. You have the cloud integration when it comes to security and compliance. It utilizes Microsoft Entra ID authentication. There's firewall rules and encryption and encryption settings to ensure secure data access. And then the last two. It also helps with performance and scalability. Behind the scenes. Azure SQL has a lot of different things. They have elastic scaling, they've automatic performance tuning and they're also kind of geared towards large data sets. So as as your company grows that more data, the database is automatically going to scale up for that. And then the last thing I want to mention is I don't know how familiar everyone is with Power BI or whether you are in your data journey. But when it comes to connecting to the data source, power BI is two methods. There's DirectQuery, which is essentially a live connection if you will to your Azure SQL or your database. And then there is import mode. Import mode works in the sense that every time the Power BI model is refreshed could be automatic, scheduled or manual, it's going to reload all of the data and save it in that file. There are benefits to both. I always recommend import, but for directquery, which there are some situations where you would want to go that route, Azure SQL has a much better connection as opposed to other databases. You're able to do more with the directquery. Next. You can go to the next slide. Yep, thanks. All right. So with Data Cell spi the need for manual refreshes is eliminated. We mentioned this in the beginning as being a common pain point. The three challenges with a manual refresh, we kind of touched on it earlier. There's operational inefficiency where you have to manually trigger an update you were that requires someone to physically go in and trigger it at a certain point in time. There's increased risk. Human errors when refreshing. That's, that's a big one. I've seen that a lot. And then timing of data refreshes. If, if something is being refreshed manually, there isn't really a set time that it's going to be refreshed and you can run into some data integrity issues. Typically the refresh cycles, it's always going to be on a schedule and all of our reports is going to be timestamps. So when someone looks at the report, they're always going to be able to know when it was refreshed. They're not going to have to go reach out and try to figure out, hey, when was this manually refreshed? And then the last challenge of manual refreshes are scalability issues. As volume grows, it's just going to become impractical to refresh the data sets manually. This is where our BI solution comes in. With the help of ETL plus the Power BI modeling that we're going to get into in the next slide and just automated refreshes through ETL and also through the Power BI service, we're able to address all of this. We're able to set up automated refreshes. You're going to be able to to in the future, in an upcoming release, go in to ETL and update whatever specific table in Power bi. You're not going to have to refresh the whole model. You'll be able to automatically kind of connect to that table in an easy to use user interface and refresh it if you wanted to. And then the last piece with our BI solution is governance. Governance is huge. Especially when a company undergoes the initiative of going to a BI project. There's a lot of sensitive data and I know that that's usually one of the most important things that a company has to think about and manage. So I just want to address this with our out of the box solution we have built in from day one. Row level security and object level security, both of which can be customized. Row level security is often customized. That has to do with specific user, what data they're essentially able to see at the row level. So if you have, let's say you have an office in, I'm based in Florida, so let's say there's an office in Fort Lauderdale, you can apply a row level security. So I'm able To only see invoices or orders associated with the Fort Lauderdale office. I'm not able to see anything else. Object level security has to do with actual objects. So think of this as table entities. You have a master model that has all of your data, you have your sales invoice, your sales order, your purchase order. If you only want me to be able to see purchase order and sales order information, that's where object level security comes in. It's permissioning based off a specific table entity. You can go to the next page. Johnny this is the fun stuff. This is where we start getting into our DFT layer and different use cases. We're going to run through these scenarios really quick. These may, I'm sure if you already have a BI project with Power bi, I'm sure some of these scenarios may apply. I hope that they don't, but it's. A lot of these scenarios are pretty common. So the first scenario is the manual export dependency. So this scenario has to do with, it has to do with a team regularly exporting flat files from. Could be any source, could be any of your source systems. You're exporting them to Excel, maybe whatever you're using as a database. And big issue with this is the dependency. Everything when, when you're building a BI project, everything should be scheduled when it comes to the refreshes. And yeah, there's, there's a lot, a lot of issues with this scenario. The second scenario is local file dependency. This is, this is most common in, I see this most often in companies that are kind of in the inception of taking on a Power BI initiative. Power BI has two different routes. They have Power BI Desktop, which is a free desktop app. That's typically where all the development comes in. That's like where you build the reports and everything. And then there's Power BI service, Power BI service, it's web based, pretty much in the cloud and that's where you're publishing everything. And then that's where users are able to log in and actually consume their reports and gain insights. But typically when a company starts, they might not be aware of the licensing involved or just some nuances with the Power BI service. What they do is they build a Power BI file, they save it, it's saved as a Pbix file and then they just share that file internally amongst their team. A lot of downsides to that, first being you have to refresh it manually every time. And then second, there's no version control and it's inefficient. So that's the second scenario, the third scenario is inefficient data modeling. So Power bi, Power BI is designed, Microsoft designed it to be. There is a lot of code that goes into it, depending on what you're doing with it. But they designed it as very low code, no code. They wanted your average business user to be able to connect and build charts, kind of gain insights, which is great. But Power BI is extremely, extremely complex, especially when you want to build something the right way, when you want it to scale, when you want it to be accurate. Even though Microsoft tries their best to make it easy to build some basic reports, you run into the issue with actually setting up the model in Power bi, structuring relationships and using one table, essentially just having one large flat file that contains all of your data. Power bi, the next slide we're going to get into this. Power BI does very well with data modeling and there's a lot of nuances that go into it in order to have the model refresh and everything to be all your numbers and your data to be accurate. The last scenario, this is more common to companies that are already using Power bi. So this is to do with overloaded DAX calculations. What DAX is stands for Data Analysis expression. It's Power BI's language. Like when you want to build measures, it's basically the syntax in order to kind of create a measure. One thing that commonly observed with this is the measures are often overloaded, where a lot of companies may be trying to do advanced calculations in the measure itself or just basic calculations in the measure itself. When all of that should be pre aggregated into the data warehouse, again, that's where ETL comes in. But this is another scenario that I see. And the biggest issue from this scenario specifically is if you're looking at your Power BI report, you might encounter issues where the visuals are just spinning because it just evaluate all the data, it's not present all the time, which it should be. All of these scenarios, you can see the four, the four costs associated, increased maintenance effort. We talked about that. Scalability issues, duplication of effort and slow and inefficient processing. So again there's a lot of modeling that has to go into this. And yeah, these are the four most common scenarios. So next slide, Johnny. So getting into the next slide, this is where we're going to touch on.

Just a note you have. So if you can finish in 10 minutes.

Okay, so this is where the DFT layer comes in. This is our proprietary modeling method. This is the solution to everything that I just mentioned above. When it comes to inefficient modeling issues, all that kind of stuff. So the basics of it, I'm going to go too into depth here. Johnny discussed a lot of it, but it's split into three different table types. We have dimension tables. Think of these as they're your qualitative tables. They store descriptive attributes, product name, region, that type of a thing. Then we have our fact tables, These are our quantitative tables. They store your measurable data, your sales invoice amounts, quantity amounts, that type of thing. And then we have our timetable, which is our date related field. Power BI has a lot of date, time, functionality and having a predefined timetable, if you will, is crucial in the model. And yeah, I'll just touch on the last bullet points. I know we have 10 minutes. So what we're, we're the next slide. We're going to go through some examples but here at Datasoft, this, this is our primary approach. And yeah, everything from day one out of the box, everything is going to be pre built, clean, scalable and pre configured. So the real benefit from this, besides all the efficiency gains and the time savings is since everything is standardized and well documented. If there is internal turnover of someone who is working on some of this stuff, everything's going to be documented. It's not so and so built it this way, what did they do? And a lot of this also is all best practice when it applies to data modeling and Power bi. Next slide, Johnny. So next three slides we're going to get into just the modeling. So this is, this is very common and it's also very bad. So typically what we see is flat tables. Companies take their data, they export it, they put it in one table, they might just set up a huge GI and have that be their table and then they'll bring that one table into Power bi. This may work in the short term, may work in the interim, but long term, this, this is not going to work. There's a lot of, a lot of issues with this. There's performance issues, it's not gonna, it's not very scalable. As the company grows, that's when you're gonna, if you're not experiencing issues, you will and then you're limited on relationships. Power bi, as I mentioned earlier, Power BI likes to have a model, typically a star schema, snowflake schema, galaxy schema. Power BI likes to have everything divided into dimension tables and a fact table. I don't want to get too specific, but that's how the back end evaluates all the data. That's the structure that Power Bi likes. Last two. There's a lot of redundancy, a lot of repeated values with flat tables. And then once you actually get into building your report and having to rely on DAX to, for your measures to kind of aggregate your numbers, it's going to require a lot more complex stacks. Just because it's a flat table, there's going to have to be a lot of internal filtering done within the DAX calculation, which is going to be. Yeah, extremely slow. Next slide, Johnny. So that being said, we have two models, both of which are out of the box here at Data Self. This is the first model. So this is a module based model. You can see it follows a star schema. In the center we have sales invoice, so that this is a sales invoice module. And then all of the tables around it are the dimension tables. So just the categorical values. This model is. It has, has some benefits, has some challenges. Benefits. There's independent development so different teams can work on different modules separately without interfering with one another. When it comes to access, permissions can be managed at the specific module level which is going to help ensure users access only relevant data. This approach also tends to be a faster deployment. Just because there's one model for each module typically doesn't require too too many adjustments. And then the last one is simplified security. So it's just easier instead of it's just easier to have one model and grant access on that module. Since it's a sales invoice, you can come to the sales invoice module grant access. There tends to be simpler challenges associated with this view are risk of data silos. So separate models can lead to inconsistencies in reporting different transformations and definitions. There is limited cross module analysis with this.