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
- SAP Managed Tags:
6 Comments
