sapconcept-bw.pdf

7/28/2019 SAPConcept-BW.pdf

1/9

The myths surrounding SAP BW

Helena Schwenk: [email protected] Woodward: [email protected]

February 2005

Expert advice


2/9

THE MYTHS SURROUNDING SAP BW

1

Ovum 2005. Unauthorised reproduction prohibited

The myths surrounding SAP BWSAP has sold its own product for business intelligence (BI) and data

warehousing, the SAP Business Information Warehouse (BW) since 1998 and

now claims to have around 4,000 live implementations worldwide. Its current

strategy is to supply the product as an integrated part of the NetWeaver

platform. This has helped to strengthen the message that BW is required to get

data out of SAP applications.

However, you should not assume that SAP BW is the obvious or only choice. It

is a complex product and its implementation can be as painful as that of an

ERP system. Buying BW does not avoid the need, common to every enterprisedata warehousing project, to understand the principles of business

intelligence, address the complexities of the source data and provide the right

tools for the business user.

This report sets out to dispel the myth that the product is the only and obvious

choice for organisations wishing to report on SAP application data. We

describe the issues that you should consider when you are evaluating SAP BW,

in order to ensure that you make the right product selection.

Key messages

There are many options for SAP users

SAP BW is a powerful toolkit, but it is only a complete solution for organisations with

certain requirements and characteristics. However, there are many other options for

reporting out of SAP, some of which will include BW as a component of the solution.

SAP BW suits some cultures and technical environments

Companies with highly centralised structures and large IT departments get on well

with SAP BW. The product suits traditional businesses that need operational reporting

rather than flexible analysis, and have low rates of change in business structures.

You need to ensure that SAP BW meets your needs as the technical complexity ofthe product means that it is hard to change once implemented.

SAP BW with Business Content is not an out-of-the-box solution

SAP Business Content (BCT) is a pre-built set of extract routines, objects and reports

that constitute end-to-end reporting from the ERP modules. It is separately licensed

from the rest of BW. You might think that, in conjunction with BCT, BW forms an out-

of-the-box data warehouse with everything included, and that all users have to do is

plug it in. This is a very mistaken assumption, as getting data out of SAP applications

and into a format that is suitable for reporting and analysis is a large project in itself.


3/9


2


Rebuilding an existing data warehouse in BW is not a good idea

Unless there are clear business benefits for doing this for example, the existing data

warehouse needs redesigning this should be avoided. The complexity of the BW

architecture makes this difficult, and the lack of flexibility means things will be lost.

The myths

Whether these originate from SAP, the competition or the user community, there are

a number of myths surrounding SAP BW more than there are for most other major

software products. Such myths lead to unrealistic expectations of the software at the

high level and implementation issues in practice.

SAP BW is the only way to get data out of mySAP and SAP R/3

The major ETL tools and BI platforms all have SAP adapters for SAP data, and

therefore can be used without BW. Using SAP software to extract SAP data certainly

makes sense. However, it is easy to overestimate various interconnectivity aspects of

SAP software in many areas: connectivity between modules, connection between

modules and BW, and lack of validation between loads from modules into BW are all

areas where the specific level of connectivity should be investigated rather than taken

for granted.

BW is definitely a good way of getting data out of SAP, particularly when combinedwith the objects from BCT. However, the complexity of this stage of the project should

not be underestimated.

Some organisations will find that their architecture uses BW as part of the extraction

process, rather than as the front-end data supplier of the data warehouse.

SAP BW with BCT is an out-of-the-box BI or data warehousingsolution

BCT is very useful for many reasons: providing a starting point to build BW objects,

providing examples of best practices, and constituting a set of reports that can be

used to validate ERP data against that which arrives in BW. However, in practice,most users need to customise the analysis objects to reflect their own individual

business. Standard templates will rarely meet the business users every need, and

objects that dont meet the reporting needs will lead to adoption issues.

SAP BW is an essential part of SAP architecture

For organisations that have decided to make alignment with SAP software their

strategy, the more software modules they have from SAP the better the likelihood of

achieving strong integration, and the more leverage they may have with the supplier.

However, very few organisations have nothing but SAP software, and the specific

uses to which BW is to be put still need to be analysed, even for committed SAP

shops.


4/9


3


Certain modules need SAP BW to run, for example, the SAP Strategic EnterpriseManagement (SEM) module. SEM provides business planning and what if? analysis,

bottom-up budgeting combined with top-down planning, business consolidation, tying

strategic objectives back to operational goals, and stakeholder relationship

management. This uses data from BW and also allows for write-back into the system,

so the module requires its own BW implementation.

BW is a low TCO option

Low total cost of ownership (TCO) of an enterprise BI solution is achieved by

maximising use of the system by implementing quickly, servicing a large number of

users and minimising the level of ongoing support required. Low TCO is not driven by

any software product but is facilitated by an appropriate project methodology and

implementation.

SAP BW is bundled with NetWeaver which can lead to the high-level perception that

low TCO naturally follows when using BW. It seems to make sense that buying some

extra software from the ERP vendor will work out cheaper than going to a best-of-

breed vendor for a BI suite; the added assumption that getting data out of SAP into

BW is easy compounds this. However, the product characteristics of SAP BW can

lead towards higher rather than lower TCO. Long implementations due to the

products complexity, rollouts to a relatively small number of users because of the

Excel interface, and a higher level of ongoing support than software with a more user-

friendly development environment are all characteristics of BW that explode this myth.

Its easy to integrate SAP data into SAP BW

Potential customers are given the impression that SAP data is easy to integrate into

SAP BW because the products come from the same supplier. However, this is not the

case, although there are many ways in which to integrate data from internal and

external SAP sources into BW, these vary in terms of their complexity and sometimes

require ABAP programming, or third-party vendor products (at extra cost) such as

Ascential DataStage.

BEx is a poor solution for business users

BEx receives very mixed reviews from users financial users who are Excel-literate

and are not familiar with BI tools enjoy it, while users who are either accustomed to

high-powered OLAP tools (such as Hyperion Essbase or Cognos Powerplay) or who

want very simple interfaces (such as PDF or printed reports) can find it clumsy and

inflexible. However, in terms of what can actually be done with the product, a lot can

be built in BEx. This may also not reach users because IT departments are not

geared up to write complex reports in the front end tool. Also, the tendency of users to

select BW as a no brain option means that not enough time and effort are invested

in introducing the users to the tool, training and explaining its functionality, which

could help with adoption and user satisfaction.


5/9


4


Evaluate SAP BW

Alongside other BI products

SAP BW is rarely compared to others at product evaluation time. A typical pattern

with BW is that the implementation goes ahead and then the user organisation

realises that the tool or implementation dont do the job as required and introduces

another product. The BI pure-play vendors, whether front-end or back-end based, are

used to being in a competitive situation and compared on functionality and price

sometimes with parallel prototype builds in order to compare functionality and speed

and ease of build.

As part of your overall BI strategy

A variety of approaches can be used to leverage the strengths of BW while also

meeting needs that arent within the strengths of the product. BW will only play the

role of an enterprise data warehouse in a relatively straightforward and highly SAP-

based architecture.

A common data-warehousing pitfall is to define requirements based on a small subset

of users.

Local and central users have different requirements

A global healthcare supplier implemented a single instance of SAP and a single instance of BW

for reporting. The corporate centre handled the implementation and rolled access to SAP BW

out to the business units. Previously the company had had a more decentralised architecture

where the business units had their own IT functions which managed their technology needs.

The new implementation didnt allow the business unit IT functions access to the SAP BW

Administrator Workbench so they couldnt define their own data extracts. This meant that the

central IT function was swamped by requests from the local units to supply data. The business

units were expected to use R/3 reports or BEx for their reporting needs, and extract data into

Excel and Access for further manipulation if required. This worked for the smaller business

units but once the larger business units went live they realised that these tools couldnt handle

the required data volumes of these extracts, and more analysis functionality was required.

The largest business unit ended up implementing the SAS BI platform, as they had staff with

experience of it. SAS enabled the local IT function to extract data and manipulate it to provide

the framework for the analyses required by the users.

This illustrates the need to ensure the reporting tool and security architecture of BW meets the

needs of all the users it is expected to serve. Note that this pitfall is not unique to BW as it is a

project issue rather than a product one.


6/9


5


How to implement SAP BW

Do not treat BW as just another SAP module

BW must be implemented in line with good data warehousing and BI practice, in

particular maintaining the strong connection with business users that is required

during the course of a BI design and build phase. Treated as just another ERP

module, it will lead to a lack of focus on the business requirements, lack of end user

involvement, and ultimately lack of end user adoption.

Dont take the ERP approach where processes are set in stone

Managing a BI or data warehousing project in the same way as an ERP project leads

to issues, the main one being that ERP processes are not expected to change once

implemented. The point of a BI system is to meet user reporting and analysis needs.

If these needs are not met, users will start to work round the BI system, extracting

data from sources and using Excel and other personal tools to aggregate data. This

leads to data quality and reconciliation issues, as well as users taking time to

generate information rather than simply extracting it from the system. The concept of

a low adoption rate where the system is deployed onto desktops, yet the users

never use it does not exist for ERP systems, but for BI systems it is a classic reason

for project failure.

The inflexible architecture of SAP BW leads to difficulties in making changes whererequired; for example, to business structures. However, if these changes are

required, they should be taken seriously rather than ignored and the assumption

made that business users are impossibly demanding.

There are two ways to avoid this pitfall as far as possible:

ensure that all business users are consulted about the types of data structuresthey require. A common project issue with BI systems is that only a small subset

of users are asked to contribute to the project requirements for example,

consulting a single business unit and then rolling out to twenty. This means that

many requirements are not captured, and users then have to work round the

system. In a system where changes are hard to propagate, it is essential not to

do this

predict the types of changes that the system will need to reflect, again inconjunction with business users. A common issue with BW is not to provide users

with the right level of detail.

Allow for customisation of BCT

A common reason for project over-run is that users assume the BCT modules will

supply all the reporting and analysis objects needed for their company. This is

unlikely to be the case. The BCT modules are very valuable in providing a starting

point that can be used for validation of the data in BW, as well as templates for the

organisation to create its own reports and analyses. However, time must be planned


7/9


6


in the project to perform this customisation. By the nature of BI, each organisationmay use the same invoicing processes, but this doesnt mean each organisation is

likely to analyse the data in the same way for decision-making purposes.

The blending of operational reporting and decision support-style analysis may partly

account for this confusion. In general, BW supports the middle of the analytic

spectrum, allowing mid-range query and OLAP analysis, but not the very simple

reports for information consumers or the high-powered OLAP functionality for

business analysts that other platforms can enable.

Take time in the design stage

A key characteristic of BW is its complex architecture. Objects such as InfoCubeshave to be designed to reflect the business need, and also the expected change in

this need. This differentiates BW from the pure-play, front-end based BI players such

as Cognos and Business Objects; these vendors have more architectural options

open so that systems can be simpler and implemented more quickly.

A key problem with BW implementations occurs when users need more detail than

the InfoCube is geared up to provide, as this means the cube is constantly referring

back to the detailed data and performance dramatically degrades. Products that

reflect change more easily allow for redesign, but BW needs to be designed correctly

up front.

When to use SAP BW

In this section, we describe the cultures and technical landscapes of organisations

that have synergy with the architecture of SAP BW. Enterprises with these qualities

will be inherently suited to making good use of SAP BW.

High level of central control

BW facilitates a high level of central control, especially if the BW implementation is

undertaken by the same part of the organisation that implemented the ERP. Some

organisations are working towards this, or are already in this position. Those that

arent may find that local units have alternative requirements, or that the central unitisnt geared up to meet reporting needs from the local units.

This is arguably a function of the implementation rather than the product. However,

many BW implementations tend to work in this way in practice, perhaps because the

projects are driven from the ERP implementations.

Multiple instances of BW have their own issues, with integration and validation

between BW instances presenting its own challenge, despite the data hub and spoke

framework.


8/9


7


Centralisation of metadata pays dividends

The global healthcare supplier we described earlier found that the centralised metadata

supplied by the single instance of BW and implemented by the corporate centre met their

requirements. Data definitions were discussed, set and made visible to local and central users,

and shared across the business, removing confusion and the need to constantly check

definitions. The local unit was very happy that the corporate centre was there to handle this

piece of work.

High level of ongoing, SAP-skilled, IT supportSAP BW requires a high level of support from IT specialists, both for loading data into

BW and creating data structures such as reports and analyses. Companies that

succeed with BW understand this in advance and have the support organisation in

place.

Many companies use systems integrators to manage and work on their large SAP

implementations. This is a good way to make use of expertise and experience without

having to develop it in-house. However, users should be aware of the support

requirements of the continued need for SAP-specific skills such as SAP BASIS and

ABAP. Provision should be made in the project plan for knowledge transfer between

consultants and in-house staff.

SAP BW is an evolving product with a variety of capabilities. However, because of the

technical complexity of the product the companys IT department needs to have the

capacity and the inclination to perform development in order to extend their

applications to take advantage of product improvements. This contrasts with the ERP-

like structure of many BW projects, where business change is not reflected as often

as is ideal.

Alignment of reporting requirements with BW capabilities

The key strength of BW reporting is in providing operational reports on SAP

application data, with some slice and dice analysis capability and drill down. However,

in terms of providing ad hoc analysis facilities the tool is not as strong.

In order to be happy with the facilities provided by Business Explorer, the BW front

end, users need to be Excel literate. Not all are, especially outside finance

departments. This leads to a number of BW implementations having to be extended

afterwards, as the users need a more intuitive and less interactive product for basic

reporting.

In general, the range of BW reporting capabilities is narrow compared to the best-of-

breed front-end vendors such as Business Objects and Cognos, both of which

provide better support for the simpler reports and more complex analyses. However,

for some organisations they are more than adequate.


9/9


8


Ovum does not endorse companies or their products. Ovum operates under an Independence Charter. For

full details please see http://www.ovum.com/about/charter.asp.

Whilst every care is taken to ensure the accuracy of the information contained in this material, the facts,

estimates and opinions stated are based on information and sources which, while we believe them to be

reliable, are not guaranteed. In particular, it should not be relied upon as the sole source of reference in

relation to the subject matter. No liability can be accepted by Ovum Limited, its directors or employees for

any loss occasioned to any person or entity acting or failing to act as a result of anything contained in or

omitted from the content of this material, or our conclusions as stated. The findings are Ovums current

opinions; they are subject to change without notice. Ovum has no obligation to update or amend the

research or to let anyone know if our opinions change materially.

sapconcept-bw.pdf

Documents