ERP with SAP – what does the Customer need?
A new SAP Customer has successfully introduced the R/3 system. He is pleased about
the fact configurability and flexibility of SAP. He looks forward to thousands of report
for any kind of evaluations. What is the name of that report, that showed all data in the
system at a mouse click? This was his favorite report from the times of the previous system.
Turns out, it doesn’t exist in SAP. But why?
The highest priority of the SAP systems – performance
The most important SAP concept - all data in the database are available to all
modules - creates enormous advantages for the customer, but also a disadvantage:
today's database systems are not scalable. Therefore one must deal very carefully
and economically with this resource. All standard SAP Applications are built in a way,
to avoid extreme system loads. The principle is simple: the more complex the data selection,
the stricter the constraints, that need to be entered on the selection screen. And only
certain important data is stored for Enterprise reporting in the form of sum-records and
appear in reports pre-defined by SAP.
Customer data and SAP report fields
The data from most important standard fields are thus stored in a cumulated
form and can be used in the reports. But where does the customer store his specific data?
SAP offers a broad spectrum of possibilities, from APPEND structures to variant
configuration. When choosing the storage method some implementation partners neglect
later accessibility of the data. The ease of access of the data should is however
central to the storage decision.
First ADD ONs for the cusomer reporting - quick and dirty
It may not appear very important, but already in the implementation phase some
reports are built by principle SELECT * FROM [ Tablejoin ] and seem to work quite well.
Of course in that phase the customer only has little data in his database. The real
problems surface later. Even the corporate goals can suffer, because of employees,
who start badly written reports too often and thus place extreme load on the database.
Is then strategic reporting possible without SAP BW?
With standard means - no, with correct ADD ONs - only possible, if the data is accessible.
Consider the following example:
a customer needs a report, to shows all batches that were
produced on the assembly-line ABC. If the value ‘ABC’ is stored as a variant attribute,
then it is not possible to create such report. The report would need to fetch and evaluate
all the batches from the database, which would place an extreme strain on the database and system.
In this case an optimization analysis could show, that it would be much better to store the
‘ABC’ attribute in an APPEND structure.
How does one design such ADD-ONs correctly?
Much depends on the quality of the ABAP Consultant. A strategic SAP report should be
planned and restricted carefully. Normally the user needs only certain data - a list of
over 10.000 pages is quite useless for him. An experienced consultant knows that and always
uses clear rules, which require the user to limit the selection by criteria to a reasonable extent.
For reports, which require cumulating over several millions data records, other optimization
approaches are appropriate. The SAP Infosystem offers many possibilities to collect the necessary
data in advance, using its flexible updating rules. There the intermediate data can be collected
without any performance losses (V2 updates). If access to the large SAP tables is unavoidable,
as for instance with CO reporting, it is to be examined, whether the existing table indices
are selective enough and whether index access makes sense at all.
(More to it - SAP training course documents BC414). There are also certain techniques of the
programming that can accelerate handling of very large data sets by up to factor 100.