Comparingof SAP R/3 Reporting Systems
Common feature among R/3 reporting systems is that they all collect data in special data tables. This is a preferred method for operational reporting due to real-time data acquisition from linked SAP modules. Several reporting systems derive data based on update rules.
External data can also be imported in the reporting information structures for consolidated information view.
These information systems use a variety of tools for presentation and analysis such as ABAP, ABAP Query, Report Writer/Painter, and LIS.
All information systems require in-depth R/3 configuration knowledge.
This is the most important reason that reporting requirements must be a part of overall OLTP business workflow-business rules.
Using linked SAP modules requires absolute integration with process configuration teams. The process requirements must be stable, because the workflow determines what data is captured based on a variety of states and conditions defined to meet business operations and analysis requirements.
SAP R/3 is primarily designed for a high transaction rate. Information processing in an OLTP and a data warehouse are very different. A few differentiating characteristics between an OLTP and a data warehouse are listed in Table 2-1. Data warehouses require a very different configuration due to large data volume and unpredictable data navigation schemes. It is impossible to configure an OLTP system as a full-featured data warehouse without having an impact on OLTP operations. Therefore, the nature of reporting on OLTP systems must be limited to support real-time operations and not historical reporting. The next section addresses reporting issues associated with R/3 information systems.
Limitation of SAP R/3 Reporting Systems
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.
No comments:
Post a Comment