Today, I want to take a few minutes and talk about my last week. It was a hard week, not because anything bad happened, it was just a tough week. There was a lot of challenges that came up, and it got me thinking. As I was preparing for this podcast, it got me thinking. It is not easy to face hurdles as we are on this journey to building a Reportopia. It is easy to say this isn’t worth it or “I quit. This is too hard.” I just want to spend today’s episode recognizing that there are going to be challenges on this journey. But at the end of this episode, I want to provide my opinion on how we can overcome these hurdles. Not to say it’s still not going to be hard, but just maybe how we might think about some of these challenges.
So I’m going discuss this topic in today’s episode just by giving some examples. There are really three categories of challenges that came to mind as I was preparing. First, we have business logic challenges. We’re going to talk about a couple of examples of business logic challenges and describe it as well. Second, we have people. I guess dealing with people and politics might not directly contribute to building your Reportopia solution, but it’s still something that we must deal with. Finally, you have the human factor, mistakes. Mistakes are going to happen.
Let’s start out by talking about business logic challenges. We go out there and we find a value opportunity. The opportunity is something that we think we can improve about this business, help us grow faster, or make a process run more efficiently. This is a theory, if you want to approach this by using the scientific method. Then you take that theory and do the research. In the case of reporting, we look at where we will get our source data, and what does that data look like when we pull it out of the source system. And then we must apply the business logic to gain insight. We look at how we are going to transfer that information into insight.
The application of business logic sometimes can be very straightforward. If we’re talking about sales and we just want to know how sales representatives or regions are performing, it’s generally straightforward. We can just simply look at how many deals they closed, or we can look at how much revenue was generated. There’s a lot of different ways to look at it, but some concepts like that are simpler than others. I want to talk particularly about a marketing measure, close rate. This is something that I’ve been working on with a client for years. Not talking about the logic for years, but we’ve adjusted the logic for close rate several times.
I’m going to dive into this common marketing measure because I think it really exposes how business logic can get quite complicated quickly. First, what is a close rate? We’re basically saying, “Out of all of the opportunities that we have to make a sale, how many of those opportunities are successful? How many of them result in a sale?” The numerator is the number of people that bought. The denominator would be the number of people that we had the opportunity to sell to.
Now, on the surface, it seems quite simple. You might look at what was your close rate over the past one year or your close rate in 2021. Simple enough, right? I can go out there and I can count how many distinct people purchased from me. I can go out there and figure out how many distinct people I had the opportunity to sell to. It gets more complicated. First, the opportunity may not have happened in the period that you’re measuring. If we’re talking about the year of 2021’s close rate, then what if an opportunity happened in December of 2020, and then the sale happened in 2021? Are we going to count that sale in 2021 without any corresponding opportunity, and just assume that maybe it’s all going to work out, by the end of the 2021 period? You might have the same scenario where opportunities didn’t have the time to close? That’s one approach.
Another approach would be the people in 2021 that purchased but didn’t have the opportunity to purchase in 2021. They didn’t have any evidence of the opportunity to sell. Another way of saying this, is that we can infer that opportunity. If we had a sale, then there must have been an opportunity. Even if we didn’t find one in our measurement, we can infer that opportunity.” That would be another way of handling this situation. An example of this could be visiting a website. They could be showing up in a store for an appointment. There could be several things that you use to determine if you have an opportunity.
I started by saying that we’re going to count distinct customers or website visitors. Is that even the right way to do that? There are a lot of little things that we can get wrapped up in when it comes to closing or converting, depending on which part of the world you’re coming from. Whenever we’re defining these measures, there’s a lot of little things that can creep up that makes the business logic more complicated. When the logic gets more complicated, the development process goes slower. It gets more difficult to understand the results of the business logic. Ultimately, we’re trying to come up with a measurement that we can hopefully see how it’s performing through time. That’s really what’s important.
Often, the rate itself is not the most important thing. What’s important is to know that we have a consistent measurement, and we can determine if we are improving or not improving. We need something that we can measure against, and it goes further. You may have a business model that considers a close rate. You can figure out how much you might be able to spend, again, considering the lifetime value of a customer, etc. These things all play together.
That’s one example of how business logic can get complicated quickly. On the surface it might seem quite simple. Another example of this is a completely different situation. I have a client where we are working on payment postings. Basically, we are trying to eliminate a lot of the manual work that goes on whenever a customer makes a payment via credit card. We want to post their credit card payment to the accounting system automatically. We know through the process of that person making a payment, we know their name, we know which invoice they’re paying on, and we can automate that process. We have the evidence we need to automate that process most of the time.
In this case, the business logic is more of a combination of technical and business logic. The evidence that we have in this case is in the form of an email, unfortunately. We’re parsing the contents of an email body. It’s in a standard format, but we’re parsing the contents of an email body to try to find the different data elements. These elements can be the customer’s account, what’s the payment being made on, or what’s the amount of the payment. You can imagine an invoice or a payment receipt in the form of a email body as text, and we’re trying to take that and parse out the different elements we need. By and large, it works great, but it doesn’t always work perfectly.
In this case, I made a misjudgment. I looked at this body and decided how to parse it out, and what ended up happening was there was a shift in the characters. There were more characters in one payment than there was in another, which ultimately ended up in us losing or posting a few payments without these cents. For example, if it was $100.25, we were posting $100.20 instead of $100.25.
We need to define that business logic with certainty. If we were to stop and analyze every possible scenario before we made anything happen, the process would’ve been a heck of a lot slower. Defining that logic can be complicated, and there’s countless examples of this. This is not something that matters which industry you’re in, doesn’t matter which horizontal within an industry you’re in. You can be in IT, marketing, sales, operations, finance, it does not matter, every segment has these business logic complexities that we have to deal with at one point or another.
That’s the first example of how things can get hard, and sometimes that hard work can be fun. It is challenging to just mentally put yourself to the test and think about these things. But eventually, we must decide.
The second area where things can get hard is around people. At LeapFrogBI, we work with several clients. The decisions are made by the client. They have to say if they want to follow through with something, or not. They have to make a decision on a particular scenario. This is going to fall on our client, basically.
Someone in your organization, if you’re building a Reportopia solution, has to make decisions. What I see happening often is as companies get larger, they naturally get more complex. Then there’s more people involved, and when there’s more people involved, there seems to be this tendency to protect yourself or play it safe. It’s almost like once you decide who’s going to decide, that decision maker worries about what happens if they make a bad decision. I understand that sort of thinking, but it really stagnates the processes and the development of a really effective solution.
We don’t see this all the time, but I do see this occasionally. It is something that needs to be addressed. My opinion on this is that we must have a culture where people are able to make mistakes. That’s really, important. If your organization has given someone the authority to build this reporting solution and you want them to be successful at reaching some goal that you have not reached before, then there is a risk factor. No matter how you cut it, there’s a risk factor somewhere.
It could be in the business logic, like we just talked about. We might make a bad decision that ultimately doesn’t measure exactly what we want exactly the way we want. It could be in the way we’re sourcing data. It could be in several different things. Maybe we didn’t have the right testing cases. There’s a lot of different situations, and of course, we’re always going to try to avoid mistakes wherever possible, but people need to have the freedom to make the best decision they can, look at the outcome of that decision, and not be punished in any way if the decision turns out to not be correct.
Don’t get me wrong, you don’t want people just willy-nilly making decisions that don’t make sense at all. But you don’t want to stagnate your organization by making decisions that don’t have good outcomes as being a terrible thing, The point is, you want people to be able to make decisions with the information that they have at hand. You want good, critical thinkers that are making rational decisions. Those decisions are not made with 100% understanding of all the things that are impacting that decision so there’s going to be cases where the decisions don’t turn out to be correct. What’s important is that the decision makers quickly recognize that the outcome is not what we wanted, and they adjust. That’s what should be rewarded…..the people that can actually see what’s going on, make a decision when it needs to be made, and then adjust if things are not going correctly.
Area #2 kind of bleeds into area #3, which is just the simple mistakes. I’m going to repeat myself here a little bit, but it is so important that we have a culture that really fosters the learning process. We don’t know all the answers when we go into building these solutions. We know there’s an opportunity and we have a pretty good idea how we’re going to realize that opportunity. We can evaluate exactly what are we going to do to improve this business process. We ask ourselves,” Are we automating a process altogether, or are we creating some type of insight that’s going to enable people to make the process more efficient?” We have that going in to building these solutions, but mistakes are going to be made.
I gave an example about the credit card payment postings earlier, where we’re trying to parse the body of an email and you can consider that to be a mistake. Should we have known that characters might shift on other bodies of text? Sure. I think, inherently, we did know that there was a risk of that, and we didn’t find this scenario in our initial test cases, so was it a mistake? You could call it a mistake. You could call it a business logic gap. Whatever you want to call it, it is something that is going to happen, so it makes building these solutions a little bit harder. It makes us really work to look at these detailed situations and try to figure out what is the right way forward.
Here is another example. This week, I had a client where we’re trying to optimize a process. We’re trying to identify when there are errors in a complicated process where both people and automation are involved. We’re implementing that process across five different companies. This is a collection of companies that are being managed in this same way. And one of the companies ended up not being included in the error collection rate. It wasn’t included because I didn’t include that company in my initial logic. I had jumped to the conclusion that we were not including that company; I didn’t think they were going to be involved in this process. Ultimately, they needed to be involved and I thought I had added them. That’s the best way to describe that quickly.
Ultimately, it’s a mistake. It’s a mistake that I made. And when I went back and looked, I thought what I could have done to not make this mistake in the future. How could I have known to not make this mistake in the future? That type of questioning of yourself really, I think, grounds you. I consider myself to be pretty good at what I do, I’ve been doing this for a long time in a lot of different situations, but I still make mistakes. I do try to question myself about how to improve, and in this scenario, how could I have improved. Well, I could have done better at documenting the process. In this case, there were reference tables that needed to be updated that didn’t get updated, but if I had documented the process further, then maybe I would’ve followed my documentation when I tried to implement this additional company and that might have prevented the mistake from happening.
In any case, the point of this is that mistakes are going to happen, it can sometimes be disheartening, and it makes this whole process seem hard. Building Reportopia is not something that is typically going to be a very easy thing to do, and that doesn’t matter if you’re on the technical side or the business side. There’s a lot of work to be done. Sure, there’s low-hanging fruit out there often that can be knocked out quickly with very little risk, but as you get further down the road and you’re trying to be more and more efficient, you’re shaving much smaller margins off your business processes, I guess you can say, which adds to the difficulty of being successful. Not to say you won’t be successful, but you will be successful if you stick it out and do the work that has to be done.
These three areas can be difficult. The three areas are, defining clear business logic, just working with people, and recognizing that mistakes are going to be made. When working with people, there’s often a lot of people involved in these processes, and everybody’s got their own way of doing things. Everybody has their own interests, so being upfront about those interests is important. We should recognize that mistakes happen and make that part of the process. People should feel like mistakes are part of the process. When people identify a mistake and correct it, that’s really the thing that should be focused on.
Building Reportopia is totally worth it. These little things that I’m talking about are often why this work doesn’t get done. It’s so small compared to the opportunities that we’re often trying to capture.
The first bit of advice I have is, don’t let perfection get in the way of progress. You can talk about business logic until you’re blue in the face. You can bring in all kinds of committees and see who you think is the most critical thinker and has the most foresight into the ramifications of each little nuance. Or you can get something out there and start capturing some value today. Maybe you can capture 80% of the value today with the no-brainer portion of this logic, and then you can focus on that remaining 20% by optimizing the business logic. Don’t let perfection be the reason for not making progress. You need to make progress and continue to push forward.
Secondly, in my opinion, the way to overcome some of this is trying to keep things simple. Especially when it comes to business logic. You can basically create business logic to deal with every nuance that could possibly come along. I would say you’re kind of tuning your metrics, which you want to do to some extent, but you don’t want to over tune your metrics until they’re just unrecognizable.
In some ways, you can say that all that noise that is going to be part of the metrics that we’re creating is part of the metric. It may be offsetting the resulting values a little bit. Does it really matter? Is it worth the complexity to account for every nuance within the business in order to adjust this number to something that basically is going to be 0.01% different from what it would’ve been if we don’t even address those things? I would say probably not.
But back to Point #1, if it is worth it, don’t let that stop you from making progress. Go ahead and get the thing out there in a way that is defined that most people can agree with and then move forward with the complexity if you absolutely have to. Ideally, though, keep it simple. When you keep things simple, people understand it.
People understand a measure that you can describe in a couple of sentences. If you can’t, then often, not only are other people not going to remember what that measure is telling you, but we, the people building the solution, will forget. If we also forget to document it clearly and then we’re going in and reading through our code to figure out what the heck we did. So, keep it simple. It often pays off to just avoid the complexity. At a minimum, consider the value or the cost of the complexity before you undertake it.
The third thing I want to say is, just say what needs to be said. I feel like sometimes, in organizations, we’re stagnated by this fear of people either judging us or pointing fingers if things don’t go in the right direction. That keeps people from speaking up. I think it could be more productive if everybody felt free to consider this business your business, Or “his process your process. If you owned it, what would you do? What is the right thing to do? That’s really all that should be considered. It shouldn’t be, “If I get this wrong, this might be the last straw”. When you’re at that point, it’s difficult to make meaningful headway.
So there are three examples of how things can be difficult. It’s difficult to define clear business logic, people must work together (that can create some complexities as well), and then ultimately, we’re just going to make mistakes.
And then how to overcome these things? Don’t let perfection get in the way of progress. Secondly, keep it simple. And finally, if something needs to be said, just say it. It’s not saying that you need to be crude, that’s not the intention. Say the things that need to be said. Question things. Ask things in a professional way. If you’re a bystander talking about business logic for two weeks, then just go ahead and say, “Is this really worth it? We’re spending two weeks of five people’s time, should we really be doing this in order to optimize this thing that we have already identified the value? We’re diminishing the return by spending all this time on this. Should we go ahead and just decide to move forward?”
I hope this didn’t come as kind of a downer, that’s not the intention. Building a Reportopia solution is just so important. It really is when you think about things. One more thing, I think I’ve said this before, but if you believe that an organization’s success is dependent on the cumulative ability of everybody in that organization to make good decisions. I’m going to say that again. If you believe that, if you think that an organization being successful depends on everybody in that organization making good decisions. If we’re talking about a person at the point of sale, that person needs to make a good decision. It doesn’t take as much critical thinking to make a good decision in that case. Maybe in some cases it does. For example, the store manager might need to order the right inventory, and that person may not need to have as much leeway or may not have as much critical thinking required as the regional manager, but everybody in the organization has a role to play, If you believe that those people making good decisions is what’s going to lead to your success as an organization, then how important is it for those people to have the information and the insight that they need in order to make good decisions? It’s critical. And that’s what we’re talking about, building a solution that supports the entire organization so that the business can operate efficiently.
