BI Projects

“What you need to know about SAP BW”

“the reasons behind the struggle to get it right”

Arno Luijten (SAP & BI specialist @ NewFrontiers)

Februari 2008
The struggle for Management Information from SAP R/3.
Many organizations are struggling with their Management Information. There are many needs and
many solutions to provide this information and it is exactly this that makes the problem so complex. In
large companies there are many requirements that need to be met and, quite often, huge data volumes
are involved as well.

Looking at all the solutions that are offered, it is not a straightforward choice pick any of the solutions on
offer. Typically all offerings have their strengths and weaknesses. Even knowing and understanding
those can be a lifetime mission. Although the market for MIS solutions is consolidating because of
mergers and acquisitions there are still many options

Pick SAP BW, it is a ‘no-brainer’

Companies that run SAP R/3 are a very interesting target group for BI vendors. They typically have
complex businesses with complex processes to support them. As R/3 is quite a versatile system, it
allows many businesses to taylor their needs into the system. Despite of being an extremely versatile
system, R/3 still comes with a huge legacy build into the system. You cannot blame SAP for offering a
system that is based on evolution. Building a system with all this functionality from scratch is almost
impossible and would take huge investments.

One of the most apparent omissions in R/3 is the lack of reporting capabilities for management
purposes. The way the system was built is exactly what makes R/3 a difficult system from a MIS point
of view. There are thousands of tables used by R/3 that may contain relevant information. Also the
limitation that you cannot access the underlying database directly makes things complicated.

So at first sight SAP BW seems like a no-brainer. Being from the same manufacturer as R/3 it must
'understand' the R/3 system better than anything else. Still, there are many companies that are
struggling to implement SAP BW. Why? There are several reasons for this and it's the combination of
factors that hampers a smooth implementation. We will try to explain this below.

© 2008 NewFrontiers Group (Author: Arno Luijten) Page 2 of 7

Struggle - Reason # 1 – the architecture of BW
BW is not only developed by the same company SAP, it also shares a lot of code with it's parent
product. The whole kernel and ABAP language are more or less the same. Also the way developments
are handled in the landscape are very much comparable. That is good news isn't it?

Well, yes and no. The way R/3 processes data is much different from the way a Data warehouse is
processing data. Although SAP made good efforts in adapting the kernel to be able to handle these
bulk operations, it is still using a procedural system to deal with bulk operations on (potential) huge data
sets.

Are there no synergy advantages because both systems use the same programming language and
infrastructure setup?

Again this looks like an advantage but it is actually not. There are fundamental differences between the
setup of an OLTP (online transaction processing) system and a reporting system. This means that the
programming language ABAP is rooted in the procedural handling of data used in a OLTP. It involves
the selection of data into a temporary structures and then perform the required operations. Typically
systems used in MIS handle data in the format of streams where you modify data by operating on the
data stream. The differences become clear when you are using huge volumes of data, the data stream
architecture typically has a smaller memory footprint, making it faster and much more scalable.

The proof of this is the release of the BI Accelerator. This is a hardware based (technical) solution to
improve the performance of SAP BW. The BI Accelerator deserves an article of it’s own so for here it is
enough to state that it is an expensive stopgap bringing no improvement to architecture of BW.

Struggle – Reason # 2 – the business content in BW

Building a Data Warehouse to satisfy the needs for (management) reporting is not an easy task. It
requires a good analysis of the reporting requirements and a well constructed model that fits the
organization. As most organizations want to combine data from different sources into comprehensive
reports that can reveal important steering information (for example combining actual sales figures with
external market data) they also need structures that can accommodate both in a way useful for that
particular organization.

Unfortunately most organizations are not paying enough attention to this phase of building a data
warehouse. By not carefully designing your model you are building legacy from scratch as it will be a lot
of work afterwards to change models to accommodate for new needs. SAP has this very tempting offer
inside SAP BW called 'Business Content'. It basically gives you a head start in setting up your data
warehouse. By simply activating the content you get ready defined structures to build your reports on.

So (again) if that is the case, why do most BW project take so much time and effort?

© 2008 NewFrontiers Group (Author: Arno Luijten) Page 3 of 7

The business content was built in line with the SAP R/3 business model or modules. These modular
results do not share anything. Explained in an example, building reports relating the sales expenditure
booked on cost centres to the confirmed sales orders (metric: direct sales cost per sales order
confirmed) are very labour intensive. At NewFrontiers we call that the ‘stovepipe approach’. All data sits
in it’s own “stovepipe”. Bill Inmon once called BW a bunch of non related cubes. Since the ‘reporting
requirements’ are quite often asking for a cross-module insight, the data needed for a single report has
to be sourced from different modules. SAP’s pre-configured business content never fits this requirement
and a lot of additional work is required to gather the data into a single cube.

Struggle – Reason # 3 – the building or changing of

structures in BW
There are two routes to make BW fit .

• Build from scratch

• Adapt the pre-configured definitions (business content).

The first option means a lot of work, all definitions have to be put in place, all structures need to be build
as well. The second option looks much more promising. Early flavor results can be made available in a
relatively short period of time.

Trying to change the pre-configured definitions makes it apparent why SAP BW is a very time
consuming system to build. Changing structures in BW is not a trivial activity. There are many steps
involved and quite often data needs to be reloaded into the system. As the system tries to prevent data
corruption by guiding the designer through a carefully designed procedure for changing objects it also
limits the number of 'tricks' an experienced DBA can use to migrate data structures.
By relying on an system to maintain the setup of your data warehouse, you are no longer able to
change things 'manually'. Although this seems like an advantage, daily practice proves it has a serious
and negative impact on progress. Most changes will take a long time because of the inefficient way of
working. You may consider this being the trade off for having a system that protects you from messing
up your data warehouse. However when your R/3 system is heavily customized and you are dealing
with large data volumes this will become a problem.

Struggle – Reason # 4 – the way the data is stored

BW uses machine generated structures to store your data in a (underlying) database. Unlike R/3 it
frequently uses non-descriptive names for tables and fields (at least for those that are fluent in the
German language). Similar to R/3 you must use the front end to perform any operation on the
underlying database.

© 2008 NewFrontiers Group (Author: Arno Luijten) Page 4 of 7

This is where the systems becomes inefficient, in general the system uses much more steps to reach a
result then a skilled DBA needs. A DBA will know the context of the operation, BW will always use
generic ways to achieve a specific result.

Looking directly in the BW database can be accommodated but will only lead to confusion as the
metadata, required to understand the business data is not available in the database unless you use the
BW front end. This is actually a shame as (for example) Oracle database provides many ways to
include metadata into the database itself (meaningful field/table names, field comments, etc.).

Maintaining a data warehouse will always require manual interventions at some point whether you like
it or not. The 'distance' BW sets between the storage structures and the administrators will lead to much
frustration and delays. It is similar to the cars of today. It looks like everything can be diagnosed and
solved via the computer, but in the end you still need to get a down and dirty to the fix a problem.

Struggle – Reason # 5 – the data duplication

In general BW does not have the ability to perform operations on data sets but only when copying from
one data set to another. This means data replication in SAP is a common thing to happen, taking up
excessive disk space as you go. Don’t get me wrong. Data warehouses typically duplicate data by
aggregating data from transactional, detailed levels into data marts for analytical purposes. However
the data duplication in SAP BW has a pure technical background and serves no business need.

Although the above way of working also brings you SAP BW's equivalent of the 'undo' button it does put
a significant toll on performance when data volumes are high. It also adds additional tasks to the
housekeeping department. The number of checks you need to perform in a fully grown BW system are
much bigger when compared to a database operated data warehouse.

As described earlier BW comes with a pre-packaged definition set. This also leads to significant storage
needs for data that is not used. Because SAP uses generic extractors to retrieve data from R/3 you will
end up with much more then what you need.

© 2008 NewFrontiers Group (Author: Arno Luijten) Page 5 of 7

Struggle – Reason # 6 – the BI specialists
Finding skilled BW resources is not only difficult, it is also very costly. Many BW resources do not have
an understanding of the processes in R/3. Many see R/3 simply as record/transaction generator and
still need a lot of coaching by your current R/3 administrative staff to explain the meaning of the data in
relation to your businesses processes. So, however funny this may sound, often SAP BW consultants
and SAP ERP consultants do not understand each other. This obviously also leads to errors,
unnecessary delays and projects running out of their budgets.

Famous last words

Do not believe that a BW implementation is easy. Do not implement the software because you believe
that you have paid for it. The biggest cost is implementing BW and keep it running. By the time you are
having second thoughts on your choice there is almost no way you can have a graceful retreat.

You need to be very clear on the costs and benefits of a BW system before you start! A good start is to
look back on how you experienced the implementation of R/3 itself. Most likely you reached a point
there when you thought 'how much more is this gonna take'. Rest assured for BW it will be no different.

© 2008 NewFrontiers Group (Author: Arno Luijten) Page 6 of 7

About Arno Luijten
Arno Luijten first experience with SAP is from the mid 90’ies. At that time he was IT manager at Ascom
Banking Automation Netherlands were he was responsible for the implementation of SAP R/3. One of
his favorite stories ‘SAP stories’ is based on what he experienced when he had to order the hardware.
The people that sold SAP never addressed the topic specifically. Based on his earlier experience with
the implementation of transaction software he put an estimate in the budget. The shock came when the
“SAP basis guy” handed in the specification. Although in shock he thought that by buying that – in those
days – super server it would be done! Later they told him about the 3-tier landscape the storage
requires etc. Anyway the first time ever that Arno ran over budget! Big time!

It is this experience that has had large impact on Arno’s way of working. He has been very successfull
implementing solutions for SAP. Never underestimating the effort always open and upfront to his
clients, making sure that they know what they have to know.

Arno was amongst the first that joined NewFrontiers and as such has had significant impact on what the
company is like to day. Key thing put your money where your mouth is! He has built up significant
experience building data warehouses on SAP ERP for organizations like Shell, Epson and Unilever.
Most of his clients wanted Arno to stay for many years which is where and why he has build up so
much in depth knowledge of the different techniques and tools in place like SAP BW (today called
Netweaver BI).

© 2008 NewFrontiers Group (Author: Arno Luijten) Page 7 of 7