Welcome to The Dashboard Effect Podcast. I'm Brick Thompson.
Caleb Ochs:And I'm Caleb Ochs.
Brick Thompson:Hey, Caleb. Hey, before we get started, I wanted to remind our listeners that they can go to our website at bluemargin.com. There's a lot of free information along the same lines as we've been talking about in our podcasts. So if you're interested in this topic, take a look there.
Caleb Ochs:Yeah, yeah, we're putting in a lot of work over the past few months and putting out some cool content. So I hope that it's helpful to people just like (hopefully) this podcast.
Brick Thompson:Yeah, definitely. Alright, so the topic today is what we're calling "BI Paralysis" -- things that can keep companies from actually getting rolling with their BI, even once they've started an initiative.
Caleb Ochs:Yeah, it can always, it can always bite you. Sometimes when you least expect it sometimes when you don't. But there's a lot of causes for it. And hopefully, what we can do through this discussion is going to give you some ways to get over it, and get some reporting out and make better decisions.
Brick Thompson:Yeah, good. I think one of the main causes that I see a lot is that there are stakeholder groups in a BI project, they can't get in sync on business rules and business logic around KPIs and measures that type of thing. And that they just spent too much time trying to get it perfect, before they actually start putting stuff on paper (not on paper, but on the screen) getting reports that they can look at. And we've certainly had that ourselves here at Blue Margin. And I can think specifically of a time that we were switching from billing by time and materials to fixed-price projects. And so we needed to redo our reporting to understand how we were doing in these projects, and we did a project internally. We're good at this, but we got pretty hung up on getting the report perfect before we finalized it. And then in the end, we did what we recommend clients do, which is go ahead and get a draft out and start iterating. But it can even bite you if you're used to it and good at it. And I think maybe it bit us a little bit because we are experts. So we felt like okay, we can make it perfect before we build it.
Caleb Ochs:Yeah, right. I mean, it's a perfectly reasonable thing to do, right? It's the thing, we got to get our logic. We have to know what we're gonna report on first. And we got to figure this out so it's perfect. And then we can build the report, but there's two sides to every coin, right? There's the logic, and then there's how it actually fits to your data, and then actually just seeing it. So there's those two things that you have to balance. And it's best to do those things kind of at the same time, right? Define the logic and also look at what it's doing on top of your data at the same time, so that you can make a better decision on how you need to tweak the logic, if at all. And then in real time you're seeing how it translates to your data. So it's important to do those things together.
Brick Thompson:Yeah, I think it really is where you can get stuck. And we've seen it with clients, even recent clients, especially clients that have a lot of different business units, and they don't maybe understand their data very well. And so they're sort of having discussions internally, maybe even arguments about how they should be calculating things. And in fact, if you could just build something and put it on the screen in front of them, they can very quickly zero in on how it should be,
Caleb Ochs:Yeah, where it might not be right or where it needs to be changed, or things that are looking right. All those things just become a lot easier to find and identify, and it gets people on the same page a lot quicker.
Brick Thompson:Yeah. Like the same thing happens just around data quality. So you know, you've got, you've got the issue of "Alright, how are we going to calculate something simple, like utilization of a resource?" something like that sounds simple. But you bring, you know, five different experts into the room, they might all five have different ways of calculating. So that's kind of what we're talking about here. But you can also get it just around data quality. So if you know your data is not perfectly clean, let's say you don't have good master data management. So for example, in your data, you have several entries for the same client. You know, let's say McDonald's restaurants is your client and you have an entry for McDonald's restaurants, McDonald's, McD's, (I think we've used this example before). They're all the same thing, and so you might feel like okay, we've got to go fix all that Master Data Management, get that all into just "McDonald's" before we start doing reporting, when in fact, the opposite is really true to the report, or do a report that's specifically made for trying to help with fixing that data of and you get there much quicker,
Caleb Ochs:Right? Yeah, you definitely get there quicker. And at the same time, as you're putting out these reports that maybe not perfect according to your definition, you know, you might have three different versions of McDonald's. But what that will do is it'll surface that information to the rest of the company. And the more that your company understands the intricacies and the ins and outs of of your data, the better off you're going to be, because then they'll be able to make their own processes better. They're going to understand what they're looking at when they're consuming a report. It's just better for everybody, the more knowledgeable the your employees are around your own data.
Brick Thompson:I think that's right. And if you, if you take the approach of, "Hey, let's fix the data in the transactional system, (let's say in the CRM or whatever), before we do any reporting, because we want to make sure it's exactly right, before we get it out," you lose huge opportunity and time and actually a knowledge of people that can look at it. If you can take the data out of the transactional system, and put it into a data lakehouse so that you can do discovery and analysis and so on more easily, you get to a better place much quicker, you may go fix the data back in the CRM in this example, the transactional system, but actually figuring out what you need to do, you can do more easily a lot of times when you have that data outside of the system.
Caleb Ochs:If I was that person that had to be had to, you know, clean up the transactional system. First of all, it's kind of a boring, tedious, not fun job. So I'd want to know why the hell am I doing this? Right? And if you've got like a draft of a report that showing Customer Lifetime Value, for example, and you've got three different McDonald's and you know that they should be one, it's pretty satisfying to go fix the data in the source, and then see that report correct itself. It's actually awesome. Yeah, at least I like it anyway. But I'm kind of nerdy.
Brick Thompson:Yeah, I agree. I must be too, because I find that very satisfying. To scratch that itch. When we were talking before we started recording, you had the example of a client who wanted every number on every report to be absolutely perfect to the penny, before exposing anything to the business. And well, you can tell us about that-- you had an opinion on that.
Caleb Ochs:Yeah, I think in some cases that is appropriate, depending on what type of reporting you're doing. But in this case, it was more operational sales reporting, and there's no, you know, get the data out like, it's, it just delayed the process. I don't know how long, but by a couple of months, probably, before people are actually seeing results. What that does is 1) it's like, everybody else is like "What's going on over there? Like, it doesn't seem like you guys are doing anything." And 2) It just keeps that information from people. Even if it's 90%, 80% directionally accurate numbers, you can then start making some decisions. You can see how your decisions are impacting the numbers, even if it's just directionally accurate. Like I think it's much more valuable to get data out. You know, you got to be able to be pretty confident, you know. You can also harm the business if you put out just completely incorrect stuff, right?
Brick Thompson:Of course.
Caleb Ochs:You know, if it's directionally accurate, that's still really important.
Brick Thompson:For a lot of use cases. So in other words, consider the use case. If there's a use case where knowing something within 5% actually advances your ability to make good decisions, and maybe even improve that data so you get it down to perfectly matching -- do that. If your use case is like, hey, this has to be down, actually, to the 100ths of a percent correct, or that could cause big problems. Okay, obviously, that's a different case. Yeah, you have to you have to be a lot more careful that way.
Caleb Ochs:Right? Well, in this company's case, it was a month before they got any sort of reporting, you know. I think they had a monthly reporting cadence. And you know those four weeks, it's like, you're kind of working off of the best information you have available at the time, like, yeah, maybe you could go run an ad hoc report. But that's probably directionally accurate to because your analyst didn't put it together and run all their processes on it. So when you really think about it, it just makes a ton more sense to just get it out there.
Brick Thompson:I mean, in that case, that we were talking about a specific case, I'm sure the reporting that had either didn't exist, or wasn't correct. So it didn't need to wait to the to the penny.
Caleb Ochs:Yeah, exactly.
Brick Thompson:So but there is a there is a valid concern about getting into the penny, which is"My users, if they find a mistake, if it's off by a penny, they might decide that they don't trust the report", and they don't get good adoption. How do you think you can deal with that?
Caleb Ochs:That's a really good point. Yeah, I mean, you you that is a risk that you run, right? I think it's mostly in communication and messaging to people. I guess here's where it gets interesting. Let's say you're sending out a report every month. As soon as you send that report out, it's already old and obsolete and invalid, like, an hour later, if you go try and match that report to the source system, things have probably changed, and it's not going to work anymore. That doesn't stop people from taking, let's say, you put out a Power BI report, for example, that shows the same data as this monthly Excel report you put out doesn't stop people from looking at the Power BI report then looking at the Excel report and be like, "This is wrong." I think that kind of scenario is where (kind of going back to our initial or a little bit earlier), where we were talking about just getting people to understand the data. Like, yeah, that's an education process, like you're never going to have...never is too strong of a word...but it's not very often that you're gonna say, Power BI report matches exactly in total aggregate numbers to my source, because the source is live. And your Power BI report probably refreshes on a on a schedule, right? You could make it live Piwer BI report, too.
Brick Thompson:Really good point.
Caleb Ochs:But it's always going to have some subtle differences. So once people start understanding data, and just kind of the nature of it, and getting to the point where they do understand that having like this rolled up view and directionally accurate numbers is better than than nothing, or a report that's a week old. Right? Yeah. So it is It's
Brick Thompson:It's a good point. I mean, I think we've tough. done things in the past that people could do to which is produced the report, and you can put a banner on it that says"this is a draft report, it's correct within 5%. Use it for directional things, don't expect it to the penny." You know,"We're working on it." Or you can put a whole note on there, so that people know what the expectation is. I do think when you produce a perfectly formatted official report, there is an expectation that is exactly right. And there will be you'll run into users who are sort of looking for a problem. And it's not inappropriate, actually, it helps you to get the report, right. But giving them a heads up about, "Hey, we don't expect this to be perfect." And then you can change that banner when when it's fully validated, and everything's matching perfectly, you can change it to I don't know how you designate that. designation. Yeah.
Caleb Ochs:Yeah. And, to your point, like, you want people to be looking for problems in it because it helps you suss those out and fix them faster. And even once you get a perfect report, things in your business are going to change. And you know, what one field was used for at one point in time may change, their process just changes. And you want things to change in your business, right? That means you're growing. It means you're making progress on things, so that's going to throw your reports off, and they're going to be wrong again. I think that that's where it all comes back to education of people that are looking at the reports like, you've got to know that this is not that this is an evolving thing, right.
Brick Thompson:It's a living entity, actually. And that's something we've found in our business where in the old days, we would do sort of these monolithic projects to produce a report. And what we've learned is that you're just going to need to iterate reports ongoing. Either internally, hopefully, the company has resources that can do that, or sign up with us to have us monthly help do that. We learned that internally here years ago. We thought we can have perfect reports and they would stand forever. We learned really quickly that as the business is changing, we're changing those reports constantly. Right? And so get that expectation in there. Yeah, I think it's important.
Caleb Ochs:Yeah, it makes your life a lot easier.
Brick Thompson:And it may be hard to have that expectation, because when you're using your transactional systems, they come with a reporting suite. Usually, those don't change at all. Usually, you can't customize them much. Maybe you can change visualizations or where things are on the page. (Which actually, that can get you a long way sometimes.) But there may be an expectation of "The reports the report. That's just how it is." And I encourage people as they're thinking about it, to not think of it that way. Realize it's evolving. It should be you should be improving it
Caleb Ochs:Right. Exactly. That's what you want.
Brick Thompson:Alright. Alright, BI Paralysis -- don't fall don't fall victim.
Caleb Ochs:Yeah, overcome it.
Brick Thompson:Thanks, Caleb.
Caleb Ochs:Thanks.