SAP BOBJ on SAP BW – What tool do I choose as a developer?
With the release of Business Objects 4.0 (BI 4.0), the ability to leverage SAP BW data via the recommended BICS connection makes it very easy to dive in and start building reports. However a few things must be kept in mind before choosing the right tools to use. While there are many tools available within the BI 4.0 suite, Web Intelligence (Webi), Analysis for OLAP, Analysis for Excel and Crystal Reports Enterprise will generate significant amount of use among traditional reporting users when using SAP BW for your data warehousing needs.
If you are running SAP BW the recommended method of sending content to BI 4.0 is through the development of BeX queries which leverage the BICS connection for direct access to the data instead of a ‘functional’ access. There are many articles out there on SCN on why this is the best approach. This blog post however will focus on the best way to position Webi, Analysis and Crystal Reports Enterprise when you are running SAP BW (7.0 or above) as your data warehouse and using BeX queries. Although there are many different takes on this subject the basic driver for this post is when implementers are faced with the question “What is the best way to deliver BW content using BOBJ for my client?”
The first step is to look at different reporting capabilities your client would require or expect. I have come up with the following ones to encompass the overall reporting landscape with some conditions to describe them.
Summary & Informational Reporting:
1. Quick snapshot view of data based on date or other prompts
2. Users may choose to add additional fields (the ones the developer makes available) on their own (guided analysis)
3. Uses a standard for consistent presentation of information
4. Advanced numerical and string calculations can be performed on the fly
5. Minimal user interaction with report, views are very summarized
6. Can be used as official documents with formatting
7. Report data cannot exceed over 1 million cells (rows * columns)
Drill-Down Reporting & Ad-hoc Reporting
1. Users will create their own ‘reports’ and ‘analysis’ based on different data fields or other reports
2. Requires some data source and meta-data knowledge
3. Highly intuitive with drag/drop capability and faster response time
4. Basic numerical calculations on the fly
5. When OLAP type of reporting needs to be leveraged
6. Faster drill-down to detail capability
7. Formatting options are very limited, focus on analysis not presentation
Detailed Operational Reporting
1. Detailed level of transactional data is presented instead of summary
2. Report is run on a frequent basis and it usually based on time conditions (weekly, monthly, yearly)
3. Needs to be distributed, printed, stored, and kept on file
4. Reports are usually run as is with minimal prompts
5. No ad-hoc calculations are needed, all calculations must be pre-built
6. Can be used as official documents with formatting
7. Reports are usually longer in vertical and horizontal length
The next step is identifying the level of interaction the users are expected to do using the reports. It is important to understand the different ways a particular data set can be used. A data set containing dunning information for example can either be used to view counts of customers at various levels (summarized) or it can be used to pin-point a select group of customers with a certain dunning level who require a follow-up based on the address information displayed for those customers. A simple T-shirt size model to represent High, Medium and Low degrees of report interaction will suffice at this point.
Finally we proceed to the type of users who will consume the data. To keep things simple and applicable to different industries and organizations we can group users under the following buckets:
Business Analysts
This is the group responsible for finding the answers in the data.
Managers
This is the group responsible for using the data findings to help execute decisions.
Transactional System Staff
This broad based group is anyone who is familiar with the transaction systems and helps generate the data. This could include front level staff, CRM agents, CSRs, account processors, payment processors etc.
Taking all this into consideration we can generate the following table to position the product against reporting capability, degree of interaction and the user groups.
The above positioning table can help choose the right product for your reports with attention paid to the reporting capability, the degree of interaction and the user groups. Sometimes it is a matter of adjusting and revisiting your BeX development to help fit the BI 4.0 report on this table. And feel free to change up the degrees of interaction across different groups. For example consider if there are managers who have a ‘high’ degree of interaction with their reports.
What are some techniques you use to pick the right BOBJ tool? I would be interested in looking at other point of views on this subject.
Som Suresh
Submitted March, 1, 2013
Thank you for this entry. Very helpful.
Thank you for your comment Chad.
Good posting Somnath,
One small question for your comment below,
For formatted report using WEBI, Dashboard design(or whaever, BOBI4.0), do you think BEX Query would be essential as a data source?
What about BW Cube ?
The reason why I'm asking you is that from a TCO point of view.
BW Cube, as a data store, and creating Bex query for reporting, however, one more creating report using WEBI for another way of presentation?
I 'm well aware of using bex query as a data source for WEBI, (e.g. CK, variable, authorization), however, one of my client is still asking me about 'without bex query' .
Well SAP recommends that if you have BW that you use the BICS connectivity available by directly connecting to Bex Queries. There are ways to build a universe but unfortunately you do need Bex as the 'middle' layer if you are using BW cubes. Naturally this changes with HANA but assuming you don't have HANA and you use traditional SAP BW you will definitely need Bex queries to send data to your Business Objects front end.
Hi Thanks for sharing information.
My question is Who needs to go to beyond the metrics to identify root causes and identify the impact of results and trends. They need the ability to dig into data with ad-hoc reporting and analyze to understand the how and why?
-- Executives and Managers or Business Analysts ?
Who have been traditionally under-served by business intelligence tool, which in many cases are only adopted by power users?
-- Executive and Managers or Business Users or Business Analyst ?
Beyond the metrics is reserved for Business Analysts usually but that brings me up to your next question. I feel executives are under served by a lot of BI solutions. Solutions should be easy enough even for executives to perform action based on any insight they get from metrics. Maybe instead of pure self-service solution for executives we need to be thinking about building 'managed solutions'