SAP system users have had the ability to run an embedded SAP BW system inside SAP ERP Central Component (ECC), starting with SAP NetWeaver 7.0; Suite on SAP HANA; and SAP S/4HANA. See how to use this capability (since it is included in your SAP transactional licenses) with minimal pain and cost.
Key Concept
Although an embedded SAP BW system in an ERP environment is not meant to replace an enterprise data warehouse (assuming there is a need for one), it can serve some enterprise analytical needs with limited time, effort, and cost.
A couple of years ago, an SAP professional that I hold in high esteem excitedly told me that when he had erroneously run transaction code RSA1 in an SAP ERP Central Component (ECC) system (running SAP NetWeaver 7.3) instead of the SAP BW system, he was surprised to find that he was able to access the Administrator Workbench in the ECC system. It really should not have been a surprise because inside every ERP system (running SAP NetWeaver 7.0 and higher) an SAP BW system resides. This person’s apparent discovery led me to think that if such an SAP-savvy person had merely stumbled upon this, it is likely that not too many people are aware of it. My own experiences over the last few years bear testimony to the general lack of awareness on this topic.
So let’s start with the basics:
- Since SAP BW (the traditional flavors and not SAP BW/4HANA) is built on the same SAP NetWeaver platform as the ERP application or Business Suite, all the SAP BW building blocks are available on any SAP NetWeaver-based system (7.0 and above)
- If your organization has purchased ERP licenses, there is no extra cost to using embedded SAP BW
- Your embedded SAP BW application resides in the same system and instance in which your ERP application resides. It is not a separate SAP BW installation and is part of your SAP NetWeaver installation. That is why it is called embedded.
- The availability of and accessibility to embedded SAP BW do not depend on the database on which your applications are running. Regardless of whether you are running on Oracle, SAP HANA, or some other database, you can use embedded SAP BW.
- The availability of embedded SAP BW extends all the way to SAP S/4HANA. It comes bundled with SAP BW 7.5.
Technical Overview
Embedded SAP BW is an umbrella term for all the SAP BW functionality that exists inside an SAP NetWeaver system starting with 7.0. The features available in embedded SAP BW correspond to the SAP NetWeaver version, so an SAP NetWeaver 7.3 system has an embedded SAP BW 7.3 version.
What happens when you try to access the Data Warehousing Workbench (transaction code RSA1) in an SAP NetWeaver system? You get a clean slate, meaning there is no activated business content available to you and you have to activate it. Figure 1 shows the business content of an SAP NetWeaver 7.4 system running ECC 6.0 with enhancement package 7 at a summarized level. Note that what is available to you depends on your version and Support Package level.
Figure 1
Business content in embedded SAP BW in an SAP NetWeaver 7.40 system
Since SAP S/4HANA has an SAP BW 7.5 system embedded in it, the type of SAP BW building blocks that you have available, such as Advanced DataStore objects (ADSOs) or CompositeProviders, is quite different from the building blocks you find in an SAP BW system embedded inside an SAP NetWeaver 7.0 system. Figure 2 displays the Financials InfoArea of the Modeling/InfoProvider view of the Data Warehousing Workbench in an SAP BW system embedded in an SAP S/4HANA system. Note that a lot more embedded SAP BW business content is available in SAP S/4HANA.
Figure 2
Financials SAP BW business content in an SAP S/4HANA system
How to Use Embedded SAP BW
Let’s look at some of the primary ways in which you can use embedded SAP BW.
Strongest Use Case
SAP Business Planning and Consolidation (SAP BPC) Optimized for SAP S/4HANA is possibly the strongest use case for the embedded SAP BW engine. In this flavor of SAP BPC, you combine the capabilities of integrated planning with SAP HANA all inside one instance, thus eliminating the latency that is inherent in the conventional extract, transform, load (ETL) and extract, load, transform (ELT) approaches typical to the traditional separation between a transaction-based system (like SAP ERP) and a data warehousing system (like SAP BW). Here are some uses of SAP BPC Optimized for SAP S/4HANA:
- Integrated planning across the enterprise in a shared transactional system
- Unrestricted access to the most granular level of transactional and plan details
- A single version of the truth for operations and finance
- A reduction in batch jobs via real-time processing
- A reduction in the data footprint by eliminating data redundancies
- Accelerated system response times on real-time information
- Robust calculations, allocations, and simulations for quicker insights
- More external data integration options with SAP internal data
- Business function and predictive analysis libraries for more advanced modeling
- Pre-delivered content and data mappings to reduce implementation times
- Modern user experience and use of Microsoft Excel to facilitate adoption and productivity
- Web-based data visualization and dashboarding options to speed up discovery
In terms of pre-delivered content, in addition to the virtual InfoProviders that SAP provides for this version of SAP BPC, it also gives you multiple Microsoft Analysis for Office workbooks for planning that you can either use out of the box or as templates for customization. I have found this feature useful and often advise clients to start off with these templates and not reinvent the wheel. Figure 3 is a partial view of the various workbook templates that are available.
Figure 3
Analysis for Office workbooks for planning as part of SAP BPC for SAP S/4HANA
These workbooks cover major planning categories, such as cost center, profit center, and market segment planning.
Note
You need to determine whether your current licensing agreement with SAP covers use of SAP BPC for S/4HANA.
Limited Analytical Reporting Needs
Many SAP system users have limited analytical reporting needs. Most of their analytical needs are fulfilled by using Excel spreadsheets. There is therefore no compelling need for a separate system, especially since there is a non-trivial cost associated with it. Let’s say your company’s flagship product is a virtual monopoly, your customer base is predictable, and so is cash flow. Your analytical reporting needs are probably limited to basic accounts receivable/aging analysis and days sales outstanding. You can realize that with embedded SAP BW since the underlying business content to support your analytical needs, such as InfoObjects, InfoCubes, and DSOs, are already available in your ERP system. This can then be married to the transactional data that resides in the ERP tables.
If your embedded SAP BW system is version 7.3 or higher, you can leverage the concept of virtual providers to access data residing in your ERP tables in real time. How so? Since virtual providers do not store any data, but are the conduit between your query and the source of your data (and are also relatively simple to set up), all you need to do is to ensure that your virtual provider points to the correct source of data in your ERP system. Figure 4 displays the options available when you create a virtual provider.
Figure 4
Create a virtual provider
The simplest way to leverage transactional data via embedded SAP BW is to use the option Based on Data Transfer Process for Direct Access. The only caveat here is that the data source needs to be a direct access data source.
Note
Although virtual providers work better with smaller quantities of data, they can scale well if your company is running Suite on SAP HANA because even if you have large data volumes, the SAP HANA engine ensures that performance is not affected despite the fact that you are basically treating a transactional system as a data warehouse.
Minimal Need for a Data Warehouse
A lot of conversations and decisions around analytics and BI assume the need for a data warehouse. This conventional approach puts the cart before the horse. A data warehouse should not be considered a prerequisite for an effective analytics framework. It should be your data and analytical reporting needs that drive the decision for a data warehouse.
Although purists tell you that you should not combine analytical and operational reporting in a single system and that you should have separate systems for each, today a lot of organizations are questioning the wisdom of the traditional enterprise data warehouse. Improvements made in the area of data compression and in-memory computing have alleviated the primary pain point of establishing and maintaining data warehouses: latency. The ETL or ELT paradigms are the bread and butter of a data warehouse.
Unfortunately, these paradigms have perennially been the root cause of latency as enterprises increasingly require real-time data for real-time analytics. The rise of SAP HANA has forced companies to consider how they can effectively leverage its capabilities to deliver real-time analytics on large volumes of data. SAP HANA Smart Data Access (SDA) allows you to virtually combine data from disparate sources for SAP HANA. Since data volume is not an issue with SAP HANA, you can store large volumes of data in an SAP HANA database without needing to set up a separate data warehouse.
SAP S/4HANA takes this a step further with embedded analytics. It uses virtual data models (VDM) and Core Data Services (CDS) to enable real-time analysis of transactional data in the source system. Embedded analytics blurs the line between operational and analytical reporting. Strategically, you can still consider embedded analytics as the high-performing application for real-time operational reporting. Embedded SAP BW can then be a complement to embedded analytics by enabling analytical reporting.
A Stepping Stone for a Full-Blown SAP BW Implementation
Embedded SAP BW can be a stepping stone for a full-blown SAP BW implementation. For enterprises that do not have SAP BW (or any other data warehousing solution) in their landscapes, but would like to assess and evaluate their need for a data warehousing solution over time, going with embedded SAP BW would be a most pragmatic approach. You could use your host ERP system as a stepping stone and sandbox for not only getting familiar with SAP BW but also kicking the tires based on emerging analytical reporting needs.
One of the key advantages of this approach is that your investment is limited. If you do not want to transition into a separate SAP BW implementation, your sunk cost is a small fraction of what you would spend if you were to set up a separate SAP BW sandbox. This is an aspect I have highlighted to my clients that are in an early stage of their analytics journey.
Let me go a little deeper into the kicking-the-tire aspect by providing you with some relevant recommendations:
- Activate specific SAP BW demo content (which is part of standard SAP BW Business Content) in areas of importance to your organization and populate the relevant objects with a limited amount of dummy data
- Use the BEx Query Designer to design a couple of queries on your InfoProviders. This functionality gives you a good sense of the various components of a query.
- Use BEx Analyzer to consume the results and become familiar with the slicing and dicing capabilities in SAP BW
- Use various consumption options for your BEx query. Look at the options in Figure 5 under the Release for External Access section.
Figure 5
Consumption options for your BEx query
If you check the first check box, you are making your query available for reuse by online analytical processing (OLAP) providers and consumers. For instance, if you have SAP BusinessObjects available in your enterprise, you can now connect your query to BusinessObjects tools and take advantage of advanced analysis and visualization. If you check the second check box, you are enabling access to your query via web services. By checking the third check box, you are creating an Open Data Protocol (OData) service that enables your developers to do advanced development in a variety of technologies such as JavaScript Object Notation (JSON) and XML.
Once you have gained a good understanding of the key pieces of SAP BW, realize a use case relevant to some important area of the business that involves some data modeling, transformations, and query design.
Considerations and Constraints
I have showed an example of using embedded SAP BW in your organization. I would also like to alert you to some considerations and constraints you need to keep in mind:
- An embedded SAP BW environment is not to be treated as a substitute for a full-blown enterprise data warehouse or even a data warehouse within your ERP environment. At most, it is a capability that you have paid for and can make some use of.
- SAP recommends that data stored in your embedded SAP BW environment should not exceed 20 percent of the total data in the host ERP system. I believe SAP is encouraging use of the ECC system for what it was best designed to do – transaction processing. On the other hand, the data volume constraint becomes a less compelling argument when you have SAP HANA as the underlying database.
- SAP recommends using a separate client for your embedded SAP BW activities.
- As you peel the layers of the onion of your embedded SAP BW system, you may discover aspects or issues that were not previously detected or known. Note SAP’s overarching caveat not to use this environment as a full-blown enterprise data warehouse.
- If you have an existing SAP BW landscape, it may be inadvisable for you to consider jettisoning it in favor of embedded SAP BW without doing a detailed analysis of use and operational costs. Embedded SAP BW is a much better alternative for companies that have not yet embarked on their SAP BW journeys and are looking for an economical way of getting started. It can also be a viable option for companies that are migrating to SAP S/4HANA (and have had SAP BW running in their organizations), but are now looking to determine the necessity of running a separate SAP BW landscape.
Anurag Barua
Anurag Barua is a principal at TruQua Enterprises. He has 23 years of experience in conceiving, designing, managing, and implementing complex software solutions, including nearly 18 years of experience with SAP applications. He has been associated with several SAP implementations in various capacities. His core SAP competencies include FI and Controlling (FI/CO), logistics, SAP HANA, SAP BW, SAP BusinessObjects, Enterprise Performance Management, SAP Solution Manager, Governance, Risk, and Compliance (GRC), and project management. He is a frequent speaker at SAPinsider conferences and contributes to several publications. He holds a BS in computer science and an MBA in finance. He is a PMI-certified PMP, a Certified Scrum Master (CSM), and is ITIL V3F certified.
You may contact the author at
Anurag.barua@truqua.com.
If you have comments about this article or publication, or would like to submit an article idea, please contact the
editor.