Comparing
Content
Comparing/Limitation of SAP R/3 Reporting
Systems
Comparing/Limitation of SAP R/3 Reporting Systems
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.
Systems
Comparing/Limitation of SAP R/3 Reporting Systems
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.
