BI and ESA driven approach to SAP project implementations - Part 3

Where are we now?



We walked down the memory lane, and relived the experience of information inefficiencies in our SAP projects.

We analyzed some reasons why the traditional implementation methods leave a lot to be desired.
I guess it is about time we got around to solving this mess.



Let us try to set the context.



Consider the process of building a house. You start by sitting down with an architect who will convert your ideas into a tangible thing – a blue print. What happens then? A structural engineer takes this blueprint as input, and converts this into a series of technical drawings and specifications. These are then expanded upon by the electricians, masons and plumbers etc as they build different parts of the house.



We can take a similar approach in our SAP projects too. In fact, we do have (or claim to have) a blueprinting phase in most of our projects.



What is the significant difference between an SAP blueprinting activity and that of building a house?



In the case of a house – we follow a tops-down approach. We give our ideas to the architect, who will put it all together, along with things he has learned over the years from other clients – and set down tangible things for the structural engineer to look at. Engineer does the same for the electrician, mason etc.



In SAP blueprinting, we assume that the SAP software is inherently tightly integrated, and hence a bottoms up approach is just fine. We start by concentrating on the order to cash process, procure to pay process etc and assume that it will all somehow build up to a nice whole solution at the end, due to the inbuilt integration aspects of SAP.



Seldom does everything go according to plan – whether we are building a house or implementing SAP. The plumber might find that he is unable to find the same size piping that the engineer specified. What happens now? Either the plumber goes ahead with whatever is available in the market, or he goes back to the engineer with this information. If he goes ahead with his own ideas without checking back with the engineer, it can become a sizeable issue later on. If he checks with the engineer, the latter will be able to take a decision with the least impact to the design, time and budget. It is also expected that the engineer checks back with the architect if this affects the usability of any aspect of the house. Finally, if the original vision needs to be changed, the architect is expected to check with you, the guy paying the bills – who has to live in the house after every one else involved in the building process goes off in their separate ways.



In SAP, especially with the advent of specialized suites like CRM and SRM, it is not longer safe to assume that SAP will inherently take care of the integration aspects. A good example is business partner master data. You might have a channel partner in your CRM system, who is also a sold to party in your ECC system, and a vendor in your SRM system. SAP doesn’t care if you treat them the same or as disparate entities, since all the business rules you configure are within a given system (say CRM) and not within your solution (which has CRM, ECC, SRM and maybe legacy systems).



Unless you make a conscious effort to design it well (say with MDM and/or BI ), the chances are that you will never know that these business partners are all the same. What is the big deal if you don’t know they are the same? Well, you lose out on the big picture. Example : Say you have two types of relationships with another company – you buy some things from them, and you sell some things to them. At any point of time, you typically have money coming in from them, and money going out to them. If you cannot establish the fact that the vendor and customer are the same company, you won’t be able to optimize your cash flow, credit management etc.



How do we ensure that all of these different data points play well with each other?



To begin with, we need to find the one place where they all come together.



Who needs all of the data well integrated?



Is it the sales and distribution guy? Is it the lady who manages the inventory? Is it the finance clerk who pays invoices? The answer – and no points for guessing – is none of the above. It is the folks who look over multiple domains that need all the dots connected. Example : the VP who runs both sales and marketing finds it invaluable to know if he can compare marketing spend with sales revenue. The COO, CFO and CEO are typically interested in comparing data across all the domains to make sure the company is healthy and growing.



The first step then, is to find out how these people manage their company – in quantitative terms.



This is not as hard or insurmountable as it seems. People at this level usually manage information at an aggregated level. I like to start with analyzing how the business is planned and budgeted. The logic is simple – they expect to compare actual data with this planned/budgeted data to make their decisions. If you got the plan/budget covered – you have the actual data (at the aggregated level) covered too. Looking at the budget at the topmost level – you can identify the minimum dimensions that you need in your data model. This is where account modeling becomes your best friend. Represent each KPI as a measure, and list the characteristics by which they are measured. After you are done representing all your KPIs – you would arrive at something like this for example. Here I am considering just 2 domains – sales and marketing. In real life, you have to consider all applicable domains.





Business Partner Group Product Type Quarter Measure Amount
Revenue
Marketing Spend
..
..



The one thing you have to watch out is – only list those dimensions that are common across KPIs at this level. For example – You typically sell at a material number level, but market at a product type level. So – you cannot compare sales and marketing spend at a material number level. If you try to do it, you will need some sort of an allocation rule that splits your product type to all products– and from that point you start reducing the purity of the data. In budgeting, it is a valid process to allocate like this – but the moment you start splitting your actual data (the real dollars), you are spoiling the quality of the data. You can do this for “what if analysis” etc, but do not treat this as the “truth”.



You can now start going down the org hierarchy and filling in the next level of KPIs, thereby expanding your data model. This is an important aspect of the exercise – after all the VP cannot run the company all by himself. The guys reporting to him will need a more granular view of the data to manage their responsibilities. Again, budgeting is a great place to start from. Budgeting is typically a top down operation in most companies. Example : If the VP budgets by Business partner groups, probably the guy next down in the hierarchy will split it by geographies.



Keep going in this fashion, till you reach the operational reports. At this level – you may or may not find budgeting information to help you. But do not despair – this is where the existing legacy reports come into play. They will help you get started to find the lowest level information that needs to be reported on.



Needless to say – do not just trust documented information made available to you. You should talk to the users and make necessary adjustments. It is very common for users to take a canned report, and manipulate it on their desktops. So make sure you verify the validity of existing reports etc.



What do we do with all the information we compiled so far?



It is time to talk to the folks implementing the order to cash process etc. Each “measure” you figured out typically has at least one transaction that creates this data in the system. Example: Revenue might be from SAP sales orders. You know all the characteristics that the business is interested in to measure that KPI. So, armed with this information – start a discussion (which is nothing but a gap analysis) . The idea is that there should be a way to attach all the business-relevant characteristics to the transaction.



Let us consider one of the pain points we discussed in the previous blog. The case in point is that of identifying a customer segment in marketing spend transactions. If the customer belongs to only one segment, you do not need to hold the segment explicitly in the transaction, since it can be uniquely determined from the master data. However, what if the customer belongs to multiple segments? You cannot determine the segment automatically in this case. So you are better off asking a user to choose the segment from a list of possible values in this case.



This also provides an opportunity to take a look at the possibility of changing a business process. Example: Say the business user budgets marketing spend by customer segment. However, the transactions never capture segment. You should go back to the business and ask them if they see sufficient value in capturing the segment information in transactions. Explain to them the details of what it takes to capture segment – maybe an SAP enhancement, retraining hundreds of users, maintaining more master data etc. The business might just realize that it is not of great value to measure KPIs by segment any more. After you go through all the measures in this fashion, you should have the transactions designed in such a fashion that they will contain the characteristics that your business users are interested in (or have a well defined look-up rule to find a characteristic from some other field) . This is not to say that transactions will not have any additional fields – they might need all kinds of extra fields to hold things together.



This information – which serves as a common base for the business intelligence guys, transaction system guys and the business users, is invaluable to an organization. In the next blog, we will explore the physical implementation options in the system – and what a business process expert needs to know in terms of the options available to him/her.

BI and ESA driven approach to SAP project implementations - Part 2

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.

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.

Campaign Id
Planned Marketing Effectiveness
Actual Marketing 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.

Campaign Id
Planned Marketing Effectiveness
Actual Marketing Effectiveness
Planned

Number of

Clicks
Actual Number of

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.

Campaign Id
Measure
Planned

Value
Actual

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.

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.

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 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.