Skip to Content

BI and ESA driven approach to SAP project implementations – Part 1

A trip down memory lane… 

So, you walk into your SAP project assignment that just kicked off a month ago as the BW consultant a.k.a the “Reporting dude”. Eager to start off – you ask around for “Reporting Requirements”.  Here are some of the better responses you get. 

  1. Functional Consultant for Sales and Distribution – “Reporting comes much later; Now I am busy trying to get the baseline order to cash process working. Come back in 2 months.”
  2. The client manager in charge of legacy reporting – “Here are all the reports in our system now. We run about 143 of them, but I am sure we can easily cut off about 25 old ones. “
  3. BW guy who joined the project a month before you – ‘ I activated a bunch of stuff in business content. We are ready to rock and roll whenever those SD and FI guys are done with their stuff”.
  4. BPS or IP consultant – “Stay out of my area, buddy. I have a BW background. I will give you my cube details when I am done and then you can play with it all you want”.
  5. Project Manager– “ whatever you do, make sure that the management dashboards work well. The CFO just told me that they are waiting for this project to complete, to get all the information she needs to be available at her finger tips”.

 Great start – you start to wonder if you would rather not have spoken to anybody, and just got into the next plane back home.  The thought of the next mortgage payment kicks in, and you decide to continue with the project and do the best job possible, given the circumstances. After all, this is only your eighth project that is going through this – you are sure the rest of the SAP projects in this world are all better, and maybe the ninth time will be a charm. 

You divide the existing reports (less the 25 that the legacy guy said can be killed), amongst the three BW consultants, and try to find corresponding business content. Every now and then, you go to the functional consultants to ask “What in SAP is the equivalent of miscellaneous sales?” and “tell me again whether it is the SD guy or the FI guy who will tell me about account receivables report”.  

Life is not so bad after all – the other BW guy was probably right. When the SD guy finished his order to cash process, you did have all the extractors ready to pull this information into BW and a pretty Bex report to display it. The client VP who saw the report is impressed. He says ‘Wow – now, if only I could see sales and delivery side by side”.  No problem – you build a multi-provider for sales and delivery cubes and voila – next day you show him his favorite “side by side” report. The VP just stops short of hugging you. 

 He says “oh now – how do I decide on the selection screen itself I want to see only sales figures , and not delivery figures”. Without missing a beat, you say “No problem, sir– you can hide any column in the display”. “Well, that is not what I meant – I want to choose what I want before the report runs”. Now that is a challenge – you need to think about it, and the VP is ok if you come back later with a solution; except that he planned to be out on vacation for the next 4 weeks. He suggests that you talk to one of his direct reports while he is away. 

This direct report is very good to you too– except that he looks at your report and says “ We need to know the sales and deliveries split by geographies”. The VP never mentioned this, and the business content has no geography. No problem – we can always extend it. One small problem here though. The SD guy has nothing called ‘Geography’ anywhere on his sales transactions. Nobody ever asked him to put it there. He is a nice guy though – he looked up the legacy system and figured out that there was a “behind the scenes” lookup logic that provided this information in the legacy system. You have a great ABAP person in the team – he can change the conversion program that loads legacy data into SAP, and also code a user exit to get it into sales transactions in SAP. Problem solved ! 

The BPS guy delivers his cube as promised. You have several reports that need to compare “plan vs. actual data” in marketing. You try to build a multi-provider and realize that the plan cube in BPS has more fields than the actuals cube that you built in BI. Assuming that there is some good reason for this – you go right ahead and build that multi-provider anyways. For consistency sake, you add the remaining fields to the actuals cube.  

The report looks good – you are pretty pleased, and go back to review it with the marketing manager. The marketing manager is blown away at the sight of this new report. His confusion is only on one aspect – he budgets by “marketing segment”, and is very happy with the new BPS functionality that lets him do that. But the report in front of him has only values for budget for each segment, and no values for actual spends against segments. This does not surprise you one bit – because you know this is not part of the extractor from CRM, and you know the CRM guys don’t capture it at all in their transactions.  

The marketing manager pulls up his tracking spreadsheet and shows you that it correctly compared budgeted and actual spends for all segments.  Of course he wants it to be the same in the new BI report. You reckon there is some fancy apportioning rule in Excel that is doing this. But it is too late to change your ETL and data model now. To make matters worse – there is that BPS guy with that smug look. 

It is time to make some hard decisions – you go to the project manager with a list of problems. Together, you take the decision to move some of this into the next phase. The only one which you have to deliver, no matter what, is the dashboard for the CFO. 

The PM takes you to meet the CFO. Contrary to your fears, the CFO is a kind lady, and puts you at ease immediately. She wants to see everything that the Vice presidents see, but in an aggregated fashion with the ability to drill down to lower levels if she chooses to. What could be simpler? You commit that it will be done. She also introduces you to the finance manager who manually creates her monthly dashboard in excel. You are relieved to learn that he uses the legacy system reports as the source for his dashboard preparation.  

You have all the dashboard details in front of you, and feel confident that you can pull this off. As you go forward with the design, you realize that not all data will come from SAP systems. What is the big deal – BW can get data from anywhere, right? So you have a chat with the legacy reporting manager. Since it is a CFO level report, he immediately agrees to get a file created with legacy data in the format you need. Bingo – the dashboard is done. 

You load data from SAP and non SAP sources into your cubes, fire up Bex and stare hard at the report. You don’t believe your eyes – it looks out of whack, and to your absolute horror –you find out that the master data in legacy systems do not always match the master data in SAP, and now you have multiple representations of each customer in BI. You realize that the CFO’s dashboard worked only because all data came from one source in the legacy system and that the finance manager manipulated it to make it all pretty.  

Now you badly need that vacation that you’ve postponed twice already– you can’t take it anymore. Gritting your teeth, you somehow manage to write some complex transformation logic to make it all work. You now have a report that seems to work – but no one, including you, knows whether this will actually work correctly every month after the project goes live. 

Finally, the project goes live. Most of your reports seem to work – even better, a lot of client managers love your reports so much that they commission a second phase for  BI to build an enterprise wide reporting system, along with migrating even more functionality from the legacy system to SAP. The CFO dashboard still does not tally automatically – so you have to do some tweaking every month (behind the scenes) to make sure it tallied. The VP, who asked for a selection of key figures before he runs the report, still has not got what he wanted.  

You really don’t want to be associated with the second phase of this project. The data model looks like an awful mess – you no longer know for sure how many objects existed and what they did. There are several cubes that held variants of the same information. You had to create several roles in the system to organize the reports and satisfy security concerns. You want to run as far away from this, before the client awards the second phase, along with the maintenance of the already live project to your company. The only problem (apart from mortgage payments, that is) is that the only person who has any idea of the current implementation is you! 

So, here we are – after a long walk down memory lane. What can be done to make sure you don’t run into this scenario with such alarming frequency in future? How do we increase the odds of making the ninth time a charm? As a consultant, of course you start by trying to analyze the problem and find the root cause. Let us explore that in the next blog. 

You must be Logged on to comment or reply to a post.