One of the hardest tasks in developing a reporting environment in R/3 is selecting one data access and analysis tool that satisfies end-user needs. The following are the major shortfalls of native SAP R/3 reporting:
• Information on existing reports is either missing or unclear. Searching a report among thousands of available reports in R/3 is a big problem. The Report Navigator, developed by SAP's Simplification Group, is a good attempt to solve this problem.
• Available reports are designed to meet operational and transactional information needs. Most reports are predefined, list oriented, and provide very limited OLAP functionality.
• Several reporting modules and associated reporting tools make it hard to select a specific tool. Reporting tools are inconsistent, and designing reports is a complex process. Maintenance of thousands of reports for software upgrades is a huge challenge. Knowledge of how often a report is used is not available, such as which reports are frequently used or ever used. As a consequence, all reports need to be maintained regardless of their usage. Recently, SAP has provided utilities to track report-usage statistics that will help identify which reports are to be upgraded or dropped in a release upgrade or support.
• Fragmented reporting menu access requires extensive end-user training to navigate through several multi-level menus to display a few reports.
• Performance impact on R/3 OLTP operations due to reporting is another major issue. The R/3 systems are configured to provide high OLTP transaction rates. Building a robust reporting and OLAP environment under an OLTP environment requires different configuration parameters that will degrade OLTP operations. See Table 2-1, which lists the common differences between OLTP and Reporting/OLAP environments.
To overcome OLTP and reporting co-existence problems, several customers have attempted to build a separate R/3 environment dedicated to reporting. I discuss a few such models in the next section. But first, I'd like to look at how SAP planned to re-architect R/3 application components in the early '90s.
Application architects at SAP planned to break down the traditional SAP R/3 very tightly integrated application modules into several loosely coupled applications; these applications would still be connected to each other by use of Application Link Enabling (ALE) technology (ALE is SAP's EDI-like middleware. I discuss ALE in much more detail in the next few sections.). This new distributed application concept became what is known as SAP Business Framework Architecture, as shown in Figure 2-4. Due to the mySAP.com initiative, the SAP Business Framework today looks quite different from when it was proposed in the early 1990s, as shown in Figure 2-4.
However, the core concept behind the SAP Business Framework remains the same-loosely coupled business components. The only difference is that today the integration technologies are becoming Internet-centric, replacing pure ALE and new business components to support business to business (B2B), business to customer (B2C), Customer Relationship Management (CRM), and business intelligence, and have taken higher priority than breaking SAP R/3 modules into individual stand-alone applications.
Login to add comments on this post.