Setting up Reporting Dashboards: 4 Costly Errors by Your SAP Implementation Consultants You Wish You Knew Earlier

[00:00] Krutarth Kosambi:

All right, so four costly errors. That generally people, you know, go through during SAP implementation. The first thing I want to start with is the fact that how is it different? How are the reports and a dashboard different? At the same time, how is it different from a scorecard, right? I mean, your report is something which looks at what is on the left. It’s a tabular format. I mean, you kind of have to look at it to find a specific number or to find what’s going on.

[00:40] Krutarth Kosambi:

A scorecard is more about, you know, what you did monthly or what you did yearly and how you are doing against either what’s budgeted, what’s a plan, or how you’re doing against the industry. Right. The way a dashboard is different from a report or a scorecard is that the dashboard is something that is used for monitoring. Right. It has real-time data. And what it does is within a few seconds, like within five or 10 seconds, if you look at a dashboard, you should be able to take some kind of a decision, right? So it’s very important that your dashboard is showing you KPIs correct or anything like that, which is going to be actionable to you.

[01:30] Krutarth Kosambi:

Right? One of the other things which dashboard I think should have is the number of visuals of the number of visuals increase. You know, I mean, after six or eight visuals, if you have more than that, then it’s very cumbersome to look at. There’s you know, it will take more than ten-fifteen seconds. So it needs to be somewhere between six to eight key indicators or metrics and something that is actionable. Right. We go back to history, right, and how automation and how. You know, two big retail industries back then and how we’re just transformed right now.

[02:16] Krutarth Kosambi:

Years back in the early 90s. Used to have had a lot of manual paperwork. And, you know, if those sales, these stores will collect whatever got sold, it would then pass it on to a regional hub. From the regional hub, it would go to the corporate. They would find mistakes. It would go back and forth. It would probably take a good amount of time, probably a few weeks to really see what’s happening. Walmart in the early 90s, and I guess this was before even before 1990 where it launched a geostationary satellite.

[02:57] Krutarth Kosambi:

And what really happened is that they transformed how they were doing things. Everything was in real-time. They knew what was being sold, where if there was some important communication if there was an announcement if there was training, I mean, they had a way to communicate it really fast. The executive team out there was able to make quick decisions because they have real-time data. They don’t need to wait for 15 days or 20 days for the report to show up. And at that point, it might be too late depending on what kind of economic conditions you are in. So this is the favorite slide on these PowerPoint presentations. We might have seen that there are a lot of dashboards out there, maybe even in your company where there are pretty looking graphs and indicators and everything. But then when you ask someone, you ask the employees, you know, I mean, there is no actionable thing, or there’s nothing where the person feels connected to, and this becomes a real problem.

[04:10] Krutarth Kosambi:

So, again, right. I mean, as I said, the dashboard is something that needs to be actionable, and we need to make sure who is looking at it. Today’s agenda, in a way, is pretty straightforward. First, we are going to look at what is the impact of bad analytics right, and bad analytics usually comes from you having bad data. The second thing is that I will go to the assembly line. It is the stages that generally and SFP implementation or any kind of implementation goes through their different stages and at different stages what the mistakes are, right? What are the errors that we make while we go and create this dashboard? Lastly, we look at why is it important to have had a good dashboard right now and how it connects to how it would be in the future, right? So let’s hop on to bad analytics on business. Right. If those bad analytics, if there is bad data, I mean, there’s so much money that is being spent, right.

[05:23] Krutarth Kosambi:

I mean, you would know how different resources working on the same thing. There are reconciliations here, and you would have an external auditor asking a thousand questions, probably being there weeks more than they should be. On bad data, if you make a decision on bad analytics, if you make a decision, your decision is most probably wrong. And by the time you realize it, you would be, you would already be a few months into the game, and it would be really hard to change it back to what it was before. There will obviously be degrees in growth or the plan that you how for yourself in the future. At the same time, you create unwanted copies. And I guess everyone here would agree that you will have a report where there are ten copies for ten different departments using probably the same information. I was working at a big client, and it seems that they had twelve hundred reports at that point. Twelve hundred reports being used.

[06:29] Krutarth Kosambi:

Then the new executive team that came up kind of said that, hey, there are too many copies, too many emails going back and forth to different departments, giving two different recommendations on the same thing. So they reduced it to 30, and they are like, we are going to put it on the SharePoint. It’s going to be these 30 monster reports, and whatever department needs to go there, fetch that data, and then they need to filter out or change the data according to the way they want it. So from twelve hundred to thirty I mean it’s space, it’s time, it’s reconciliation, it’s everything that affects. At the same time, if, since we are in order to cash right at the later part when you receive cash if there are deductions and there are short payments, disputes become a huge problem. Disputes become a huge problem. Collections become a huge problem. So if the data is not correct, it no matter what, I mean, it might be a sales order which had a wrong payment term.

[07:34] Krutarth Kosambi:

It then kind of flows like seven or eight steps from there to delivery to billing to invoicing to payment to deduction to your team working on credit and collections. And at that point, you know, I mean, it is like seven or eight stages down where you know that something is wrong and maybe the customer is not happy with it. So we’re going to go through the assembly line on that assembly line, which is not just used for dashboards that can be used for other SAP implementation as well, for reports or for even small or big projects right. The assembly line is kind of pretty simple. The first part is the ideal thing, right? So that is where you conceptualize what you want, why you want it. Right. If you do get what you want and if you see it, what kind of actions will you take? I mean, once it is there. A lot of times we do see that we want this, we want this, we want this.

[08:46] Krutarth Kosambi:

Everything is there. But then when it’s up on a dashboard, the dashboard stays there for like six months. And after six months, if we ask that, “Hey, you know, is anyone looking on that dashboard?”. Then probably there is no one who is looking at it. So we’ll start with that phase idea thing. Right? And if no, first thing is that you define a scope, as I said before, our dashboard is something where you’re monitoring, and it needs to be actionable.

[09:15] Krutarth Kosambi:

Right. So if you see trouble, you should be able to make a change. But just by looking at it. So defining scope is very important. There are different kinds of dashboards, and depending on what kind of dashboard and who it’s targeted to, it’s different. So in my example, I’m saying that there are strategic dashboards where it would be these executive teams using that particular dashboard, right? And what is in it needs to be specific to the executive team.

[09:49] Krutarth Kosambi:

Right. If you if he was trying to put some KPI, is at some metrics which also would help a business analyst or which would help your financial analyst, then maybe it’s not that dashboard. It’s a different dashboard. We have operational dashboards, mostly for managers, departmental people. And then we have an analytics dashboard, which is mainly used by your analyst, by your specialist. The number one problem with the dashboard is that there is no definite scope, and by that what I mean is we decide on eight indicators, right? And then some other department which is related to it will come up and say that- Oh, we want to see this too as well. There will be another department which will say, “Hey, you know, I mean, can you add the other two indicators as well?” When we do that right. I mean, the scope keeps on changing, which is not good. At the same time, it’s not actionable now, right. I mean, you want to look at specific indicators which on which you either as a manager or as an analyst or as an executive member want to make a decision on that part. So there’s no point in, you know, reducing the importance of what you are looking at or making it complicated and spending more time just looking and drilling down on numbers.

[11:19] Krutarth Kosambi:

And we had this example just before a year where everything came up as a priority that we wanted a DSO report, no matter what. Through different segments, through different customer risk classes. And we created that report. I mean, the resources were pulled out from other projects. We completed this. And at the same time, it didn’t add as much value as it would have. Right? An example here is the DSO is 90 days, like what does that tell you? I mean, you kind of need to know, for example, the other metrics like ADD or collection index or collections effectiveness index along with it. When you look at it along with it or when you look at your payment terms, you kind of then know that. You know, I mean, is this a good number or not a good number? If you’re just average it out, it’s just a number out there. Maybe you’re reporting out of it. But then again, you know, I mean, there’s no action to it. There is no change, which you’re willing to make just by looking at the number.

[12:37] Krutarth Kosambi:

So the first thing ideating it had the problem of scope, right? And as I said, you know what scope it’s departmentally you kind of need to isolate it. This is the only thing I’m looking for. Not entertain other departments or other requests of which would come in and just clutter your dashboard. The second part we move on to is planning. Right. And this space between I mean, there are two parts to it, right? I mean, one is defining the ownership of the dashboard. So who is going to be the owner if it’s if you’re making it for the executive team? Obviously, it’s at a very high level. It’s company-wide indicators. At the same time, if you’re making it for a manager or a business analyst of our particular department, your KPI, change, your metrics, changes the way it looks might also change. It might be a little more detailed on the dashboards are created towards you know for managers or for deep business analysts, whereas if it’s the executive team, it’s really at a high level. And, you know, I mean, you do need to make sure that who is going to be the owner of it. Now, there are two things to it. One is that. And I’ll go to the next slide right. There are two things to it, right? I mean, one is that who is going to be the end viewer and who is going to be the owner? And by that, I’ve seen a lot of times where let’s say a manager is an end-user of the dashboard right.

[14:14] Krutarth Kosambi:

He is the person who is who’s looking at everything. But your company changes every now and then. You have transports going on. You have changes going on every probably every week, every month. Within six months that report or that dashboards need to make sure that whatever is the data, whatever is the calculations, whatever is the filters, do take those things into account. It might be a new sales order type. It might be a new company or whatever, whatever new dimensions you added or whatever changes you added, we need to make sure that that is reflected. Now, that can be a different person. So it can be that the ownership of the data and making sure that the dashboards are correct is something that an analyst looks at. But at the same time, the end viewer is going to be your manager or your executive team. Now, the third issue is understanding data and its source, right? So when we say understanding data and its source right, one of the issues is that if you have different systems and if you’re trying to create a dashboard where you have inputs from different systems, that there are so many companies out there which probably have, you know, I mean, all kinds of system, all kind of names that you have heard.

[15:42] Krutarth Kosambi:

And that creates an issue because there is generally a single data repository where all the data would flow. It would either be like a nightly job or, you know, there would be specific times when data comes in from different systems. And it is either, you know, I mean extracted by ETL or BI team, which is then read with the calculations, with the filters that are on and feeds into a dashboard. So we do have to make sure that the data is always evaluated and we make sure whatever timings of those jobs, of making sure that if within our dashboard there are six or seven different visuals, we do want to make sure that they all match and they possibly are real-time.

[16:36] Krutarth Kosambi:

It can be that few of them are not real-time and that’s fine. I mean, it just depends on what kind of KPI or what kind of metrics you’re going to use. But it is important to make sure that the person who is looking at it knows. One of the other things and one of the other issues, but is more on the technical side. And I don’t know how many of you are technical here. Sometimes, a request comes in saying that, “Hey, you know, I mean, will pick and choose.” So there are eight indicators which we have agreed to, but then we are like, hey, you know, I mean, let’s put 20. We need all the calculations for those 20 indicators, we will pick and choose which ones we want to show on the dashboard. That is that it is not right.

[17:20] Krutarth Kosambi:

The reason being that behind the scenes, there are so many data extractions that need to happen, and you’re pulling things from different systems or even from the same system. There are a number of fields. What it does is then it starts to create an issue with your load time. It starts to create an issue with your job timings running more than it should be. So many times we come in the morning, and we would hear the IT say that nightly job failed, the nightly job had issues, or it overran whatever period of time it should have run and created issues with other dependent jobs that run the whole day. So again, you’re right. I mean, the relevancy of feed data and source are two important points. If you have different systems of your using different systems, you know, you make sure that you extracted at a time which is giving you the correct results. And at the same time, if you are extracting data to make sure that there are not like 50 different possibilities and you would pick and choose, it kind of goes back to not having a good scope, right? And a good scope is something that you already know what you want to see. And you should be able to visualize that. If I do get those eight indicators and if one of them is, you know, on the lower side or a higher side, what are the actions you’re going to take? So that is something that is important. And you need to think about that and the first part, right? We go on to phase three. Phase three is the development part. So your scope is something that starts with the business. So the business already knows what is happening, what is not happening or what other different scenarios. What I want to see why I want to see it. And if I see it, what’s the action that I will take?

[19:27] Krutarth Kosambi:

Developing is more when you would pull in the IT resources, or you’ll pull in the dashboard consultants or SAP consultants. And this is where your remembrance gathering will start. A big issue that I see with requirements gathering is that during requirements gathering, instead of requirements gathering, it’s the scope that is being discussed. That is, first of all, not a good start. If you do want to make sure that you know, you have the scope, and you have planned it out, you know who the resources are going to be, what is going to be the estimated time. If you want to capitalize on the project or you know, I mean, things like that need to happen first. If you are on the table where its requirements are gathering, you already know what you want. Most of the time, that is not the case. We would be in a meeting, and then there would be discussions on what is needed. What is not needed? People would change things. Different persons would need different things. So let’s make sure that you know the ideating, and the planning phase is complete before we go to the phased implementation.

[20:41] Krutarth Kosambi:

So the first part is obviously requirements gathering. The second is how you wanted to look, right. What are the capabilities within that? If you wanted to dig down deeper, how are you going to do it? What is it going to look like then? Coding, design, security. You sometimes don’t want your metrics or KPI to be shown to employees. The reason obviously being that, let’s say, for example, you know, I mean, some of the indicators are related to bonuses or commissions, and it might demotivate people, or you don’t want them to see something because you are in between acquisition or merger. There might be reasons for it, making sure who has access to it. What’s the design? What’s the coding? And the last part is obviously, you know, I mean, you test. You’re probably satisfied 90 percent. You give feedback if there is a possibility of making any changes or not. If it’s not faced, the problem is that a lot of times something is decided at the start. The developer starts to code it. The coding is halfway done. And at that point in time, we have to go back because the scope changed, the scope changed, or the requirements changed, and you just keep going back to it again. Adding a line, adding pressure to whatever timeline, and whatever resources you have for that dashboard. So fewer iterations, we make sure what we want beforehand and try not to change it. At the same time, if there are ad hoc requirements after half of the project is done or half of the development is done, most of the times if it’s not something simple, it’s just a filter or whatever, the developer has to go back and start from scratch.

[22:32] Krutarth Kosambi:

So again, that would increase the timeline, which would make everyone go back to the drawing table. The last thing I think, and this is very important, is the collaboration between IT and business. If we have a definite scope if we help planed properly and the slide, which I showed, which showed the phased implementation, if we go through that, then the collaboration between IT and business automatically becomes a kind of seamless. But if that is not done, then there isn’t.

[23:06] Krutarth Kosambi:

There is a lot of miscommunication that goes on later on. So it is imperative that business and IT come together and work together to create that perfect dashboard that we are looking for. So we are done with the four errors, right. I mean, we saw that there is an issue with scope. There is an issue with data and its source, the end-user, or the ownership of the dashboard. And lastly, if it’s a phased implementation and if it is going in that particular manner, are not right. I mean, those are the four things. The reason why we want to perfect this is because of the future, right? And not just the future obviously, I mean, it will give you a lot of information if you have a correct dashboard if you have a nice dashboard.

[23:58] Krutarth Kosambi:

But what does the future look like? Right now, most of the people have a generic dashboard, right? And what I mean by that is they are alert. So it may show you some kind of problem. If there is a performance issue within the system, depending on what kind of dashboard you have. There is a root cause analysis. Let’s say that you are in a dispute case. You have your root cause. You have your reason code analysis, a dashboard being presented. A lot of it is manual, right? I mean, you still have to dig down and look at what’s happening, what’s not happening. Even if it’s customer evaluation, your generic dashboard might probably show you what the problem customers are. But still, there is a lot of manual investigation that needs to happen on why something has shown up. So this is a dashboard, but generally, people use today, right? So to me, this is more like descriptive analytics, right? I mean, it’s a summary of what has already happened. And you kind of see those numbers, you see those ratios, you’ll see those KPIs. Now what we shift from generic to AI. And we hear this a lot. I mean, AI, machine learning, and the shift that is going to happen now are going to be that there is an alert validation or there’s an alert that showed up. But now the system is going to tell you if it’s worth it to go behind it and research what’s happening or not, right? So if it’s really worthy of your attention or not, is something with the system will tell you. Predictive analysis, again, right? It is something rare where it is predicted, and even before it happened. An example would be that some customers, D&B rating, credit rating have been going down consistently. And it would it will tell you a prediction can be that, you know, I mean, at this point in time, you are on this date, you are most probably to receive a check from a customer.

[26:07] Krutarth Kosambi:

Same thing with customer evaluation. It will tell you your problem customers at the same time, it would make it would also give you an action plan on what needs to happen or where the problem is. So we are at the descriptive analytics, right? I mean, so this is what has already happened. The diagnostic analysis is, and I don’t know how many of you use SAP. There is a collections worklist, right? I mean, what it does is you have all these different collection customers, and it tries to prioritize depending on what rules you have. Right. So obviously, diagnostic analytics is something where it shows you who do you need to contact first. I mean, your action plan.

[26:54] Krutarth Kosambi:

Predictive analytics. As I said, right in the last slide, predictive analytics is something where the system becomes intelligent enough to predict what’s going to happen, right? So if its credit risk, if it’s a customer who is going to default, if it’s cash flow that’s going to come upon a particular day, it’s going to predict that for you. The prescriptive analysis is where so, I mean, this is D to P to right. Prescriptive analytics is something that we will be in the next three to five years, where the system or the dashboard is now making a recommendation to take action. An example would be that a customer is having financial issues. And it can tell you that, “Hey, you know, I mean, not only will you look at the graphs, not only will you look at the visualizations on what’s happening, but the same time the system is going to recommend you back, saying that go ahead and, you know, block the customer or block the block sales orders until and unless you receive a payment”.

[28:02] Krutarth Kosambi:

You know, I mean, once you receive a payment, it’s going to ask you to remove the block, or it might be automated enough so that the system takes care of it every day and probably gives you a log. So this is a timeline. I mean, we already are into descriptive analytics and diagnostic analytics. We do see now a lot of dashboards, a lot of predictive analytics where they can tell us what’s going to happen.

[28:29] Krutarth Kosambi:

What’s a possible date? What’s the possible amount? What’re the possible scenarios? And lastly, as I said, right in three to five years from now, we’ll be at a position where due to machine learning, due to AI, it’s going to be prescriptive. And this is where the system is not just going to tell you no, it’s also going to tell you an action plan of what needs to happen. So with that, I am done, and thanks, everyone.

[28:59] Krutarth Kosambi:

Thank you.