A lot of people are involved in building reporting solutions, the Reportopia Team. I thought it would be good to talk about each of these roles and how they participate in building a solution. First, we want to focus on what I’m going to call the business roles. You have three different business roles: the business sponsor, process manager, and process worker.
So, first let’s talk about the business sponsor. This is the person or people, that have identified the need. They understand the value, of improving a process. It could be your executives in the organization, or it might be an individual contributor. It could be anybody within the organization that can identify a value opportunity. I use the words “value opportunity” to just describe broadly what we’re trying to do. We’re trying to increase revenue, reduce expenses, reduce risk. We’re trying to do something that adds value. The business sponsor, again, is this person that’s identified the value and it can be the person that’s acquiring funding for the overall solution.
The next business person is the process manager. This is the person that’s responsible for overseeing this function within the business that we’re trying to improve. This could be, if we’re talking about accounting, it could be the revenue cycle manager. If we’re talking about healthcare, it could be an operations manager or it could be a practice manager. It’s someone that’s overseeing this process we’re trying to improve. Now, this person is key because they could also be the business sponsor. It could be one and the same.
All of these roles that I’m about to describe are not necessarily different people. They’re roles, and oftentimes, there are people playing multiple roles. This is a common area where you will have the same person playing multiple roles. The business sponsor may also be the manager of the process that we’re trying to improve. This person, the process manager, is key because they understand the value opportunity from a day-to-day management basis. They know where these inefficiencies are, or they know where these opportunities are. They’re the person that’s going to be able to truly describe the business goal, which is going to drive the overall solution.
The third and final business person is going to be the process worker. Basically, we’re talking about the individual contributor. This is the person or people that are on a day-to-day basis working within this process to carry out the business’s role. For example, if we’re going to talk about a revenue cycle process, you might have a revenue cycle manager and there might be a few accountants within that department that are carrying out the day-to-day operations. These people are key in this overall solution’s success because just like the process manager, they understand the process as a whole and the inefficiencies and efficiencies within that process that we’re trying to improve. The workers or the individual contributors within that process are intimately familiar with these issues. Oftentimes, these are the people that are really feeling the pain. These are the people that are doing the day-to-day work and asking themselves, “Why are we doing this manually? We know we can automate this thing. Why are we doing this manually?” Or they’re asking themselves, “If I just had this bit of information, which I know is available out there, I could make this so much better.” These are the people, again, that feel the pain. They are really close to the value opportunity and they can often describe, at a very tactical level, the implication of improving the process.
These are the three main roles on what I’m going to call the business side of building a Reportopia solution. And again, it’s the business sponsor, the process manager, and the process workers.
Now, let’s talk about the implementation team. I have about eight roles for the implementation team. It’s not as if we have one individual for every role. Oftentimes, especially in small to mid-market companies, you might have one person doing all of these things. It’s possible to do that and it’s possible to succeed. But you have to be realistic about what we’re saying. You can’t have one person building something and testing their own code, as an example. That would not be as resilient of a process if you had multiple people involved to catch errors. So again, this could be one or more people, but I’m going to go through the various roles that are involved in implementation.
First, we have the Project Manager. This is pretty common. You have someone that’s going to understand, at a high level, all the things that are going on in building this solution. We’re often working on not one but two or three or many different value opportunities at the same time, and that requires a lot of coordination. You must know at which phase of the process, whether it’s in the business definition side or development side, etc. We got to know where everything is at any point in time. We must make sure everybody is communicating what’s going on. If there are any blockers, we need someone to raise those up and try to get them resolved. We got to make sure we’re staying within budget and timelines. So, the Project Manager is key here in making sure the overall project stays on track.
I don’t really like using the word project when it comes to building these solutions because, I’ve probably have said this before, but “project” kind of has this concept of begin and end. While there are various phases of building out these solutions, there’s no end. You’ve really got to look at Reportopia as a business function. As soon as we fulfill one value opportunity, well, what’s going to happen? That same process manager, that same process worker, is then going to see the result is much better. But now that they’ve done that, now they realize they can do other things. So, as soon as you improve something, you immediately, find additional opportunities. So, the word “project” is not my favorite but nevertheless, “Project Manager” is the role here.
The second role in the implementation team is the Business Analyst. I’ve seen Business Analysts take on all different sorts of descriptions. Generally speaking, the Business Analyst is going to be able to communicate with the business sponsor, the process manager, and the process workers. First, they figure out what the business need is, and then break that need down into its individual components. Then, we can know what it’s going to take to fulfill that need. Next, the Business Analyst needs to be able to relay that information to the development team so they can understand what the business requirements are and what it means to be successful. That’s a broad definition of a Business Analyst, but this person is key. They are the glue between the business and the development team. It’s important that you have someone that can not only understand something about a development process, but also understand something about the business that we’re trying to improve, and that’s the BA’s role.
Next, we have a role that takes on all kinds of names like “architect”. I’ve heard it called “data architect”. There are all kinds of names, but generally it’s some type of an architect level role. This person is going to oversee the entire solution architecture. This includes infrastructure. It includes all sorts of things, all the way down to development design patterns, the actual phases of development, and how we’re going to do testing. It also includes who’s going to do testing and what are the measurements we’re going to take in this process to make sure the process itself is being efficient. The architect’s role is the oversight of the entire solution.
Next, we’re going to have someone that is going to be a data source specialist. We’re building reports and that means we’re going to be pulling data out of some system of record. The system of record most often is going to be a business application, which has a database in the back end. It might be an Excel sheet that someone is maintaining manually. Whatever it is, you’ve got someone that’s going to become the specialist within that data source. When I say specialist, it doesn’t mean that this person is an expert in all things about that data source. They’re going to be the person that’s going to understand enough about that data source to know they were pulling the right data elements out of the source to fulfill the need. This is a key role, as you can imagine, especially when you’re talking about interfacing with ERP systems, large EHRs, or even some CRMs; there’s a lot of complexity. This person needs to be able to understand the data elements that are needed to support the reporting requirements, finding those data elements, and understand the behavior of the data source. Things like, how is the data source handling updates? Are they overriding data in place so there’s no history? Are they storing a log somewhere with the full history? There are all kinds of little things that this person must understand, because that information needs to go to the core development team so they can build something that caters to that source behavior.
Now we have the “data modeler”. The Data Modeler is in the pre-implementation and post-implementation phases of this process. First, the Data Modeler is going to have to understand, from the Business Analyst, what are the requirements. What type of analytics do we need to be able to support? Then that person is going to design a data structure that’s going to support those requirements. But that person also must keep in mind that we’re building a cohesive data structure. You’re building a foundation that you can extend without having to scrap and start over.
We’re not building point solutions and building another point solution that serves very particular needs. We’re trying to build this ecosystem that’s able to support the needs today, and when we have a need tomorrow. Maybe the need tomorrow is already supported without any additional development because we’ve built this thing in a way where we have a data structure that mimics the business that we’re trying to support. The Data Modelers are a critical piece of this process. All these roles are critical. If any of them fail, then you’re going to be at risk of not meeting the value opportunity that we’ve identified.
Let’s move on to the ETL Developer. ETL stands for extract, transform and load. This is the person that’s going to build the processes that collect information from your data sources and pull it into this data repository. It’s going to be built to support the reporting requirements. There’s a lot of different types of ETL Developers out there. You have everything from people that are going to write code one character at a time, to fully automated solutions where the ETL Developer isn’t writing much code at all. There are pros and cons to all these different approaches. If something is going to break in your process, it’s most likely going to be in this part of the process where data is coming from your data source and moving into the data structure, you’re trying to create to support requirements. And that’s because this person, the ETL Developer, must keep in mind not only that we need to support today’s requirements. We know today’s requirements. Not only to support today’s view of the data source, but this person also must keep in mind that both of those things are changing. As an example, your data source is going to be updated and that is possibly going to cause schema changes that can break the ETL process. So, your requirements are going to change. The ETL Developer must be building things in such a way that we can respond to changing needs, both in the data source and in business requirements. That’s not a small task.
Next, we have the Report Author. This is the person that’s going to author reports. They’re going to develop a report so that the end-user, the process manager, and the process workers, have the information they need to improve this process. This is a key role. It’s one thing to take data out of the data model that’s being created and just throw it onto a design surface of some kind into a table. That’s fine. That gets you from point A to point B. It’s a whole different thing when you try to lay out a report in such a way that it’s easy to consume for those process managers and process workers. That gets into everything from visualization selection to user experience, performance, and ad hoc abilities. There are all sorts of things that the Report Author is going to impact.
This person is usually tool-specific. This is where you’re talking about the front-end tool, or the business intelligence tools. This is where the Report Author is going to be an expert. Today, most of our clients are using Power BI. It is a great value proposition using Power BI. It has a huge set of functionalities being developed very rapidly, and it’s above others at the current time as far as front-end tools. In any case, the Report Author is often very tool-specific. They might be an expert in one or two different front-end tools, so we’ll have to keep that in mind when we’re selecting a Report Author.
Lastly in the implementation team, you have these QA Engineers or Test Engineers. These are the people that are going to test at various parts of this process. There are a lot of different phases. I’m not going to go through all of it, but you’re pulling data out of those data sources and you’re creating a new data structure. You want to make sure that that new data structure represents the information that came from the data source, because there are things that can happen. I mentioned a minute ago that it’s up to the data source specialist to understand the source system behavior. If that person made a mistake or if there just was no way for that person to truly understand the data source behavior without first testing it, the QA/Test Engineers are the people that need to be able to catch that sort of thing.
They need to make sure that the data in the data repository that’s being created matches the data source. They need to make sure that business rules are being implemented in the way that the Business Analyst specified. Ultimately, they must make sure that the report being developed and being provided to the process workers, is accurate. They need to make sure it performs well. These are the people that do some really important work. Without knowing if what we’re putting out there is accurate, it’s really going to diminish the value of the overall solution. So, the QA and Test Engineers are responsible for identifying any data validation type issues and raising that up to the Project Manager, so we get the steps in place to actually address those problems.
The next set of people, I’m going to call support people. We talked about the business people, we talked about the implementation team, now, we’re talking about the support team. This could be a super long list, but I just broke it down into a few very relevant types of roles.
First, you have someone that is responsible for the overall implementation. This depends on how the implementation is being done. Most small and mid-size organizations work with a third party, because it often doesn’t make sense to hire for all these roles. It wouldn’t make sense to hire three to five people if your company only has five people in total. That wouldn’t be a good financial decision. If you are using an outside vendor, you’re likely going to be working with a Practice Manager that oversees the overall implementation. If you have an in-house team, you’ll have someone that’s called the Director of Data Analytics, the VP of Business Intelligence, or something along those lines. This is the person that’s responsible for the overall implementation. You also have your Database Administrator (DBA). There are often processes that are going to involve various types of database technologies, and the DBA will be involved in this.
The infrastructure team is key. The infrastructure team is responsible for providing the infrastructure needed to do the implementation. This includes your bare-bones type technology folks such as people that are managing servers, managing storage arrays, or maybe managing any types of hosted solution like AWS or Azure. We use Azure at LeapFrogBI most of the time. Then you have security people as well, in the infrastructure team. It may be a totally separate team. The infrastructure team is important because if you don’t have the right infrastructure, or if you don’t have the right cooperation between the infrastructure team, the security team, and the implementation team, it can slow things down. It’s important that all people involved in this process understand what we’re trying to accomplish.
We’re trying to make our business successful by running it more efficiently, and we need everybody to come to the table and try to find solutions. It’s one thing to tell the implementation team that we don’t have any resources for you. So, they’re not going to be able to move forward. That’s just an example. Let’s say we found a $100,000 value opportunity, and we’re not going to be moving forward because the infrastructure team doesn’t have a budget to provision a new server, which might cost $5,000 in the year. It’s important that the Practice Manager, Director of Data Analytics, or whoever’s responsible for the overall solution, is driving this process. They are making sure that the infrastructure team knows they’re going to spend a little bit of money so they can make more money down the road.
Next we have a monitoring team. It doesn’t make sense to build a solution unless you’re going to monitor it because things are going to change. Your data source is going to change, the business process is going to change, you’re going to have infrastructure failures. Things are going to happen. If you’re not going to monitor these processes, and by monitor, I mean understand if they succeed or fail every time they’re executed; then you’re quickly going to be in a position where you don’t know if you can rely on them. As soon as you get in that position, the value of the solution is greatly diminished. People are just not going to be able to rely on those solutions so they’re not going to use it. It’s really that simple. Monitoring is super important.
You then have a support team, and you probably can imagine what this is. If the business has a question about the report, there needs to be someone that’s going to take that question. That might be in small implementations, that might be the Data Architect, or it might be the ETL Developer to answer those questions. Someone needs to be available to the business to answer questions about the report, to accept bug reports, or enhancement requests, etc.
Then we have trainers and spec writers. I’m going to group these together because oftentimes they are one and the same. The trainers, of course, are the people that are going to take some type of a report that was developed and deliver it to the business process manager or process workers and make sure they understand how to use it. They will make sure those people understand what was delivered, why it was delivered.
Remember, this all started based on the business sponsor identifying a value opportunity. We need to make sure the people that are receiving this report understand the value opportunity we’re trying to capture. They likely do. They’re likely painfully aware of it. They know how to use the tool that’s being given to them to capture that value. It can be that simple, but sometimes it’s quite complicated. Sometimes, when you look at business process management and how we’re going to improve different processes with reporting solutions, it can get deep quickly. The trainer’s role is to make sure that the business knows how to utilize the solution.
The spec writer is documenting this process. There are a lot of things that can be forgotten; not only forgotten, but hard to communicate. If you don’t write these things down, they’re going to be lost and you’re going to be in a bad position. I’ve been there, where someone asks you a question, maybe you’ve built this thing six months ago, and no one remembers the business rules that went into this process. That can diminish the value of the solution.
One thing I’ve started to do is put a page at the end of the report that lists the business rules. I call it the glossary page. If there are any exceptions that go into the report, I’ll put them in there. I’ll put things like the purpose of the report, the data source description, and the refresh interval. I’ll put that information in the glossary of the report, not only for the business’s benefit but for my own benefit. It’s just a quick little cheat sheet that tells me, in the future, what we did. It’s important to keep that current because if you just throw it out there one day and you start iterating on a report and you don’t maintain it, now you’ve got a different problem. That’s the problem with documentation, it is extremely difficult to keep current, but it can be done, and it is super important.
So, I’m not sure how many roles that was, more than a dozen, for sure. Maybe around 20 roles that we just went through. That is a lot. Once again, building a Reportopia solution is something that can be done with anywhere from one person to a team of a dozen people or more. It really depends on how much value there is to capture, how complex the situation is from a data source standpoint, and a business requirement standpoint, who’s available. It’s not easy if you go and try to find people that have these skills I’ve talked about, especially the hard tech skills. It’s not easy to find people that have deep experience in these various areas.
There’s a lot of variables that go into this as far as the number of actual people that are involved in the process, but nevertheless, all these roles are important. Even if you have one person doing all these roles, it’s important that person is doing all these roles. They are not forgetting about training, not forgetting about project management, and not forgetting about testing. All these things are super, super important.
