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

[Former Member]

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.

1. Why would you budget by a characteristic that your transaction processing system does not track?
2. 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.

1. Move it all to the next phase.
2. Let ETL add segment information to the actual spends, in the same ratio as it was planned.
3. 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.