Hello and welcome to Love Your Reports. My name is Paul Felix. I’m your host. And this is episode number two. In this episode, we’re going to address probably the most common question that I get when talking to organizations that are considering building a reporting solution. And that is, how much does it cost? What’s it going to cost to reach this pinnacle of reporting that we call Reportopia? Now, I’m going to get into the details here of trying to determine what your cost is going to be. But before I do that, I want to mention that this is not like the Field of Dreams, where you build-it-and-they-will-come type of scenario. You don’t need a big leap of faith here to determine your return on investment. And that really is what people are thinking about when they ask about cost. They’re trying to determine, if I spend all this money, what’s it going to actually return me?
And to determine that, clearly you need to quantify the opportunity side of the equation. The opportunity is quantified in two ways. It’s either reduction in expenses or increase in revenue. That’s the bottom line. It is that cut and dry. You need to be able to say, before you move forward with building a reporting solution, that if you do build this reporting solution, “My return on investment is going to be X.” And to determine that, you need to have business processes identified that are going to be improved in such a way that they decrease expenses and/or increase revenue.
Now, I don’t want to make it sound like this is completely black and white. There are soft type scenarios here, such as risk reduction is a little more difficult to quantify. But you, in any case, you really do have to have, especially when you’re first getting started, you really need to have some pretty solid numbers that show that you’re going to have a positive ROI before you move forward. Okay, we’ll dive into that more in a future podcast, but in this podcast, we’re going to focus on the what-does-it-cost question. How do we determine what it’s going to cost to build this reporting solution?
Now, I want to start off by saying that there’s a lot of different schools of thought here about how you approach this question. Some organizations will suggest that they do an initial assessment and try to break down all of the things that need to be done, put dollar signs on all of those things and add them up to come up with a total cost. And I’ve been involved with companies that do that as well. And they have some success in giving you an initial cost of this investment. The problem with that though, is it really looks at this as a project, as if you’re going to build something. And when you’re done, you’re done.
Maybe there’s some residual maintenance costs in some of these plans, but generally speaking, they’re going to give you a number. And that feels pretty comfortable to say, “This thing is going to cost me $50,000 and that’s a cut and dry number.” But that’s not really the way this works. These are business processes. These are things that need to grow and change with your business. So because of that, when I quantify the cost side of the equation, I’m really looking at it as a monthly spend. And that’s how I’m going to try to describe this today.
Okay. So when you’re determining how much this thing is going to cost you, this is the way I approach that question. If you can visualize a matrix with a set of rows and columns, on your columns, we’re looking at the type of analysis that you want to do. How complicated, in other words, is the analysis that needs to be done? And by complexity, I’m saying is this very, very simple? Is it just something where we just need to take a data point that maybe is already even available in your existing business application and use it? Or is it something where we need to pull data together, and do different types of transformations, apply business logic, and then do projections? That would be a much more complicated scenario.
So one side of this is the complexity of the analysis that needs to be done. On the other side of this matrix, if you’re thinking about a set of rows here, is the complexity of your data sources. Again, if you have a business application, just one business application, that we’re going to use to build this reporting solution on. That business application is easy to access, it’s well designed, it just meets everything we need just right out of the box, well, then maybe there’s nothing else to do other than to use that business application’s data directly. But on the other side of things, if you have multiple business applications, if you have master data and dirty data problems that need to be resolved, if you have data integration issues, that makes a much more complicated scenario than a one-source, ready-to-go application.
So if you take these two components, which again are the complexity of the analysis that needs to be done, and on rows, the complexity of your data sources, that creates at the intersections. This is a description of what type of data solution needs to be created to support the analysis that we’re trying to generate. So the data solutions, which I’m going to focus on just very briefly here, but we’ll dive into this more in the future, the data solutions could range from anything, again, very simple, to very complicated. But let’s start with the very simple, and the way I typically describe this is in a data solution pyramid.
So if you think about a pyramid, on the very bottom of that pyramid is your system of record reporting. Your system of record reporting can be a couple of different things. It could be that your business application, whatever that is, it could be a CRM system, an ERP system, a policy admin system, a health record system, whatever you’re using to run your business. It likely already has some reporting in it. It may already have reporting built into that solution. So in some cases, we can just simply utilize that existing reporting that’s coming out of your business application. That’s a zero additional cost scenario. You’ve already got what you need and you can impact your business processes with what you have.
Now, also in the very bottom of the pyramid, which again, we’re calling system of record reporting, we could have a external reporting solution connected directly to your business application. So this could be something like Power BI, Tableau, or any of the reporting tools out there, reporting services, or even Excel connected to this thing. The point is the reporting solution is connected directly to your data source. There’s nothing in between. And that’s a system of record reporting solution. That type of solution could have pretty minimal cost, because again, all we’re really doing here is report authoring. We may have to do some minor manipulations and such, in the reporting solution directly, but they’re going to be pretty limited.
Now, moving up in complexity, both in analysis and data source topology, we end up getting to a point that we really can’t be successful by just having a direct system of record reporting scenario. And again, this is where you’re either using your business application reports directly, or you’re creating a reporting solution that’s tied directly to your source system. So I’m not going to get into all the details of the technical reasons why you would go into this type of a category of staging. But I will say this, oftentimes, your data sources are not designed to support reporting requirements. They simply don’t have the data structure required to support those requirements. And that means we have to put something in between the reporting solution and your business applications. And that data solution can take a number of different forms. The simplest of those is just a staging area.
You don’t want your reporting solution to compromise the performance of your business application. And that’s what’s often going to happen, once you start to put too much pressure on your business application due to reporting queries hitting that business application in real time. That’s what’s going to happen. It’s going to degrade the performance of your overall application. So to overcome that, and for other reasons, we create the staging area. Now, a staging area can be something as simple as just a replication of your business application data into a different repository. Or it could be something a little more complicated, where we’re not only staging data, but we’re also capturing the history of changes in that data.
Okay, so we’re at the second layer of the data solution pyramid. Again, the bottom layer is just your system of record reporting, where we’re going to connect a reporting solution directly to your business application or your data source. And then above that, we have this somewhat simple data structure, where we’re going to stage data, meaning we’re going to pull data out of your data source, and we’re going to somewhere. Now, in the staging area, as we move up this pyramid, we are going to increase cost. That’s really what we’re talking about here is, we’re moving from simple to a little more complicated. Now, we need to maintain a data structure. The cost may not be super high at this point. It’s not a very expensive thing to just replicate data, but it is increasing complexity. This does mean that we now have something else to maintain. So we don’t want to make that decision to move up the pyramid, unless we know we need to make that decision.
Now, the next step above staging is just your ODS, which is your operational data store. This can take many forms. And again, I’m not going into all of the technical details of what this is. I’m going to just say that once simply staging the data that comes out of your data source, whatever that might be, is insufficient, meaning that we can’t just stage data and then report on that staging data. We need to do something else in the data structure, meaning we need to prepare that data in some way. We need to apply some business rule. We need to transform it. We need to integrate some other source that’s not natively integrated in your data sources. That’s where your ODS, or your operational data store, comes in. And I’d say that when you’re talking to implementers, the word ODS can take all different sorts of forms, so I just generically say that the ODS is something beyond staging and something before you get into a data warehouse.
And the data warehouse is the next level in this data solution pyramid. So once again, just backtracking, we started off with just reporting directly on our business applications. And that could be reporting built into your business application. It could be reporting tied to the business application directly. Once that’s insufficient, we then move into a staging data solution, where we’re just replicating data from point A to point B, maybe persisting it. And once that becomes insufficient and we need to apply business rules in some way, that’s where we get into the operational data store, ODS. And once that becomes insufficient, then we look at a data warehouse. Now, a data warehouse is a another topic, of course, but a data warehouse is a data structure that’s designed specifically to support your business.
It’s not an ad hoc data structure. There’s very well defined techniques in building these solutions. There’s particular data modeling techniques that we’re going to use. And in the end, when you have a data warehouse, you have something that really should speak directly to your business. It should be built in a way that your business owners should be able to go into your reporting solution and really just build a report themselves. It shouldn’t require a lot of technical knowhow in order for these business users to get the information they need out of the data warehouse. And that’s because the data warehouse will represent your business. It’s built in dimensions, in fact, which again is beyond this particular episode. But I will say that when your business user goes into the reporting solution and they’re connected to a data warehouse, they should have a very clear list of object.
If we’re talking about insurance, you should have a dimension that lists your policies, a dimension that describes your insureds, a dimension that describes your producers and so on. You should have facts that describe the premiums, and the commissions, and so on. So it’s structures that are using terms common to your business users, which is going to enable them to self-serve their own reporting needs, in a lot of cases. We also would have canned reports that are pre-built for very particular and focused needs when you’re using a data warehouse. But it also adds a lot to the value equation when you enable your users to self-serve.
Now, the only thing that I include beyond the data warehouse is artificial intelligence, which is kind of beyond the scope of what we’re talking about here today. But once you have reached the point where you’ve, I would say, met all of your basic needs for reporting, and you’ve captured all this opportunity, the next step is to start thinking about, how can I actually do even better through predictive or models, algorithms? Things beyond just looking at what has happened or trending what’s happened in basic regressions, but using that information to determine, what can we actually do here to predict what might happen in the future? So that’s the AI side of the data structures, which could take many forms.
Okay. So to recap here, when we’re looking at the cost side of the equation, the cost is going to be determined by the intersection of your analysis complexity and your data source complexity. The data solution that’s required to support these systems is really where a lot of the cost is going to lie. And the data solution pyramid is what we use to determine what type of solution you need. All right, let’s break down the expense side of the equation, into the things we’re actually going to need to spend money on.
Number one, and the biggest expense, is going to be labor. This is the people involved with building these solutions. Number two is infrastructure. That’s the hardware, the actual compute resources, the bandwidth, all of the things you need, the disks, all of those things you need to actually implement this solution. And then number three is software. So you need to have some type of a operating system you’re running on. You’ve got to have all of the tools and such that you need to build these things. So all those software costs as well.
Now, the infrastructure and the software are really not significant costs at this point. If you do this smartly, there’s a lot of ways of reducing your cost given the cloud computing options we have today. Just to throw some numbers out here. Some of these solutions that we build today that are really small, limited type solutions, even data warehouse solutions, are costing, for the infrastructure and software cost, they can be as low as just a couple hundred dollars a month. Which is extremely low compared to what the cost might have been just recently, when we were trying to host all these things in our own data center. Now, it’s not like you can get that low of a cost if you just go out and start provisioning resources in the cloud. There are things you need to know. You got to be able to use automation to really take advantage of using resources only when you need them. But it’s certainly possible and we do it today.
So on the labor side of things, which is by and large, where nearly all of the cost is going to be here, you have a number of different roles that you need to fulfill. Now, these roles might all be fulfilled by one person. And these roles might be fulfilled by someone internal to your organization, someone in your team directly or it might be filled by an external organization. Either way can work, but you do need someone or some team of people that have these skills in order to be successful. So let me run through these. First of all, you have a business analyst. This is the person that bridges the gap between what the business requirements are, helping identify those requirements, helping identify the opportunity, and the technical implementation of this solution. This person is going to interface with your business user and translate that information into a technical implementation. Something that a developer can pick up and build.
Then you have the actual ETL developer, or extract, transform, and load developer. This is the person that’s going to move data from your data source, or data sources, into a data solution. Then next up is your data architect and/or your data modeler. The data architect is responsible for the overall architecture. The data modeler is responsible for building or designing the model that we’re actually building. We’ll get into modeling and such in future episodes from a business perspective. But for now, we’ll just say that it is the foundation of everything you’re building. It is what’s going to enable this solution to not just be a very point solution that’s going to serve a very focused need, instead, it’s going to be the foundation, something that you can build on from now until eternity.
Then you have your QA and your testing engineers, people that are going to make sure that what we’re building is actually accurate. Your report authors, those are the folks that are going to take data out of whatever data structure we’re using and actually author a report. They’re going to lay out the data visualizations in a way that your business users actually get the information they need. And you might also have project managers. So there’s a number of different roles. There’s more than this, as well, but those are the key roles. You need someone or some team that has all of these skills in order to be successful here.
Okay. So we talked about a number of things already here. We started out just pointing out that we’ve got to have a positive ROI calculation in order to move forward with a reporting solution. We talked about the types of complexity that actually drive cost, your analysis needs and your data source complexity being the primary two. And then we broke down the actual spend and the main categories, with labor being the largest of the categories. So now, let’s talk about the actual cost here. First of all, if you’re building this solution in-house, then what is your cost going to be? And on the lowest side of the equation, your cost is zero. If your existing software solutions have reporting capabilities that you already have at your disposal, then there’s no additional spend required to build a reporting solution. But anything beyond that is going to have some spend associated with it and you’re going to have to allocate somebody to do this thing.
It may be smaller organizations might just have someone doing this as part of their job, pulling reports together as part of their job. So it could be just a small number or half of a resources cost, which might be a pretty low cost to you. If you’re trying to build a reporting solution, though, that’s something other than system of record direct reporting, you then really need all of these components in place. And to give you an idea of what a person might cost to do these things, if you’re lucky enough to find the one person type that can actually build this solution for you, that person’s going to be north of a hundred thousand dollars a year in most markets. And you really are going to need at least a few resources to do this right.
First of all, you don’t want to put all of your eggs in one basket here, where if one person leaves, well, you’re left high and dry. No one else knows how to deal with this thing. But it’s very uncommon that you’re going to find that one person that really has all of the skills that you need. And even if they do, is that one person going to have enough time in the day to actually build this thing for you? So if you’re looking at building this thing in-house, you’re looking at anywhere from $0 to the cost associated with anywhere from one person to a team of people, plus the infrastructure required, it can easily be a 500,000 a year, maybe a million plus a year investment for you. That’s not something that most small and mid-sized organizations are going to want to take on, frankly. And rightfully so. You may not have enough opportunity to warrant that cost. You might, but you might not.
So it’s really important again, to look at, what opportunity are we trying to capture here? If you have an opportunity that’s only $50,000 a year, well, it doesn’t make sense to spend a million a year on building a solution. That’s kind of a no brainer. But if you have an opportunity that’s millions a year, well, maybe it does make sense to take that on and build that internal team. Now, I work for LeapFrogBI, as I’ve mentioned before, and this is what we do. First of all, this is not a sales podcast. I’m not trying to sell our services, but it is important that I give you some understanding of the alternatives when it comes to cost. So our lowest cost offering is 1,950 a month. And that actually is enough to actually deliver a solution for some of the clients that we have that have very simple needs.
Oftentimes, it’s just system of record reporting, where you have again, a reporting system that’s directly connected to your data source. And you got a very simple data source structure. Well, a solution that’s that cheap, less than 2,000 a month, can actually get the job done. So that’s kind of the lowest end of the cost equation, is 1,950 a month for us. But more commonly, we’re seeing clients on the spend level somewhere around 5,000 a month is where most clients end up. Now, one thing that’s important to mention when you’re working with a company like LeapFrogBI or any other firm, hopefully, that you’re deciding to work with is that the spend per a month is not fixed, meaning you spend as much as you want to each month.
If you find that up front you need to have a pretty significant spend, maybe 5,000 or 10,000 a month for the first few months so you can kind of get things off the ground, and then you decide, okay, well, we have what we need now on these particular opportunities. We’re capturing them. Let’s slow down on the spend and kind of let this burn in, if you will. And then as you do that, your spend is reduced. If you’re working with LeapFrogBI at least, that’s the way it works. We bill you for whatever services we offer each month. So that’s another advantage of working with a company that’s focused on only this one need, which is building your Reportopia.
Okay, I’m going to leave it there for this podcast. If any of you want to contact me, I’m more than happy to answer questions or take comments. Paul@loveyourreports.com is my address. You can find me on Twitter at paulbfelix, as well. I wish you all the best. Talk to you next Tuesday. Happy reporting.
