BI and ESA driven approach to SAP project implementations Part 11. 2. 3. 4. 5. Posted by Vijay Vijayasankar in vijay.vijayasankar on Mar 10, 2008 1:31:55 AM 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. 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. 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. 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. 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. 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 multiprovider 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 dont 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 dont 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 CFOs 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 youve postponed twice already you cant 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 dont 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 dont 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.

BI and ESA driven approach to SAP project implementations Part 2Posted by Vijay Vijayasankar in vijay.vijayasankar on Mar 10, 2008 1:33:24 AM Why does the beaten path fail in delivering maximum value... As we walked down the memory lane in the my last blog ( A trip down the memory lane) , I am sure you recognized that the traditional approach to SAP projects leave a lot to be desired. Let us try to see why this happens, so that we can figure out what needs to be done to make this better for us in our next projects. There are several reasons one can think of, but here are a few that most of us can relate to. Putting the cart before the horse Let us consider the dilemma we discussed in the previous blog where the Marketing manager budgets by market segment, but CRM transactions that deal with actual spends do not track segments at all. This poses an important question. This question can be phrased in two ways, depending on who is asking. Why would you budget by a characteristic that your transaction processing system does not track? Why wouldn't the transaction system capture segments, if the managers running the campaigns base their decisions on which segments they are capturing? I guess you wouldn't fight me a lot if I say that IT is an enabler to business, and not the other way around. So that would mean that it is the job of IT to make sure that transaction processing systems are designed keeping in mind how the business leaders envision the direction of their respective domains. Simply - the right thing to do is to include segments in the CRM transactions. CRM implementation team would have loved to have this information before they were done with their design, so that they could have accommodated it. But since reporting follows transaction processing in a traditional implementation methodology, they did not have that information in time. As a result, some sort of a compromise is arrived at which might include some or all of the following. Move it all to the next phase. Let ETL add segment information to the actual spends, in the same ratio as it was planned. Push back to the business to stop budgeting by segment. You get the idea - we end up making such compromises and end up decreasing the effectiveness of both the transaction processing system and the BI system.

1. 2.

1. 2. 3.

SAP project implementation methodologies (like ASAP and its several variants that implementation partners of SAP use) typically addressed optimization of the transaction processing abilities of an ERP system (like R/3 or ECC). Blueprints were written focusing on how to do "procure to pay" or "order to cash" better, with little to no effort to make consistent business intelligence available across the company. Evidently, this covers only the operational aspects of running a company. That leaves the tactical and strategic decision making out of the equation. This is typically manifested in the phenomena that consultants call human ETL'. Remember the Finance manager, who manipulates operational data to form a CFO dashboard in my last blog ? This is the guy, who the CFO prays will never get hit by a truck on the road! Lack of imagination on data modeling At the beginning of the project - you figure out a reporting requirement that says - "This report needs to compare Planned vs Actual Marketing Effectiveness for all campaigns". Simple - we create a cube as follows. Planned Marketing Actual Marketing Campaign Id Effectiveness Effectiveness C1 10 8

Everything works well, till the marketing guy tells you - "from next month, we are changing the way campaigns are measured. We are moving to a 100% internet campaign model, and "number of clicks" will be the way they are measured.". To preserve old data and to cater to the new requirement - you change the cube to its new structure. Planned Actual Number Planned Marketing Actual Marketing Number of of Campaign Id Effectiveness Effectiveness Clicks Clicks C1 10 8 C2 100000 110000 Hardly a couple of months pass, when you get that email well, the number of clicks do not seem to be a good measure for all campaigns - we need some other ways of measuring" . What is the result - your cube has several key figures, and your Bex reports look like a mess. There are smarter ways of dealing with this, like using an "Account Model" instead of the "Key figure model' used in this example. We will discuss these strategies in a future blog, but here is how the cube will look like if we had used an account model for this cube from the beginning. Planned Actual Campaign Id Measure Value Value C1 Marketing Effectiveness 10 8

C2 Number of Clicks 100000 110000 As you would notice, if marketing manager changes his mind one more time, you do not need to change the data model any more. All you would need is add a new value for the info-object called "Measure" . This also gives us a powerful feature for free- the ability to select a "measure" in your bex report. This means - the user can choose to see only number of clicks, if he wants to. This is not possible with the key figure model where the option would be to display everything and then hide the ones we don't want to see. Now, I am not saying that Account modeling is the one-size-fits-all solution for all your problems - but it is an option every BW person should consider seriously when designing the data model. Treating business content as sacrosanct SAP has tried to provide a lot of business content for its ERP solution and Business suites like CRM, SRM etc. The idea is that you use these as a template for your BW implementation, and build on it. Instead of treating business content as a "means to an end", people started using it more as an end in itself. Say you have business content for Sales and Marketing activated. The sales managers have all the pertinent information available on their finger tips, and the same is true for marketing managers who deal with campaign spending. Great - we have the operational aspects well covered. Now, the VP who heads both sales and marketing wants to compare sales revenue with marketing spends and budgets. Here we run into a problem - the cubes that hold sales information and cubes that hold marketing information do not have much in common. So you end up writing some transformations and hold it all together. This might solve the problem in the short term, but will fall apart as soon as marketing changes how campaigns are tracked. Those of us who have supported CRM implementations know that this is just another day in office in the marketing world. Pretty soon you will end up with several cubes and reports that are variants of each other Is there any wonder then, that the data model in an average project looks like several disparate objects are held together by band aid?. Doing it the first time is a triumph of imagination over intelligence. Doing it in your subsequent projects is the triumph of hope over experience! Not treating Business Intelligence as a service

It is very seldom in a project of any size that SAP is the only show in town. There are probably several other systems supporting important aspects of the business. The traditional approach was to migrate everything to SAP or BW (or at least build interfaces to SAP), and centralize IT spending so that somehow the Total Cost of Ownership can be lowered. Service oriented architecture (SOA), is one of the schools of thought that is gaining a lot of traction in challenging this notion. Several big companies like IBM, SAP etc have invested in this in a major way, and as a result - we now have an organized body of knowledge that supports how we can make maximum use of information sitting in heterogeneous systems. SOA has had a major impact on transaction processing in recent past, and as a result we have SAP and other software vendors providing out of the box services that can be consumed by a variety of systems. However, SOA has not quite caught up in the BI world to the extent that it has succeeded in the transaction processing world. The major reason for this situation is that BI is pretty unique to every company, and it will probably remain that way since it is a strong competitive differentiator in the market. However, this is not to say that BI cannot make use of SOA - quite the opposite infact. A good example is the use of widgets. People who keenly follow sports or the stock market, usually have a widget that keeps score for them on their desktops. Imagine the efficiency improvement for a CFO who can see up to date aggregated information on all financial aspects of her company on a widget on her desktop. This is easily possible by using a BI service. Also consider the way we organize the ETL in a BI project. The traditional option is to treat the data coming from each source system as separate, and then build transformations and DTP for them. This need not be the only way to load data into BI. You can explore the possibility of using a webservice to get data into BI, thereby having a common interface for several different systems to interact with BI. Again, this is not the solution to all the evils in the BI world - just that it can be a powerful weapon in the arsenal of every BW consultant . Now that we have a grip on the problem, and have done some preliminary analysis - we will get into solution space in the next blog.