P. 1
What you need to know about SAP BW

What you need to know about SAP BW

|Views: 21|Likes:
Published by emin3mfan7756
SAP BW
SAP BW

More info:

Published by: emin3mfan7756 on Feb 01, 2013
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less

11/02/2013

pdf

text

original

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

Despite of being an extremely versatile system. there are many companies that are struggling to implement SAP BW. huge data volumes are involved as well. The way the system was built is exactly what makes R/3 a difficult system from a MIS point of view. © 2008 NewFrontiers Group (Author: Arno Luijten) Page 2 of 7 .The struggle for Management Information from SAP R/3. it is not a straightforward choice pick any of the solutions on offer. Many organizations are struggling with their Management Information. it allows many businesses to taylor their needs into the system. Looking at all the solutions that are offered. Even knowing and understanding those can be a lifetime mission. Also the limitation that you cannot access the underlying database directly makes things complicated. There are thousands of tables used by R/3 that may contain relevant information. We will try to explain this below. Although the market for MIS solutions is consolidating because of mergers and acquisitions there are still many options Pick SAP BW. Why? There are several reasons for this and it's the combination of factors that hampers a smooth implementation. Being from the same manufacturer as R/3 it must 'understand' the R/3 system better than anything else. As R/3 is quite a versatile system. Still. it is a ‘no-brainer’ Companies that run SAP R/3 are a very interesting target group for BI vendors. In large companies there are many requirements that need to be met and. So at first sight SAP BW seems like a no-brainer. They typically have complex businesses with complex processes to support them. You cannot blame SAP for offering a system that is based on evolution. quite often. There are many needs and many solutions to provide this information and it is exactly this that makes the problem so complex. Typically all offerings have their strengths and weaknesses. R/3 still comes with a huge legacy build into the system. 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.

This is a hardware based (technical) solution to improve the performance of SAP BW.Struggle . the data stream architecture typically has a smaller memory footprint. It basically gives you a head start in setting up your data warehouse. That is good news isn't it? Well. yes and no. This means that the programming language ABAP is rooted in the procedural handling of data used in a OLTP. By simply activating the content you get ready defined structures to build your reports on. Struggle – Reason # 2 – the business content in BW Building a Data Warehouse to satisfy the needs for (management) reporting is not an easy task. Although SAP made good efforts in adapting the kernel to be able to handle these bulk operations.Reason # 1 – the architecture of BW BW is not only developed by the same company SAP. making it faster and much more scalable. So (again) if that is the case. Unfortunately most organizations are not paying enough attention to this phase of building a data warehouse. The differences become clear when you are using huge volumes of data. The way R/3 processes data is much different from the way a Data warehouse is processing data. 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. Also the way developments are handled in the landscape are very much comparable. 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. It involves the selection of data into a temporary structures and then perform the required operations. There are fundamental differences between the setup of an OLTP (online transaction processing) system and a reporting system. why do most BW project take so much time and effort? © 2008 NewFrontiers Group (Author: Arno Luijten) Page 3 of 7 . it is still using a procedural system to deal with bulk operations on (potential) huge data sets. The whole kernel and ABAP language are more or less the same. 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. The proof of this is the release of the BI Accelerator. 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. it also shares a lot of code with it's parent product. It requires a good analysis of the reporting requirements and a well constructed model that fits the organization. Typically systems used in MIS handle data in the format of streams where you modify data by operating on the data stream. SAP has this very tempting offer inside SAP BW called 'Business Content'.

Struggle – Reason # 3 – the building or changing of structures in BW There are two routes to make BW fit . You may consider this being the trade off for having a system that protects you from messing up your data warehouse. Similar to R/3 you must use the front end to perform any operation on the underlying database. There are many steps involved and quite often data needs to be reloaded into the system. Trying to change the pre-configured definitions makes it apparent why SAP BW is a very time consuming system to build. All data sits in it’s own “stovepipe”. Although this seems like an advantage. • • The first option means a lot of work. Struggle – Reason # 4 – the way the data is stored BW uses machine generated structures to store your data in a (underlying) database.The business content was built in line with the SAP R/3 business model or modules. you are no longer able to change things 'manually'. Build from scratch Adapt the pre-configured definitions (business content). all structures need to be build as well. all definitions have to be put in place. 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. Early flavor results can be made available in a relatively short period of time. At NewFrontiers we call that the ‘stovepipe approach’. By relying on an system to maintain the setup of your data warehouse. 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. These modular results do not share anything. 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. Bill Inmon once called BW a bunch of non related cubes. However when your R/3 system is heavily customized and you are dealing with large data volumes this will become a problem. Unlike R/3 it frequently uses non-descriptive names for tables and fields (at least for those that are fluent in the German language). 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. The second option looks much more promising. Changing structures in BW is not a trivial activity. 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. © 2008 NewFrontiers Group (Author: Arno Luijten) Page 4 of 7 . Explained in an example.

Maintaining a data warehouse will always require manual interventions at some point whether you like it or not.This is where the systems becomes inefficient. Looking directly in the BW database can be accommodated but will only lead to confusion as the metadata. This also leads to significant storage needs for data that is not used. This is actually a shame as (for example) Oracle database provides many ways to include metadata into the database itself (meaningful field/table names. © 2008 NewFrontiers Group (Author: Arno Luijten) Page 5 of 7 . taking up excessive disk space as you go. Data warehouses typically duplicate data by aggregating data from transactional. A DBA will know the context of the operation. 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. detailed levels into data marts for analytical purposes. The 'distance' BW sets between the storage structures and the administrators will lead to much frustration and delays. but in the end you still need to get a down and dirty to the fix a problem. It also adds additional tasks to the housekeeping department. 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. Don’t get me wrong. It is similar to the cars of today. in general the system uses much more steps to reach a result then a skilled DBA needs. BW will always use generic ways to achieve a specific result. However the data duplication in SAP BW has a pure technical background and serves no business need. field comments. required to understand the business data is not available in the database unless you use the BW front end. This means data replication in SAP is a common thing to happen. As described earlier BW comes with a pre-packaged definition set. It looks like everything can be diagnosed and solved via the computer. Because SAP uses generic extractors to retrieve data from R/3 you will end up with much more then what you 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. etc.

This obviously also leads to errors. Many BW resources do not have an understanding of the processes in R/3. it is also very costly. Do not implement the software because you believe that you have paid for it.Struggle – Reason # 6 – the BI specialists Finding skilled BW resources is not only difficult. Rest assured for BW it will be no different. Most likely you reached a point there when you thought 'how much more is this gonna take'. So. © 2008 NewFrontiers Group (Author: Arno Luijten) Page 6 of 7 . Famous last words Do not believe that a BW implementation is easy. however funny this may sound. 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. often SAP BW consultants and SAP ERP consultants do not understand each other. By the time you are having second thoughts on your choice there is almost no way you can have a graceful retreat. unnecessary delays and projects running out of their budgets. The biggest cost is implementing BW and keep it running. 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.

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. 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. He has been very successfull implementing solutions for SAP. At that time he was IT manager at Ascom Banking Automation Netherlands were he was responsible for the implementation of SAP R/3. Never underestimating the effort always open and upfront to his clients. © 2008 NewFrontiers Group (Author: Arno Luijten) Page 7 of 7 . Epson and Unilever. 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. The people that sold SAP never addressed the topic specifically. The shock came when the “SAP basis guy” handed in the specification. One of his favorite stories ‘SAP stories’ is based on what he experienced when he had to order the hardware. 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). Based on his earlier experience with the implementation of transaction software he put an estimate in the budget.About Arno Luijten Arno Luijten first experience with SAP is from the mid 90’ies. 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.

You're Reading a Free Preview

Download
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->