(SAP Excellence) Professor Dr. Hans-Jürgen Appelrath, Dipl.-Inform. Jörg Ritter (Auth.) - SAP R - 3 Implementation - Methods and Tools-Springer-Verlag Berlin Heidelberg (2000)

SAP Excellence
Series editors:
Prof. Dr. Dr. h.c. Peter Mertens,

Universitat Erlangen-Niirnberg
Dr. Peter Zen eke,

SAP AG, Walldorf
Springer-Verlag Berlin Heidelberg GmbH
Hans-Jiirgen Appelrath
Jorg Ritter
SAP R/3 Implementation

Methods and Tools
With 48 Figures
and 5 Tables
, Springer
Professor Dr. Hans-Jiirgen Appelrath
Institut OFFIS
Escherweg 2
26121 Oldenburg
Germany
Dipl.-Inform. Jorg Ritter

ose GmbH
Industriestr. 11
26121 Oldenburg
Germany
ISBN 978-3-642-08612-0
Library of Congress Cataloging-in-Publication Data
Die Deutsche Bibliothek - CIP-Einheitsaufnahme
Appelrath, Hans-Jiirgen: SAP R/3 Implementation: methods and tools; with 5 tables 1 Hans-
Jiirgen Appelrath; Jorg Ritter.
ISBN 978-3-642-08612-0 ISBN 978-3-662-04038-6 (eBook)
DOI 10.1007/978-3-662-04038-6
This work is subject to copyright. All rights are reserved, whether the whole or part of the
material is concerned, specifically the rights of translation, reprinting, reuse of illustrations,
recitation, broadcasting, reproduction on microfilm or in any other way, and storage in data
banks. Duplication of this publication or parts thereof is permitted only under the provisions
of the German Copyright Law of September 9, 1965, in its current version, and permission
for use must always be obtained from Springer-Verlag. Violations are liable for prosecution
under the German Copyright Law.
© Springer-Verlag Berlin Heidelberg 2000
Originally published by Springer-Verlag Berlin Heidelberg New York in 2000
Softcover reprint of the hardcover 1st edition 2000
The use of general descriptive names, registered names, trademarks, etc. in this publication
does not imply, even in the absence of a specific statement, that such names are exempt from
the relevant protective laws and regulations and therefore free for general use.
Hardcover-Design: Erich Kirchner, Heidelberg
SPIN 10754025 42/2202-5 4 3 2 1 0 - Printed on acid-free paper
Preface
Manufacturers of standard business software products, such as SAP AG, promise

users a faster realization of their requirements for establishing modern business
information systems compared with custom-written software. The vision: The
software product - in this case Rl3 - is actually already "complete" and "only"
needs to be implemented customer-specific for each company. However, on
account of the complexity of the Rl3 system with several million lines of program
code and more than 10,000 tables with their almost unlimited number of
application and customer-specific settings (parameterization), many observers
consider that the implementation requires just as much effort, cost and unknown
factors as the realization of one-off software.
The reduction of the undoubted complexity of an Rl3 implementation requires a
well-considered procedure with support from the appropriate software tools. SAP
provides here the so-called ASAP method as implementation roadmap and a
number of useful tools for these individual phases and their work packages.
Despite these offerings, the employees who perform or are affected by an Rl3
implementation will be initially confronted with many new terms and concepts
that complicate the understanding of the Rl3 world, the compliance with the
procedure model, and the use of the associated tools.
This book addresses these problems: It provides a compact but well-grounded
introduction to the Rl3 terminology. Chapter 1 builds on the well known concepts
from computer science and business data processing to discuss several technical
principles, and important components and capabilities of the Rl3 system. Chapter
2 introduces concepts and questions associated with the procedure for the
application system development. Chapter 3 builds on this to explain the tasks and
methods associated with the Rl3 implementation accompanying the SAP
Implementation Roadmap phases. Chapter 4 provides a more detailed discussion
of the Roadmap tools that support the Rl3 implementation.
Because there are hardly any systematic investigations concerning Rl3
implementation problems and the continuing fast further development of the Rl3
system would in any case soon render the presented methods and tools obsolete,
we have intentionally omitted a complete assessment of them. This book
concentrates on providing a compact description of the problems associated with
the implementation, and those methods and tools the SAP provides to solve them.
The audience of this book: We expect that it will be read by project leaders and
interested team members before or at the start of an Rl3 implementation, and that
it will serve as reference in the subsequent phases. Specifically, this book should
answer the question "Who must perform which activities and when during an Rl3
implementation and what tools can they use?". The book should also serve as the
VI Preface
accompanying literature for lectures at universities and polytechnics, in particular

for practical exercises and project groups.
The (classic) software engineering as a scientific discipline has not yet paid
sufficient attention to the questions of the development, implementation and
maintenance of standard software products such as Rl3. Traditionally, software
engineering concentrated on custom-written software. The procedure models and
CASE tools established for this environment are not suitable for the
implementation ("customizing") of standard software. There exists almost no
specialized method and tool theory for such implementation and maintenance
processes. This is especially surprising as the System Rl3 alone with
approximately 20,000 installations (status as at the beginning of 1999) is such a
widely-used product. The pursuit of this topic would not only be of scientific
appeal, but would certainly receive broad interest in practice. Perhaps universities
and research institutes will soon find more interest for such questions.
The dynamism of the Rl3 system places a challenge for every author. The rapid
changes in the details of the procedure model and, in particular, the supporting
tools, possibly make the half-life of some information in a book short. However,
we wish to achieve a certain depth of information and not remain too general and
abstract on the "surface". Our concrete system and tool-related statements apply to
Rl3 release level 4.0B, and Version 4.0 (December 1998) for the ASAP method.
We make explicit references to any important further developments present in
newer versions.
Complex software for changing operational conditions, in particular for a
product like Rl3, is not just simply implemented and then remains in a stabile
state. Consequently, all ideas about a completed activity or a term such as
"business process optimization" (as if there could be a suitable metric and a stabile
optimum) are misleading. However, we have restricted ourselves to the complex
implementation process, in the knowledge that the importance of topics like
"Continuous Engineering" will be discussed later in an appropriate book from
"SAP Excellence" series. The following books have already been published in this
series:
• Appelrath, Hans-Jiirgen; Ritter, Jorg: SAP Rl3 Implementation - Methods and
Tools
• Becker, Jorg; Uhr, Wolfgang; Vering, Oliver: Retail Information Systems
based on SAP Products
• Buxmann, Peter; Konig, Wolfgang: Inter-Organizational Cooperation with
SAP-Systems - Perspectives on Logistics and Service Management
• Knolmayer, Gerhard; Mertens, Peter; Zeier, Alexander: Supply Chain
Management based on SAP-Systems. Order Processing in Manufacturing
Companies
A feature of all these books, including this one, is that SAP AG employees
have checked the correctness of technical statements with regard to their
applicability to the current software.
At this point we would like to thank the partners who cooperated with us on
Rl3-related projects, and the employees at OFFIS (Olden burger Forschungs- und
Preface VII
Entwicklungsinstitut fUr Inforrnatik-Werkzeuge und -Systeme). They all provided

us with competent support for the creation and correction of the manuscript. In
particular, we would like to mention Mr. Klaus Meyners (KPMGConsulting
GmbH) and Messrs. Andreas Bartelt, Guido Schimm, Alexander Scharnofske and
Thorsten Teschke from OFFIS, all of whom contributed to this book. We would
also like to thank Mr. Michael Erhardt as the SAP contact partner who supported
us with our questions and in manuscript. Finally, we would like to express
appreciation of the support from Springer Verlag for the fast publication and
ensuring this English translation for the international market.
A final comment: Because of the effort involved, we do not provide a
monitored Website for this book. However, it contains many references to relevant
URLs, and possibly there will be a second edition, for which we can then provide
this service when we have support.
Prof. Dr. Hans-Jiirgen Appelrath Dipl.-Inforrn. Jorg Ritter
OFFIS OSCGmbH
Escherweg 2 Industriestr. II
D-26121 Oldenburg D-261210Idenburg
Germany Germany
appelrath@offis.de ritter@o-s-c.de
Table of Contents
PREFACE ......................................................................................................... V
1 BUSINESS APPLICATION SYSTEMS ..................................................... 1

1.1 INTRODUCTION ......................................................................................... 1
1.1.1 Enterprise Architecture .................................................................... 2
1.1.2 Standard Software ........................................................................... 3
1.1.3 Integration of Software ................................................................... .4
1.2 TASKS AND BUSINESS PROCESSES ............................................................ 5
1.2.1 Tasks ................................................................................................ 5
1.2.2 Business Processes .......................................................................... 6
1.3 ARCHITECTURES ..................................................................................... 12
1.3.1 Multi-level Client/Server Architectures ......................................... 12
1.3.2 Relational Database Systems ......................................................... 17
1.3.3 Object-oriented Architectures ........................................................ 20
1.4 THE Rl3 SYSTEM .................................................................................... 23
1.4.1 Client/Server Architecture of the Rl3 System ................................. 23
1.4.2 Internet Connection ...................................................... ................. 30
1.4.3 Components of the Rl3 System ...................................................... .32
1.4.4 Function-related Components ....................................................... 33
1.4.5 Cross-Function Components ......................................................... 37
1.4.6 System Components ....................................................................... 38
1.4.7 ABAP/4 Development Workbench ................................................ .40
1.4.8 Organizational Structures of the Rl3 System ................................ .43
1.4.9 Rl3 Reference Model. ..................................................................... 46
2 PROCEDURE MODELS FOR THE APPLICATION SYSTEM
DEVELOPMENT ....................................................................................... 51
2.1 DEVELOPMENT AND IMPLEMENTATION .................................................. 51
2.1.1 Development of Standard Software Systems .................................. 51
2.1.2 Tasks of the Development and Implementation ............................. 53
2.1.3 Adaptation ..................................................................................... 57
2.2 SOFTWARE DEVELOPMENT PROCESSES AND PROCEDURE MODELS ........ 60
2.2.1 Phase Model .................................................................................. 60
2.2.2 Extended Phase Models ................................................................. 62
2.2.3 Classification of the Rl3 Implementation ....................................... 63
2.3 SAP PROCEDURE MODELS ..................................................................... 64
2.3.1 AcceleratedSAP - The Accelerated Rl3 Implementation ............... 64
X Table of Contents
2.3.2 Additional Roadmaps..................................................................... 65

2.4 TOOLS FOR THE IMPLEMENTATION AND DEVELOPMENT ........................ 65
2.4.1 Function-related Tools .................................................................. 65
2.4.2 Cross-Function Tools .................................................................... 67
3 THE IMPLEMENTATION ROADMAP ................................................. 69
3.1 PHASE 1: PROJECT PREPARATION ........................................................... 70
3.1.1 Initial Project Planning ......................................................... ........ 71
3.1.2 Project Procedures ........................................................................ 77
3.1.3 Project Kickoff............................................................................... 82
3.1.4 Technical Requirements Planning ................................................. 82
3.1.5 Quality Check Project Preparation Phase .................................... 83
3.2 PHASE 2: BUSINESS BLUEPRINT ............................................................. 83
3.2.1 Business Blueprint Project Management ....................................... 84
3.2.2 Training of the Business Blueprint Project Team .......................... 85
3.2.3 Develop System Environment ........................................................ 85
3.2.4 Business Organization Structure ................................................... 88
3.2.5 Business Process Definition ........................................................... 90
3.2.6 Quality Check Business Blueprint Phase ....................................... 94
3.3 PHASE 3: REALIZATION .......................................................................... 94
3.3.1 Project Management Realization Phase ........................................ 95
3.3.2 Project Team Training Realization Phase ..................................... 96
3.3.3 Baseline Configuration and Confirmation ..................................... 96
3.3.4 Final Configuration and Confirmation .......................................... 98
3.3.5 System Administration ................................................................. 100
3.3.6 Development of Data Conversion Programs ............................... 101
3.3.7 Development of Application Interface Programs ........................ 101
3.3.8 Development of System Enhancements ...................................... .. 102
3.3.9 Create Reports ............................................................................. 103
3.3.10 Create Forms ............................................................................... 104
3.3.11 Establish the Authorization Concept .......................................... . 104
3.3.12 Establish Archiving Management .............................................. .. 106
3.3.13 Final Integration Test .................................................................. 106
3.3.14 End User Documentation and Training Material ........................ 107
3.3.15 Quality Check Realization Phase ................................................ 108
3.4 PHASE 4: FINAL PREPARATION ............................................................. 108
3.4.1 Project Management Final Preparation ..................................... . 108
3.4.2 End User Training ....................................................................... 108
3.4.3 System Management .................................................................... 109
3.4.4 Detailed Planning for Cut-Over and Support .............................. 110
3.4.5 Cut-Over ...................................................................................... 111
3.4.6 Quality Check Final Preparation Phase ...................................... 111
3.5 PHASE 5: Go LIVE AND SUPPORT ......................................................... 111
4 TOOLS ....................................................................................................... 113
4.1 TOOLS IN THE Rl3 IMPLEMENTATION ENVIRONMENT ........................... 113
Table of Contents XI
4.2 IMPLEMENTATION ASSISTANT .............................................................. 114

4.3 MSPROJECT ........................................................................................ 116
4.3.1 Basic Principles ........................................................................... 116
4.3.2 Project Plans for the Rl3 Implementation ................................... 117
4.3.3 Adaptation of a Project Plan ....................................................... 118
4.4 QUESTION & ANSWER DATABASE ....................................................... 119
4.4. I Overview Questions for the Enterprise ........................................ 120
4.4.2 Process Hierarchy ....................................................................... 121
4.4.3 1ssues Database ........................................................................... 126
4.4.4 Business Process Master List....................................................... 127
4.4.5 Outlook ........................................................................................ 127
4.5 STRUCTURE MODELER ......................................................................... 128
4.6 CONCEPT CHECK TOOL ........................................................................ 129
4.7 BUSINESS NAVIGATOR ......................................................................... 130
4.7.1 Navigation in the Rl3 Reference Model... .................................... 130
4.7.2 Process Hierarchy ...................................................... ................. 130
4.7.3 Component Hierarchy ................................................................. 132
4.7.4 Navigation Capabilities ............................................................... 134
4.8 TOOLS FOR THE BUSINESS PROCESS MODELING ................................... 135
4.8.1 Model Adaptation and Improvements .......................................... 136
4.8.2 ARIS Toolset ................................................................................ 137
4.8.3 Outlook ........................................................................................ 137
4.9 CUSTOMIZING ....................................................................................... 138
4.9. I 1mplementation Guide ................................................................. 138
4.9.2 Project Documentation and Analysis ........................................... 140
4.9.3 Change and Transport Organizer................................................ 141
4.10Rl3 AUTHORIZATION SySTEM .............................................................. 142
4.10.1 Security Concepts ........................................................................ 142
4.10.2 Principle of the Authorization Validation .................................... 143
4.10.3 Profile Generator.......... ............................................................... 144
4.10.4 Outlook ........................................................................................ 148
4.11 ApPLICATION SYSTEM INTERFACES ...................................................... 148
4.11.1 Interface Adviser.......................................................................... 149
4.11.2 Data Transfer Programs .............................................................. 149
4.11.3 Technologies for Permanent Interfaces ....................................... 153
4. 12REpORT GENERATION ........................................................................... 156
4.12.1 StandardReports ......................................................................... 157
4.12.2 ABAPI4 Query ............................................................................. 158
4.13SAP SERVICES ..................................................................................... 160
4.13.1 Professional Consulting Services ................................................ 160
4.13.2 Education and Training Services ................................................. 162
4.13.3 Support Services .......................................................................... 162
4.13.4 Online Information Services in Detail ......................................... 164
4. 14 ADDITIONAL TOOLS ............................................................................. 165
4.14.1 Accelerators ................................................................................. 165
4.14.2 Computing Center Management System ...................................... 166
XII Table of Contents
4.14.3 Release Management ................................................................... 168

5 GLOSSARy ............................................................................................... 170
6 ABBREVIATIONS ................................................................................... 178
7 REFERENCES .......................................................................................... 180
8 INDEX ........................................................................................................ 182

1 Business Application Systems
This chapter initially discusses some basic aspects of business application systems
from a business and technical viewpoint. The SAP Rl3 system is then introduced
using this as basis. Initially, the most significant business and technical
components of the system are discussed. The system architecture is considered
from the viewpoint of the basis client/server principle, and then in more detail
from the aspect of the asynchronous coupling of distributed Rl3 systems.
1.1 Introduction
In this section we assume the "enterprise global system", assign business

application systems to this global system, and list the characteristic properties of
business application systems.
A company (see (Ferstl and Sinz 1998, 1-9) and Figure 1.1) can, appropriate for
the types of its objects to be processed, be classified into the (business)
information system and basis system subsystems. Whereas information type
objects are processed in the information system, all other objects, normally
physical items, are processed in the basis system. These non-information items are
not further discussed here. We consider an information system to be the complete
information-processing subsystem of a company. This subsystem is determined
not only by technical aspects such as the computer and telecommunications
systems used but also social aspects such as personal communication and
teamwork.
Business application systems belong to the technical part of information
systems and also include the company's automated ultimate unit of
responsibilities. Analog to the company's responsibilities, we can differentiate
application systems as to whether they belong to the company controlling system
(planning, control and monitoring) or to the company service system
(administration, disposition and realization).
Depending on the circumstances, it is appropriate for a business application
system to differentiate between the actual software product and an installation of
this product. An application software product such as the Rl3 system, which, for
example, is supplied on a CD-ROM, can serve as application system in several
installations (e.g., in different companies or company divisions). Thus, in the
following discussions we always consider an application system to be a specific
installation of an application software product on a computer system. In addition
to the application software products, we also recognize other system software
H.-J. Appelrath et al., SAP R/3 Implementation
2 I Business Application Systems
products such as operating systems and database systems required for the
operation of an application system.
Task Ullimate Unit Of Responsibility Task

Object non-automated Phase
automated
Business Clerk, Controlling System

Application Data Enterer, (Planning,
Information System Manager Conlrol ,
System Monitoring)
(Object Type
Information)
Application Clerk ,
System
Data Enterer
Service
System
Base Precessing, (Realization)
System Transport Worker
(Object Type Systems
Non-Information)
Figure 1.1: Company subsystems (Ferstl and Sinz 1998,4)
1.1.1 Enterprise Architecture
Nowadays, business application systems represent a central and strategically

important part of enterprises. As with all other subsystems, they must be oriented
towards the enterprise' s goals and be built systematically. From the viewpoint of
the DP department responsible for the layout of business application systems, a
company can be considered as a three-layer pyramid (see Figure 1.2 and (Ferstl
and Sinz 1998, 176-179), whose base (3rd model level with details of the
resources) is formed by the employees, the business application systems, and
machines and plants. To improve the comprehensibility and to reduce the
complexity, employees are included in organization units and form an
organizational structure. Employees, machines and business application systems
act together, namely, they interact. Sequences of interactions between them that
serve to follow defined goals are formulated as business process models . These
models as internal view of the company system present at the middle level of the
enterprise architecture in Figure 1.2 describe typical business structures and
procedures (business processes) of an enterprise that the employees and
application systems support. The goals to be achieved with the business processes
and other determining factors are formulated in an enterprise plan. This is defined
at the top model level as external view of the business system.
Because when an enterprise is grounded a system consists of goals that later
must be adapted to the changing conditions, in the ideal situation, you should
1.1 Introduction 3
orient the processing structure and organizational structure on these goals (top-
down methodology) and not vice versa (bottom-up methodology). However,
because often some circumstances in the company must be accepted as they are,
the daily practice shows that the top-down methodology is not always practicable.
For example, employees cannot be replaced or reassigned at will, and old
application systems cannot be replaced "at one go", but can only be replaced
successively. The interactions between the planned company goals and the
resulting business process models (target state), the current state of the company
(actual state) and the possibilities provided by the standard business software
products make the selection and implementation or development of these systems
a complex problem.
New goals often result from detecting weaknesses in the existing company
organization or through the analysis of the market and the competitors.
15\ Model Level

External view ollhe
company system
2nd Model Level

Internal view of the
company system
3rd Model Level

Specifocation of Application Machines
ressources systems and plants
Figure 1.2: Enterprise architecture (Ferstl and Sinz 1998, 177)
1.1.2 Standard Software
Software products can be classified into low-level (e.g., operating systems,

database systems) and application-related software products. The latter are
grouped according to their degree of standardization into individual and standard
software, etc. Individual software is developed for or in a company by itself and
can be designed to satisfy special requirements. In contrast, standard software is
developed as flexibly and universally as possible in order that it can satisfy the
requirements of as many companies as possible. Standardization can be achieved
as the result of laws, standards, scientific knowledge and through the integrated
provided implementation of alternative methods. Thus, tax and commercial laws
have resulted in a partial standardization of the external accountancy. Scientific
knowledge - for example, in the area of internal accountancy with procedures for
cost element accounting and cost center accounting - have also contributed to the
standardization of the methods. If a software product supports several methods,
4 1 Business Application Systems
the user (or his appointed consultant) has the task to set (parameterize) the product
before its use so that it satisfies his requirements to the greatest possible degree.
Because the software products, in particular the Rl3 system considered here, as
result of the increasing integration and through the acceptance of alternative
methods, become increasingly complicated, the user is often faced with a
seemingly endless range of variants. From these he must select the setting by
parameterization, the so-called customizing. The comparison of the user's
requirements with the capabilities of the software that must be made before the
parameterization makes the implementation of standardized software to be a
complex and thus expensive process. One of the reasons is that companies are not
yet capable of being able to judge the advantages and disadvantages of the
alternative methods or do not even know to best way of representing company
structures and processes. This means that companies must expect to have long and
expensive implementation projects.
In standard software, we differentiate between de facto standards and de jure
standards. De facto standards are inofficial standards that are based on the
developments made by a software company and which achieve a significant
market acceptance by the users, or guidelines supported by several companies. In
contrast, de jure standards are developed by official organizations, such as the
International Standards Organization (ISO). Such standards currently exist only in
subareas of business application systems, e.g., in the area of product data models
(ISO 10303, International Standard for the Computer-Interpretable Representation
and Exchange of Product Data, abbreviated to STEP) or for data exchange
between companies (ISO 9735, Electronic Data Interchange for Administration,
Commerce and Transport, EDIFACT).
The SAP Rl3 system represents a de facto standard for business application
systems, which increases in importance not only in the large market acceptance by
the companies that use it but also in the increasing acceptance from other software
companies (Complementary Software Partners) of the SAP specifications. In
addition to de facto standards such as the MS Office products, SAP naturally also
supports popular de jure standards and is involved with the development of other
cross-manufacturer standards, e.g., for the interoperability of application systems
from different manufacturers.
1.1.3 Integration of Software
In the 1970s and 1980s, "insular solutions" still existed in the area of business
application systems, namely software products that could only be used isolated in
a task area. Since then there has been an increasing integration of software
products that resulted in the so-called integrated information processing and the
associated application software products such as the SAP Rl3 system. The
integration was primarily achieved using database systems with central data
management, which all application systems then used. Consequently, the term
data integration is used here. A function integration built on this permits the
1.1 Introduction 5
automatic update of permanently aggregated and derived data. Because the

software products mean that cross-company processes between the business
partners (customers and suppliers) must be supported, the use of the Internet
increases the integration and also adopts new forms. Because several companies
normally do not use a common database system, the data integration reaches its
limits here. The requirement to maintain the consistent data in at least subareas of
distributed companies has provided a powerful challenge to the function
integration. The topic area of electronic commerce provides a discussion this and
other technological questions with regard to the business cooperation of several
organizations using electronic media.
1.2 Tasks and Business Processes
1.2.1 Tasks
The operational areas, and thus the functions of business application systems, can
be grouped based on the company's tasks. Research and development, marketing,
procurement, warehousing, production, sales, general accounting and personnel
management belong to the typical tasks of an industrial company. Depending on
the industry and further company-typical distinguishing characteristics, additional
tasks and specific methods may also be included.
Depending on the type of tasks to be supported, we can differentiate business
application systems into administration, disposition, planning and monitoring
systems (see (Mertens 1997) and the example in Table 1.1).
• Administration systems are used for the rationalization of existing procedures.
Thus, a personnel management system simplifies the administration of a
company's employee data.
• Disposition systems should simplify or take over the short-term company
decision-making process. The disposition systems include purchasing systems
that determine the suitable times and quantities for the reordering of each
stored part (raw materials, resources and supplies, semi-finished products and
finished products) depending on previously selected parameters (minimum
stock level, restocking time and consumption speed).
• Planning systems support the mid-term to long-term decision-making process
and have wider-reaching financial effects than disposition systems. They
normally permit the creation of alternative plans, which then can be used to
find the best possible plans amongst each other or can make a comparison with
the actual situation for control purposes. These also include systems for the
planning of sales quantities for products and the capacities of production
plants, machines and personnel.
• Monitoring systems help department and management staff recognize

exceptional and thus data constellations worthy for further investigation. They
access existing data to detect any plan deviations. They receive here actual
data using administration systems from the running operation, which they
compare with the originally planned data from the disposition and planning
systems.
To keep complex application systems understandable despite their increasing

integration, they are grouped into specialized subsystems using recognized
business task groupings. SAP subdivides its Rl3 system into so-called application
components. Rather than the term component, the designation module was
frequently used in the past. However, the increasing use of object-oriented
technologies means that the term component is being used more often.
We group the standard software components into

• function-related components that directly serve the company's commercial
tasks,
• cross-function components that provide support for all tasks, and
• system components that are used for the technical realization of function-
related and cross-function components.
Each function-related and cross-function component supports a number of

commercial tasks, which, from the technical and logical viewpoint, are also called
transactions (see Section 1.3.2).
Table 1.1: Tasks and types of business application systems (example)
Type/tusk Production Pu rc hasi ng/wal e- Sales Personnel

housing
Operational Warehou e Customer Personnel
Admini LTation
data acquis ition management management management
Disposition Order disposition Rou te planning
Monitoring Production
control console
Planning Sales and Marketing Personnel
capacity planning operati ons
planning planning
1.2.2 Business Processes
Although the term business process has already been used, it has not been defined
precisely. In general, we define a business process to be a sequence of actions or
interactions that are performed from objects or between several objects and which
serve a business goa\. The actors, namely the objects that perform the actions, are
normally company employees, customers, suppliers, but may also be technical
1.2 Tasks and Business Processes 7
systems such as application systems or production plants. When the actions are
performed, other objects are consumed (input), produced (output), and
transformed (input and output). These objects can be materials, products,
information, and general services.
SAP uses event-driven process chains (EPC) to describe (model) business
processes. The EPCs are specified using a graphical notation (diagram language)
that was developed as part of the Architecture of Integrated Information Systems
(ARIS, (Scheer 1999a), (Scheer 1999b)). ARIS (see Figure 1.3) is based on the
idea that the objects (actors, application systems, data, information) involved with
business processes can initially be described isolated from each other and so
maintain mastery of the complexity associated with the representation of the inter-
relationships between all associated objects. The business processes and the
associated objects in ARIS are organized into four views
• the organization view that describes the employees (human actors) and their
organization structures
• the data view that describes the data or information and their dependencies
within each other,
• the function view (or task view) that represents the tasks in their hierarchical
dependency structure - a task can consist of several subtasks - and
• the process view (or control view) that provides an integrated representation of
the business processes using objects defined in other views.
?..rO
o---t?tD
?..rO
0
C)
Data Control Function
Figure 1,3: Schematic view of the ARIS architecture

The more recent ARIS versions (Scheer 1999a) incorporate a fifth view, the
service view. It describes the business services (products, non-cash benefits,
services), using, for example, product data models.
Every assignment into views depends on the goals to be followed using the
created descriptions. Other views - such as a resource view for machines and
plants- are conceivable. On the other hand, not all existing views need to be used
for a required description.
Every EPC is represented as a diagram. To improve the readability, the
recommended direction of reading is from top to bottom. Figure 1.4 lists the most
important diagram elements (nodes and edges) for EPCs. Functions designate
specialized tasks or activities performed as part of the (inter-)actions from one or
more objects. They are displayed graphically as a green rectangle with rounded
corners. Functions produce events, which in turn can react in other functions. The
term event is not always entirely appropriate; in many cases it would be better to
speak of states or situations that permit or assume the execution of additional
functions. A function is always "initiated" from one or more events (start events)
and has one or more events (end events) as result. Thus, events specify
commercially relevant states for information objects that must be satisfied before
functions can be executed. On the other hand, the execution of these functions
changes the states of these objects. This can cause other functions to be executed,
etc. Events are displayed graphically as red hexagons. Because events initiate
functions and results come from functions, there exists an alternating sequence of
events and functions that starts with at least one event and ends with at least one
event. The sequences of events and functions are connected with dashed, directed
edges to a process. This indicates the logical and time-related sequence of the
functions. Thus, the set of edges describes the control flow in a process.
g
OR Logic
@
XOR Logic
e')
AND Logic
Entity Type
Figure 1.4: Descriptive elements of the EPC model

In order to be able to display the maximum possible variants of similar business
processes in one diagram, in addition to the functions and events, the EPC model
contains three other logical operators, also known as connectors, that can be used
to describe alternative (OR operator), exclusive-alternative ("Either-Or", XOR
operator) and parallel (AND operator) sequences of actions. The logical operators
are displayed as white circles that contain the symbol for the logical operator. The
linkages of the control flow between the events and functions can be differentiated
into event and function linkages. For event linkages, the control flow of two or
more events with a pre- or post-function is split or combined using a logical
operator. An event is modeled for the function linkages as result for two or more
functions and the control follow linked with the corresponding operator.
Furthermore, an event can be connected using a conjunctive linkage with two or
more following functions. Because events do not have any decision competence,
other linkage operators cannot be used. This means an initiating event can initiate
only the functions that follow it. More complex logical structures can be modeled
by linking the control flow using several, successive operators.
The business process functions can be considered at various abstraction levels.
This makes it possible to hide behind a function several actions for an EPC, for
example, to "hide" insignificant details. This type of abstraction of details can be
replicated. Thus more EPCs that also have functions can be placed behind
functions of an EPC, which in turn also have EPCs, etc. Process paths can be
inserted to represent dependencies between EPCs. These paths designate
references to EPCs that are executed before or after the current EPC, namely, they
reflect the linkage information for the next-higher abstraction level. Nodes of the
organization unit type are provided to represent the objects (actors) associated
with an interaction. These represent the department, group or position of the
involved actor; it is sensible to extract this from the company's actual employees.
So-called entity types (= types of "things") are provided to represent the used,
produced and transformed objects. These entity types are also administered in the
data view.
To be able to discuss the principles of organization units, it is sensible to
discuss organization unit types, to which departments, groups, project teams and
positions, etc., belong. In fact, because organization unit type instances (concrete
entities) - such as the finance department, the purchasing organization - are also
"things" that can be created, changed and deleted in the business process of the
company form, they are the same as entity types. Although the organization unit
types are understood to be an extract of the data view, they are also administered
in ARIS in the organization view.
Figure 1.5 shows a small example of an EPC that describes typical business
processes of the purchasing function. When (material) requirements arise in the
company's user departments, either company-internal ordering requirements are
entered manually or generated automatically in associated systems (here
manufacturing and maintenance). The purchasing department has two alternatives
(XOR) for the procurement. The required material is obtained either using an
existing supply plan or by creating a simple order. In the second case, the order
must be approved before it is forwarded. When the required goods arrive, they are
accepted and checked by the goods acceptance. The goods arrival is booked and
forwarded to the manufacturing/maintenance and the invoice processing. The
finance department uses an automatic payment process to request for payment the
invoice that has arrived in the meantime.
Software reference models
Because the volume of all business processes supported by an application software

product such as the R/3 system is not only almost endless but also subject to
continuous change, it can be described either with difficulty or, at best, in only
very general terms. However, the typical business processes that occur in many
companies can be identified and are also of interest for the understandable
documentation for the user.
Models are abstract descriptions of an item. Software reference models are
abstract descriptions of business software products that form a bridge between the
technical implementation view and the commercial application view. They do this
by describing the functions and structures from a specialized and commercial
perspective.
Software reference models are used principally during the implementation of
standardized application systems where they support the user for the analysis of
the functionality present in the systems. They should also help the user with the
mapping and redlining during the customizing of the systems. Mapping describes
the comparison of the company-specific business processes and organization
structures (requirements) with the processes and structures provided by the
systems. Redlining describes the selection of those processes documented in the
reference model that are suitable for a company for the customizing of the system.
However, reference models can also be used for other implementation tasks. For
example, they can serve as discussion basis for the workshops used to define the
company structures and business processes for the subsequent system use and as
description to accompany the training for the interaction of individual transactions
for those business processes that are used between departments.
Because the models build on an agreed terminology together with a structured,
graphical display of the model contents, the use of the reference model provides
an increased quality for all tasks compared with conventional description methods,
such as plain text. Furthermore, an improved productivity for the creation of
individual models (planned models) on the basis of the R/3 reference model (see
Section 1.4.9) can be expected, because the use of the reference character means
that it is not necessary to start "from scratch".
@~(---~
Figure 1.5: EPC example

1.3 Architectures
1.3.1 Multi-level Client/Server Architectures
The architectures of business application systems cover not only the software
architecture but also the computer and network architecture. All three aspects are
directly connected. We now start with typical software architectures and show the
consequences for the computer and network architectures.
A software architecture is understood to be the structure of an application
system that consists of the software components, the properties of these
components, and the relationships between these components. A software
architecture can be considered from at least four perspectives:
• The functional or business-process-oriented view (What should the system
provide?).
• The software design view (What components exist and which tasks are
performed from which components? How is the data and control flow
organized in the complete system (message processing, delegation,
synchronization)?).
• The (system) process view (How can the complete system be distributed over
processors and computers (scalability) so that the response time behavior
remains good, i.e., the system provides adequate performance?).
• The physical view (How are the components supplied and installed? How is
the communication realized?).
Now that we have discussed in the earlier sections the functional view of an
application system, namely, the tasks and task structuring, we now discuss the
process view and the physical view. Because assignment (mapping) from tasks to
components (software development view) is one of the principal tasks of the
implementation of standard software, this book will often discuss this topic.
The history of the software architectures for business application systems can
be generally described as being the path from monolithic, central mainframe
computers through to distributed client/server architectures (CIS). Whereas
nowadays mainframe computers can be found only in large companies or for
special service providers, client/server architectures have established themselves
in mid-sized and small companies. The CIS model is based on the idea of
separating information-user (client) and information-provider (server) processes
from each other, so that they for performance reasons (determined by the user
through the response times of the system) or for the decentralized organization can
operate distributed over several computer systems. The standardization of
1.3 Architectures 13
interfaces between client and server processes and the base computer systems also
promises to achieve an independence from hardware and software manufacturers.
There is normally a "1 :n" relationship between server and client processes,
namely, one server maintains several clients. The grading made for the users and
providers can in principle be repeated as often as necessary. Thus, a provider can
also be a user of information from another provider.
Client Process
1 : Query 4: Respo nse

l Client Process 1
Combined
1: Query 2: Response Server
Client
Process
l Server Process 1
3: Respo nse
Server Process1
Figure 1.6: Client/server model

Figure 1.6 (at Th. right), for example, shows three processes: a client process
sends requests (1) to a combined server-client process. Because this can only
partially answer a request, it sends its own request (2) to another server process.
Once it receives the response (3), the server-client process assembles its answer
and sends it (4) to the client process. As you can easily imagine, more complex,
even cyclical client/server structures, are also conceivable.
Process view
The assignment of client and server processes to computer systems can be

selectable only to a limited extent. For example, both types of processes can run
together on one computer or also be distributed on several computers (see Figure
1.7). An important aspect for the assignment of processes to computers (or more
exactly, to processors) is the so-called load balancing. Load balancing is
understood to be the assignment of processes / process steps to be processed in
parallel to processors with the aim of performing these processes as efficiently as
possible. The meaning of a process or process step, and a processor in the
associated situation is heavily dependent on the considered context. For example,
process steps can be complete user sessions, individual transactions or just the
processing of individual authorizations or user inputs. Depending on whether the
assignment of process steps to processors has been predefined, you can distinguish
between static and dynamic load balancing. Whereas for static load balancing the
process steps of a processes have fixed assignment to just a single processor, a
new decision is made from process step to process step for dynamic load
balancing as to which processor is to be used for the processing.
The motivation behind current CIS systems is primarily technical. For example,
there are servers for data storage, printing, processing of business-relevant data
(application area), the presentation and the sending of messages. However,
architectures are also conceivable in which the servers are organized according to
departmental viewpoints (e.g., according to the company's tasks). Even nowadays,
questions to determine "correct" architectures are still research topics.
Client Computer 1 Client Computer 2
lClient Process J [Client process] Client process)
+
I I
•I
~
ferver Process
Server Compute
Figure 1.7: Assignment of CIS processes to computer systems

Typically one differentiates the concrete layout of CIS systems depending on
the number of vertical layers: two, three, four and general multi-tier architectures.
The three-layer architectures common nowadays in business application systems
consist of the Presentation Layer, the Application Layer and the Persistence
Layer). The associated systems are often also designated as the presentation client,
the application server, and the database server. The user makes interactions with
the application layer with the graphical user interface (OUI)) implemented on the
Presentation Layer, often also called the front-end. The application layer performs
the operations initiated from the user and reads information from a database,
performs calculations, inserts new information into the database, and returns the
result to the presentation layer. The database layer is used for the logically
consistent administration and the persistent storage of the data for an application.
These technically motivated architectures resemble tree structures with
branches: a set of clients for the interaction with the user are based on an
application server that provides a number of application functions. This and a
number of additional application servers in turn undertake the role of a client with
regard to a central database server that performs the required data operations
(queries, insertions, deletions, updates) for the applications. Depending on the
number of branches (namely, presentation clients per application server and
application servers per database server), we can differentiate between at least three
typical variants (Figure 1.8).
• Variant I: Application and database servers operate on a single computer
system. One or more (''1:n'') presentation clients can be operated on each
presentation computer, which then makes use of just one application server.
• Variant II: In contrast to variant I, the application and database servers run on
separate computer systems.
• Variant III: Multiple ("1 :n") application servers each runs on its own computer
system, which then makes use of just one database server. Multiple
presentation clients can be operated on each presentation computer, which in
turn each uses different application servers.
Although other variants are conceivable, they do not occur often in practice.
For example, constellations are conceivable in which a presentation client can
simultaneously access multiple application servers and an application server can
use multiple database servers. A problem associated with the distribution of data -
for example, using multiple database servers or multiple application servers with
their own databases - is the guarantee of ACID properties (see Section 1.3.2) for
performing completed, consistent transactions. This requires central system
services in the form of so-called transaction monitors.
Figure 1.8: Three-layer architectures
In accordance with the third variant, department motivated, horizontally

organized architectures can occur in which company tasks (e.g., logistics, general
accountancy, human relations) can be distributed to independent computer
systems. Thus, a dedicated application server can be operated for every company
department on which the employees have access to their presentation computers.
The integration of application systems for several companies provides another

variant. Thus, it is sensible to couple those application systems of companies with
each other that form a supply chain (see Knolmayer, Mertens and Zeier 2000) or
have some other dependencies (e.g., in the form of a reporting system between a
concern and its subsidiaries). Because of the physical separation and the
consequent transmission costs, the operation of a central database server is not
usually appropriate. Furthermore, the problem of data confidentiality also arises,
namely, precautions must be adopted to avoid a company having unauthorized
access to the data of another company. Consequently, the application systems are
coupled at the application layer. Standard data formats (e.g., EDIFACT, in the
Internet now increasingly using formats based on XML, see Buxmann and Konig
2000) have been developed to permit selected data of an application system to be
exchanged with other application systems (see Figure 1.9).
The Internet permits additional forms of the business development in which the
business partners (customers, suppliers) perform actions on the application system
of a partner company. In this case, the three-layer architectures are augmented
with a fourth layer (Internet server) that lies between the application layer and the
presentation layer.
Figure 1.9: EDI coupling of application systems
The four-layer architectures (see Figure 1.10) make it possible for end-users
and other customers with Web browsers (presentation layer) to use Internet servers
(Internet layer) and application servers to access the information of another
company. The integration of data from networked companies than can also be
realized directly using Internet servers. Currently, standardized data formats are
being discussed for this purpose, such as those based on the XML Internet
language.
Figure 1.10: Four-layer architecture
Physical view
Because software systems are generally installed distributed over various

computers, these must also be connected using networks. Consequently, two types
of networks occur in a three-layer architecture: the front-end networks that
connect the computers of the presentation layer with the computers of the
application layer, and the server networks that couple the application computer
with the computers of the database layer. In simple configurations, this can be
physically the same network, although distributed configurations are conceivable,
in which, for example, the Internet or comparable wide area networks (WAN))
and as server networks, local area networks (LAN», with significantly higher
bandwidths (10 Mbitlsec and more) are used as front-end network.
1.3.2 Relational Database Systems
The data that arise in a business application system are stored in one or more
databases . Databases are closed "data containers" that have a number of useful
properties. They are administered from a database system (DBMS) that provides
the application system and the user with access to the data for all managed
databases and ensures the consistency (logical correctness) of these data. The
DBMS with its databases forms a database system. A DBMS used to store data
provides the following advantages:
• the data are managed independently of the application system
• the consistency (lack of contradictions with regard to previously defined
properties) of the data is monitored
• backup capabilities are provided for the data

• the databases can be used concurrently by several users (multi-user capability)
and
• the data storage is independent of the hardware.
The application-independence and the consistency of the databases is ensured,

for example, by the data being stored using a previously defined scheme. This
scheme specifies which data are to be stored and in what form, how, and whether
there are logical relationships or dependencies between various data items that are
to be observed initially and for subsequent changes. The structure of the scheme
for a database (database scheme) is the central result obtained from the design of a
database.
There are different concepts (data model) how a database represents its data.
The network and the hierarchical data model are older models that are increasingly
losing in importance. Modern object-oriented or object-relational data models
have not yet established themselves for general application situations.
Consequently, the relational data model currently forms the basis for commercial
DBMSes.
In the relational data model, the data are managed in tables, also known as
relations. These relations consist of a series of attributes. Every attribute (in SAP
jargon: field) has a name and a fixed value range, such as date, decimal number,
character string, and, depending on the DBMS, may allow additional data types.
The data in the relations are stored in rows, called tuples. Every row has the same
number of columns as the relation has attributes, and the value of each column
originates from the value range for the corresponding attribute. SQL is the best-
known language for the definition of database schemes, and for the query and
manipulation (update) of relational databases (Meier 1998).
A simple example (see Table 1.2) illustrates the relationships between tables,
attributes and tuples. The departments and the employees are of interest for an
application system. A number, a name and a location describe the departments in
this example. Employees also have a number, a name and work in a department.
This case can be modeled in the relational data model using the following relation
scheme:
• Department (Deptno: number, Name: character string, Location: character
string)
• Employee (Empno: number, Name: character string, Dept: number).
The database scheme required for the definition of a database consists of the
relation schemes and additional consistency conditions and storage parameters.
The information can now be stored in a database on the basis of this database
scheme.
The department number (Deptno) and the employee number (Empno) uniquely
identify each tuple in the associated relation. This means any two tuples have
different numbers. Attributes that uniquely identify every tuple are called primary
keys. The "Dept" attribute from the Employer relation contains the "Deptno"
primary key from the Department relation and so expresses the department in
which the employee works. Attributes that are primary keys of another relation are
called foreign keys.
Table 1.2: Database tables
Table: Department Table: Employee

Deptno Name Location Empno Name Dept
100 EDP Main building 100 Brown 300
110 Logistics Annex A 101 Smith 200
200 Personnel Main building 102 Miller 100
300 Production Hall 1 103 Fisher 300
The DBMS monitors whether the database is always in a consistent state,

namely, whether all tuples in all relations are uniquely identified by a primary key
and whether foreign keys contain only the primary keys of the referenced relation.
The monitoring of this consistency represents an important prerequisite for the
correct working of a business application system, because this generally ensures
that the data are stored consistently. It expects, for example, that a corresponding
department exists and can be queried for every employee, and that only a single
tuple exists for the department number. The DBMS does not perform any changes
- more accurately: change wish - the effects of which would violate the
consistency of the databases. Modern DBMSes offer other possibilities to describe
the consistency of a database.
Application systems normally execute sequences of update and delete
operations to a database. These sequences are called transactions and have the
following properties (ACID properties ):
• each transaction forms a unit ("All or nothing", atomicity), namely, it is either
completely performed on the database or not at all,
• each transaction maintains the consistency of the database,
• transactions are performed independently (isolation) of each other,
• the changes made by a transaction to the database take affect permanently
when the transaction completes (durability).
Because inconsistent intermediate states are not visible for the other users, the
transaction concept ensures that several users can work in parallel on a database.
In addition, in an error situation, the DBMS during a transaction can restore to the
consistent state that existed before the incorrect transaction. The DBMS has the
task to ensure the security of the transactions and to synchronize the transactions
of the various users.
1.3.3 Object-oriented Architectures
In this section we briefly describe new object-oriented software technologies for

the development of business application systems. Although the user, in particular
for the use of standardized systems, wishes to remain abstract from the
development layer, the techniques are relevant by making significantly more
flexible the form of future systems and so better respond to the user wishes. The
SAP is also increasingly adopting an object-oriented course, which, for example,
becomes apparent through the development initiatives for the subjects "Business
Framework" and "Business Objects". The basis programming language for R/3,
ABAP/4 (Advanced Business Application Programming, see Section 1.4.7), is
being further developed and extended to be an object-oriented language (ABAP
Objects) so that it can be easier linked with standardized languages such as Java.
Because, despite all efforts, a software manufacturer is not capable by itself of
developing an adequate software solution for all task areas of a company, it is
forced to open its product for supplementary products from other manufacturers.
Consequently, efforts are being undertaken in the area of the object-oriented
software technology to build application systems from smaller, replaceable
components that can communicate using standardized architectures. Thus, the idea
to produce software products, such as products for automobile manufacturing or
other industries, on the basis of product lines and standardized components would
appear to become nearer, even in the software development.
Object-orientation
We can assume in the object-oriented software technology that all items relevant
for the application systems can be represented as objects, irrespective of whether
the information concerns a supplier, an contract or some other business item.
Object systems (families of objects) can be formed from objects in which the
objects have relationships to each other and interact with each other. Objects are
typed, namely, all objects of a type (object type) have common properties
(attributes such as color, height, width, price) and the same capabilities, call
methods in the object-oriented world. For example, suppliers can "deliver
materials" and "send invoices". Further, central principles of object-oriented
systems that build on these are
• the object identity ensures that every object is uniquely identified using an
identifier (Objectld),
• the inheritance through which the capabilities and properties of a definition of
an object type (super type) can be forwarded to the definition of another object
type (subtype) (inherited),
• the polymorphism with which the various capabilities of subtypes of a common
supertype using the same capabilities identifier (the name of the method),
• the encapsulation of properties and the associated capabilities within an object
type, and
• the information hiding - the capability to hide implementation details from the
user (client) of another object (server).
In particular, the integration of structure and behavior permits objects to be

considered in the sense of the client/server model as smallest possible units
(processes) for distribution to computer systems. Each object when in the role of
the client uses capabilities from other objects and can also as server make its
capabilities available to third objects.
Whereas in the classical three-layer architectures, the complete application
layer consists of one or, at least, a predefined fixed number of server processes,
the object-oriented technologies permit this layer to be subdivided into a series of
mutually interconnected client and server objects, which then can be distributed
almost without limit to computer systems. Objects interact with each other over
computer limits and can cause other objects to perform their capabilities
(methods). The developer of an object-oriented system does need to know on
which computer his object "lies". In contrast, in the classical three-layer
architectures, messages are sent between the applications; these messages are
received centrally by the receiver and then normally the receiver objects must first
be assigned. The developer must normally specify the computer that contains the
receiver object.
Figure 1.11 shows a simple distribution scenario: an application server
administers a number of orders in a container; these orders themselves consist of a
list of order items. The items consist of an item number, the number of units, and a
reference to the material master record. A second application server - possibly on
a different computer - administers the material masters in a container. A material
master consists of a material number, and a designation. The objects are
administered persistently in several database systems. The Common Object
Request Broker Architecture (CORBA) from the Object Management Group and
the Distributed Common Object Model (DCOM) from Microsoft support the type
of distribution for objects over computer limits discussed in this section. The fact
that application servers manage objects that are operated on remote computers
can, and should, remain completely hidden from the developers.
Object-oriented Framework
In the past, the main problem with the coupling of application systems (e.g., using
EDIFACT) was seen in the syntactical (the specification of the permitted character
stings) and the semantic (the specification of the meaning of the character strings)
standardization of the information structures. However, more recently, in order
that the application systems can better interact with each other, it has been
appreciated, in particular, that the behavior of the software systems must be
matched with each other above just understanding isolated messages. The
technology of object-oriented frameworks can be used here.
Application Server 1 Application Server 2
Container for Orders Container for Material Masters
Order #1234:
( #... )
t #1:3 items ( 1/1 : Hammer )
( 112: 10 items ( #5:5mm screw )
( 113: 20 rtems
j
( 118: 4mm screw )
! • •••......
Table: Position Table: Malerial Masler

Pos# Orderll Item~ Material# Id# Designation
#1 #1234 3 #1 #1 Hammer
#2 #1234 10 #5 H5 5mm screw
#3 #1234 20 #8 #8
/I ... H... ... #... # .. ...
Data Base Server 1 Data Base Server 2
Figure 1.11: Distributed objects on computer systems

Aframework is a "half-finished" software product that serves as the basis for a
class of concrete application software products. It consists of a predefined
software architecture, which, within certain limits, it extends with software
components and, as described above, can operate on distributed computer systems.
Characteristic for these systems is that they assume a predefined behavior.
Components enter a "contract" with a framework specifying their capability that
they must observe, otherwise the complete system behavior cannot be predicted.
Components are "inserted" into the framework like modules (see Figure 1.12) and
can be replaced with modules from other manufacturers - assuming that the
contract is satisfied. If a framework also supports distribution aspects, the
components can operate on any interconnected computers.
Components can themselves also be frameworks that can also include other
components. Analog to these layers, providers that offer such components are
appearing on the software market. An example is the "San Francisco" framework
from IBM (Abinava et al. 1998) that forms a general basis for business application
systems, which is being further developed with components from other software
companies (Independent Software Vendors, ISV) to provide industry-typical
systems.
Presentation Presentation
Presentation Presentation
Client Client
GUI GUI
Application _ Application
Coupling Component Component
Component Coupling
Component ]
[
Framework
DB DB Application Network
Component Component Component Component
Figure 1.12: Framework
1.4 The Rl3 System
We now use the company structure described in Section 1.1.1 with the three
layers: company plan, business model and resources to introduce the Rl3 system
in more detail. The resource level (see Figure 1.2) in the third model layer is
assigned as application software product. The technical aspects in the form of
possible architectures interests us here at this layer. However, because the Rl3
system as application system is used to realize the company plan by supporting the
company structures (organizational structure) and business processes, we also
discuss these items in more detail. Thus, in this section, we follow a bottom-up
methodology from the technical application through to the resulting realizable
business processes.
1.4.1 Client/Server Architecture of the R/3 System
Even in its simplest configuration, the Rl3 system operates as a three-layer

architecture. Consequently, all variants already shown in Figure 1.8 can be
realized, namely, presentation, application and database systems can run on
different computers. However, the minimum configuration consists of just one
computer, e.g., a notebook, on which the complete Rl3 system can be installed for
demonstration purposes.
A maximum distribution can be achieved with the parallel operation of multiple
application systems, each of which is installed on its own computer. In this case,
we also speak of Rl3 instances . An Rl3 system then consists of several instances.
Although it is technically possibly to run multiple Rl3 instances on a single

computer, this does not normally make sense, because we normally wish to
distribute the load on several computers. However, there are data centers in which
multiple Rl3 systems run in parallel on large-scale computers and so provide this
service as outsourcing for other companies.
Services and work processes
An Rl3 instance provides a number of technical services (logical services) that are
required for the communication with other components (presentation system,
database and other Rl3 instances) and generally for the processing of inquiries
made to the Rl3 system. These services include
• the dialog service for the processing of user inputs and application functions,
• the update service to post the changes made to the database,
• the enqueue service for the central management of locks made on the database
objects,
• the background service for the processing of background processes without
dialog, and
• several other services such as spool, gateway and message services, which,
however, are not discussed here.
Each of these services can be realized by one or more processes, so-called work
processes of the R/3 run-time environment. Thus, several dialog and background
processes are required to permit fast work with the Rl3 system. Several services
(enqueue, message) are required just once in an Rl3 system. This means that one
instance is named as being the central instance, on which these services are
installed as work processes.
Operation modes and logon groups
Because the company department workers work mainly in dialog mode whereas
background processes, such as updates to the data store or larger print requests,
are performed at night, it is sensible to apply a time-relevant variation to the ratio
of work processes for the dialog and background services. So-called operation
modes can be defined here in the Rl3 system (see Section 4.14.2) that enable the
computer's load profile to be set appropriate for the company requirements.
The clients at the presentation layer can be assigned either statically or
dynamically to the application servers (R/3-instances). With a static assignment, it
is defined in advance which Rl3-instance is to be used by which user. A dynamic
assignment has the advantage that an Rl3-instance with free computer capacity
can be selected. Because the user cannot know this himself, the Rl3 system should
decide which user is assigned to which Rl3-instance. Logical Rl3-instances, so-
1.4 The Rl3 System 25
called logon groups, can be defined here in the Rl3 system. The user only needs to
now select a logon group during the logon. The Rl3 system then makes the
assignment to a concrete Rl3-instance. Thus, the Rl3 system performs a static
strategy of load balancing, the so-called logon load balancing. In this case, when
the user logs on, a user is given the fixed assignment to an Rl3-instance - and thus
to a computer - for the duration of a session.
Operation modes and logon groups are significant quantities that affect the
high-performance configuration of the Rl3 system and thus should be considered
as part of the implementation. They are configured in the Computing Center
Management System (CCMS, see Section 4.14.2).
Database management
All previously presented architectures require the installation of a central database

system to which all Rl3-instances can access. Although of interest from the
technical view, but almost without importance for the user, is the fact that
additional communications connections between the applications servers are
needed for the distribution to multiple application servers, because the
coordination of the access to data through the use of differentiated locks cannot be
achieved using the locking mechanism of the central database system but requires
its own Rl3 work process (enqueue process). One reason is that SAP has added its
own mechanism to the transaction mechanism of the basis relational database
system. The SAP mechanism forms an Rl3 transaction from a sequence of
database transactions. An Rl3 transaction is a business transaction as performed by
the user in the Rl3 with several screen masks. SAP designates such screen masks
as dynamic programs (dynpros, see Section 1.4.7 and Glossar). The application
system logs here the changes made during the database transactions and notes the
required data using so-called locks (lock entries) to protect them against
simultaneous changes being made by other Rl3 transactions. To avoid
endangering the ACID principle of an Rl3 transaction, the other application
servers must also be able to access logs and locks. Additional communications
connections are required here.
The computers on which the database system, the enqueue process and the
message process (not discussed in further detail here) run represent general
weaknesses for the availability of the complete system. The complete Rl3 system
can no longer be used should one of the computers fail. To still guarantee a
continuous availability, special failure strategies must be developed and hardware
solutions installed (the hardware and database partners of SAP provide such
solutions).
Presentation system
SAP provides the so-called SAPGUI (SAP Graphical User Interface) for the
presentation layer. This software product is available for various operating system
platforms, such as Microsoft Windows 95 and Windows NT, Apple MacOS and
UNIX. A more recent development is the SAPGUI in Java, which uses a Java
Virtual Machine to provide the functionality known from the traditional SAPGUI
but without requiring the previous installation in every Web browser. The
SAPGUI is a window and menu-controlled presentation system (see Figure 1.13).
In the standard configuration, the menu permits the invocation of all functions of
the R13 system, including the development environment (see Section 1.4.7).
However, special configuration settings in the hierarchical menu structure can be
used to define other menu items as invocation points and so provide only selected
areas, such as the transactions of the material management for the user.
Although a user can open several windows (modes) to process several
transactions in parallel, a single presentation system cannot be used to access
different application systems concurrently. However, the user can start multiple
presentation systems on a workplace computer, which in turn use different
application systems. The session manager, which also permits access to mUltiple
application systems, provides an alternative to the SAPGUI.
Iii SAP R/3 System I!III~ EJ
l,eaStJ,y .!1.lossary
~loIIing Release Il0l<*
.EnterprISe cornoling !i.-nan r<*ourc;es Gelling slMed
Cap)lallwslml mgt Project IMMlI"ment
Seli!J!js..
Projecl management Bd hoc fep<>'ts
.!1.enefal report selecbon
Start l!lOIkflow
Al.l:hvr.g
End ",,"ion
Mateftals~ • ferSMneI man_ment ASAf Workbench .1.1.", profile
S~ and distrib\AJon • line rMnageIT'Ient ll. >nllles. Eng.,eer Servjces
froduclion P~oI SAP Bus.,e.. l\I:orkflow • Utltie.
us!
P!oduclion . process Tr ....ng and e~ents By.iness framework
f'!MI marrrlen"""" Jlb!ect sefvices
ll.rgarizational management
£,ervice management
Quality management
• TJavel management
,CCMS
Ad.a;inosl/abol'l
OW[) .pooI requesls
O~lObs
!nformabon syslefn CQrrm,rnicalion
L~ conlrollrlg
S]:)o<l message
WOld proceurng £.lalus.
PrCjeCl management
J:jypertelll Log oIf
~ral functions
r.,d
Figure 1.13: SAP Graphical User Interface (SAPGUI)
Application Link Enabling (ALE)
Whereas a single R13 system suffices for simple company structures with just one
company and a limited number of locations, concerns with several companies or
similarly complex company structures may require multiple application systems
with independent databases. Architectures that build on just one database provide
1.4 The R13 System 27
the greatest functionality, because all organization units can make integrated
access to this data store. In contrast, a central database could hardly be realized for
a large-scale distribution of the company, such as over several time zones and thus
would require different times of availability. The maintenance activities in this
case scarcely permit a high availability. Furthermore, the required network
bandwidths and the associated communications costs must be taken into
consideration for the geographical distribution. ALE can now be used to couple
together multiple application servers each with its own databases (and normally
also their own database systems).
Typical are scenarios (see Figure l.14) in which subsidiaries transfer the most
important information from their own decentral Rl3 systems to a central Rl3
system (e.g., the group company) and also accept new, centrally resulting data
from there. The central system creates analyses and report lists that are typically
important from the concern report system viewpoint. The closed decentral
logistical systems supply the required information here. The communication
between these systems takes place periodically (e.g., daily). Favorable times in
which the systems are not required for other tasks and the communications costs
for the transfer are lower (for example, at night) can be chosen for this
asynchronous type of communication.
Head Office
- Financial accounling
- Cost accounting
Maslerand
controldata
Plants (decentral)
- Invenlory management
- PurchaSing
- Sales
- Production planning
- Maintenance
Figure 1.14: Distributed applications with ALE

This solution always has the problem that the companies normally wish to have
a certain guaranteed consistency and up-to-dateness in the data. This requires that
some master and customizing data (see Section 2.l.3 and Glossar) have the same
status on all systems.
Application Link Enabling (ALE) supports such a distribution of business

processes and functions through the configuration and operation of distributed Rl3
applications and non-Rl3 applications. This permits the exchange of data such as
order data, master data and customizing data between multiple application
systems. Similar as EDI, ALE provides controlled message exchange of
commercial data between loosely coupled and distributed applications while
maintaining consistent data storage. Every Rl3 system has its own database that is
not continuously synchronized with the databases of the other systems, and thus
exhibit redundant and temporarily inconsistent data states. A message exchange
resynchonizes the stored data. An asynchronous communication of special
documents, so-called Intermediate Documents (lDocs), provides the necessary
application integration. Each IDoc belongs to just one IDoc type. SAP provides a
number of predefined types that the user can extend. ALE and IDoc also form the
basis for the communication using ED!. In this case, IDocs are sent to EDI
subsystems. Because ALE works with various versions of Rl3 systems, the user
does not need to worry about the compatibility of distributed systems.
The distribution is controlled centrally. The configuration is performed on one
system (customizing, parameterization) and then sent to the distributed application
systems. The (new) configuration is then put into operation at a previously
specified time.
The user has the following disadvantages when the ALE architecture is used
rather than central data storage:
• he must specify which applications are to run on which computers,
• he must specify which transaction data and master data are to be exchanged
• he must specify which customizing data are required here.
SAP provides sample models (ALE scenarios) and a number of auxiliary tools
to support the user.
Business Framework
SAP also increasingly uses object-oriented technologies. This is apparent with

various initiatives. The first step in an object-oriented world is the development of
business objects) and the associated interfaces (Business Application
Programming Interfaces, abbreviated to BAPIs). Business objects are objects that
in the daily business life represent self-contained items or facts, and adopt a
significant role in the intra-company and cross-company communication. Orders,
suppliers and customers are typical business objects. The definitions of the
business objects (object types) are maintained in a central directory (Business
Object Repository, BaR). BAPIs are interfaces that can be used to invoke the
functions (methods) of the objects.
The business objects can be understood as being the encapsulations of the
existing Rl3 functionalities and structures, namely, the programs and tables of the
Rl3 system are no longer assigned according to functional characteristics as
1.4 The R/3 System 29
previously, but assigned technically to the type definitions of the business objects.
Thus, every definition of an object type uses one or more tables of the Rl3 system.
A mentioned table (reference table) establishes the relationship between the
object-oriented work and the relational database world. The primary key of this
reference table is then used as key field (ObjectId) of the object type definition.
This satisfies the requirement of object identity. The attributes of an object type
definition are also based directly or indirectly (using the reference to other object
types) on the fundamental table structure of the database system. The methods
assigned to the object type definition are ABAP/4 function modules (BAPIs). A
principal property of these function modules is that they can be invoked over
computer limits using a Remote Function Call (RFCs, see Section 4.11.3). This
makes it possible to call the BAPIs of one R/3 system from another Rl3 system or
even from systems of other manufacturers, e.g., from Java and C++ programs.
In a second step, SAP defines a so-called business framework that is used to
build business application systems on the basis of existing SAP technology.
Business frameworks exhibit similar properties as the object-oriented frameworks
introduced in Section 1.3.3. The Business Framework technology, which also
includes ALE, makes it possible to subdivide the system into smaller, self-
contained, "release-capable" components. Release-capable means that the user can
at any time replace existing components with new versions (releases) of the same
components. Every component is based on a number of business objects and
associated interfaces. SAP extracts some application components of the Rl3
system from the complete system. Every self-contained component (see Figure
1.15) can then use the BAPIs of the business objects (GO) to interact with other
components. These can be either components from the application layer or from
the usage layer. Synchronous ALE interfaces realize the communications
mechanisms needed here. Other application systems and presentation clients, such
as those developed in the C++ or Java programming languages, can use standard
interface technologies (CORBA, DCOM) from the client/server model to access
the business objects.
The user can decide whether he runs his components on a single Rl3 system
(framework) or installs a dedicated Rl3 system for the individual components.
Because SAP guarantees the compatibility between different versions, the second
variant has the advantage that the components remain independent during release
planning.
Systems can still be coupled asynchronously using ALE. This type of
connection has the advantage that the communications partners do not always
need to be available and time of communications can be selected freely.
In
Coop. 1 :>
o
c
2
&;
o
c
Ffa'rev,crk (fuliress Ffa'rev,crk) ) ~
'"
w
oJ
0:d0Case 9jstem (CSS) ~
Figure 1.15: The SAP framework architecture
1.4.2 Internet Connection
Because products can be economically marketed over the World Wide Web
(electronic commerce), the Internet is increasingly gaining in importance for
companies in certain industries. In addition, the company's employees' private use
of the Internet means that they are becoming increasing familiar with the medium.
This means that the knowledge of operation of a Web browser can be more often
assumed rather than that of a SAPOUI. Thus, methods have be sought to make the
Rl3 system also accessible over the Internet. The Internet Transaction Server
(ITS) that provides parts of the functionality of the Rl3 system using the HTML
interface of a Web browser is one means of providing the Rl3 connection. HTML
(Hypertext Markup Language) is a relatively simple programming language that
can be used to create documents and forms for the Internet. HTML, together with
the Web browser technology, gives every user a simple access to the system.
Obviously, the Internet connection from Rl3 can also be made with a complete
in-house development using the remote interfaces (BAPI, RFC, see Section
4.11.3) or using the SAPGUI in Java. However, the ITS reduces the development
effort for simple problem situations and so is presented in the following section.
From the technical viewpoint, the Web browser provides the presentation layer
in the client/server architecture of the Rl3 system. However, because a HTML
Web browser has completely different properties and demands compared with a
SAPGUI, this is not possible without using additional components. New
requirements result both at the technical level of the communications protocols
and at the logical level. For example, should it be possible for a customer to first
register in a company's online shop at the time of making the order and not, as
required by the SAPGUI, already at the start of the session. Other requirements
must also be made on the graphical appearance of an Internet application.
Figure 1.16 shows the architecture and assignment of the ITS in the overall
architecture of the R/3 system. The ITS uses the user interface of the Web browser
to connect the user with the R/3 system. The ITS is divided into two parts, the A-
gate and the W-gate. The A gate forms the interface to the R/3 system and
prepares for the R/3 system the user's inputs to be made in the Web browser.
HTML templates are also used to format the R/3 system outputs for display in the
Internet. Because the Web browser and SAPGUI differ significantly, ITS the must
make various other modifications. The ITS's W-gate forms the interface to a
normal Web server that can be used to access the user's Web browser.
Web Browser Internet
Web Server
(/) ( W-Gate ) Enterprise

f-
network
- ( A-Gate )
Figure 1.16: Internet Transaction Server

SAP provides various components for the development of applications with the
ITS. The ITS itself must be installed and configured. Either in-house ABAP/4-
programming (see Section 1.4.7) must be performed in the R/3 system or special
configurations made in the system. Dynamic Business HTML, a SAP-specific
extension to HTML, that is finally used for the automatic creation of standard
HTML, must be used to layout the appearance of a Web application. The Web
Studio tool, which SAP supplies with the ITS, helps to layout Web pages and in
the configuration of the applications.
Three alternatives are available to realize applications using ITS: Web
Reporting, in-house development of lACs (Internet Application Components) and
the use of predefined lACs. An Internet application component provides the
functionality of an R/3 component using a Web browser. To supplement ITS,
solutions from third-party providers are now on the market that either build on the
ITS or replace it. However, they are not presented here.
Web Reporting
Web Reporting can be used to make simple reports available in the Web browser.
Such reports are also available in the Rl3 system (see Section 4.12) or may have
been programmed in-house,. The effort required to use Web Reporting is
relatively low. However, the realization of more complex interactive programs is
not possible.
lAC In-house Development
The in-house development of lACs is the most flexible solution, but also the
solution that requires the most effort. You yourself must perform both the
ABAP/4 program development, including the creation of interactive dynpros (see
Section 1.4.7 and Glossary), and also the programming and layouting of Web
pages.
Predefined lACs
The Internet application components supplied with the ITS have been developed
for special and limited business processes. Consequently, you should first check
whether the capabilities and the functionality of a predefined lAC meet your
planned goals. Much development effort can be saved if is possible to use such a
component. However, configuration work is still needed, for which knowledge of
the Rl3 system in the associated lAC application area is required. The ITS
supplies Internet application components from the areas of electronic commerce
(e.g., online shop or help wanted offers), purchasing (e.g., requirements), customer
service (e.g., reports of failures to the repair services), employee self-services
(e.g., information from the company's human relations and event management)
and internal services (e.g., project documents).
1.4.3 Components of the Rl3 System
As part of the division of the Rl3 system into smaller components - SAP calls this
componentization - the Rl3 system since Version 4.0 has five main components,
namely
• the three function-related components: Accounting (AC), Human Resources
(HR) and Logistics (LO),
• the inter-function component: Cross Application Components (CA), and
• the system component: Basis Components (BC).
Starting at Version S.x, the three function-related components AC, HR and LO

are to be offered on the software market as self-contained products. HR is already
available from Version 4.0 and can be linked using ALE (see Section 1.4.1) to
AC, LO and other manufacturers' products. A number of additional Rl3
components have been developed under the term SAP Industry Solution. These are
particularly oriented to the industry-specific requirements (banking, health care,
retail, etc.).
In addition, SAP offers newly developed components, for example the Business
Information Warehouse (BW) and the Advanced Planner & Optimizer (APO), that
are not based on the Rl3 system but can be coupled to it.
The following sections present some of the important standard components,
however, without discussing industry-specific solutions. In the description, we
restrict ourselves to the most import aspects at the top layer of the hierarchy. We
assume familiarity of the basic accountancy terms used here and refer to the reader
to specialized accountancy literature should more information be required (Wohe
1996).
1.4.4 Function-related Components
The components of the Rl3 system are assigned in a component hierarchy that is
also used at other places (see Section 4.7) in the Rl3 system as classification
scheme. This hierarchy contains the subcomponents of the function-related
components AC, LO and HR. The AC component contains the FI, TR, CO, 1M,
PS and EC subcomponents; the LO component contains the SD, MM, QM, PM
and PP subcomponents, and the HR component contains the PA, PT and PY
subcomponents.
Financial Accounting (FI)
Fl consists primarily of the components for the general accounting, the subledger
accounting (for accounts receivable and creditors) and the assets accounting. The
general accounting forms the FI kernel. It is characterized by the methodology of
the double-entry bookkeeping and receives its inputs from the other components
(subledger accounting and assets accounting). These inputs include consolidated
posting records from the subledger accounting (accounts receivable entries from
the invoicing and creditor transactions from the supplier invoice control) and from
the material evaluation of the analyzed material transactions. The transactions
from the material management (MM) and the marketing (SD) are used to
automatically update the accounts receivable accounts and creditor accounts,
which themselves are directly coupled with the general ledger. The general ledger
represents the central and current component of the rendering of the accounts. The
record of the individual postings is possible at anytime using documents, line
items and transaction figures at various levels such as account maintenance, the
journal writing, the trial list transaction figures and the balance sheet / profit and
loss analyses.
Treasury (TR)
TR covers the financial and liquidity disposition, which, depending on the

expected flows for earnings and expenditures and the resulting balance, provides
support for the investing or short-term burrowing of financial resources. The
household management also included in this component is used to control the
earnings and expenditures. For this purpose, budgets are provided for defined
organization units of the company (so-called financial posts), which as financial
framework may not exceed specific tolerance limits as so avoid endangering the
financial equilibrium, in particular the company's liquidity.
Controlling (CO)
The cost and profits accounting (CO) represents the part of the cost accounting
that records the costs that accumulate during the accounting period and groups
them according to the points of interest. Because each cost system-relevant
business transaction supplies detailed information about the cost type and the
account object in the cost system, an integrated accountancy system does not need
a separate recording of the costs. Every consumption activity in the materials
management, every invoicing in the marketing system, and every external invoice
in the invoice verification flows directly over the GIL account (= cost element) to
the associated account assignment object.
The overhead cost controlling (CO-OM) plans, controls and monitors those
services that cannot be directly assigned to the cost elements. These are based on
the cost systems methods known from business and management economics: cost
distribution costing, overhead rate costing, fixed budget costing, standard direct
costing and process costing.
In addition to the monitoring and control of the overhead costs, the overhead
cost controlling performs useful preliminary work for the profit and market
segment costing (CO-PA) and for a more exact calculation of the product costs
(CO-PC).
Investment Management (1M)
The Investment Management (1M) component with its functions supports the
planning, investment and financing process during the processing of investment
measures in the own company. Investment projects can be defined, processed as
concrete measures using orders and financed using budgets that go over order
limits.
Project System (PS)
Projects can be represented and managed in the Project System (PS) component.
The system helps project leaders and members to ensure that a project is realized
within the set deadlines, costs and results and to provide the necessary resources
and financial funds. Examples of projects are the building of a complete
manufacturing plant or even smaller tasks such as an appearance at the trade
exhibition.
Enterprise Controlling (EC)
EC groups the tasks of the company controlling. The Profit Center Accounting
(EC-CPA) supports the determination on an internal company's operating result
for profit centers using the period accounting or the cost of sales accounting. Profit
centers are internal organization units that can be formed independent of the
business structures of a concern according to various criteria (e.g., location,
product lines). The consolidation component (EC-CS) permits the more detailed
consolidation reports to be produced for the external (legislators) and internal
reporting system.
The Executive Information System (EC-EIS) should provide decision makers
with access to the company's profit-critical data. Sources of these data can be the
finance information system (i.e., external accounting and cost system), the
personnel information system, the logistics information system, etc.
Sales and Distribution (SO)
This component provides application functions for the company marketing, e.g.,
for the processing and monitoring of offers, the order processing and the
invoicing. In addition to these more administrative tasks, there are also dispositive
tasks such as shipping disposition, shipping logistics and sales representative
support.
Materials Management (MM)
The MM component primarily covers the tasks of the company's procurement and
warehousing. The procurement includes the ordering disposition (monitoring of
the stock levels and the automatic generation of ordering suggestions for the
purchasing and manufacturing), the purchasing (also of services) and the invoice
verification. The warehousing includes stock management (incl. stock level
analysis) and the warehouse management, which, in contrast to the stock
management, also takes account of the physical storage location of the stored
materials.
Quality Management (QM)
The QM component is used for the planning, control and monitoring of the quality
of the company's various products and processes. It is typically used in the
procurement (incoming goods testing, supplier evaluation), in the production (for
the definition of testing criteria and the acquisition of the test results), and in the
marketing (goods testing for the stock planned to be used for delivery).
Plant Maintenance (PM)
PM supports the maintenance tasks with the goal of ensuring that an operation's
technical objects (plants, equipment or even rooms) are in the best possible state,
or, at the very least, meet the legal and technical requirements. It is not normally
sufficient just to meet the manufacturer's specified measures. Consequently, PM
provides methods for preventative maintenance (planning), and for the handling of
planned actions and unexpected fault situations.
Production Planning (PP)
The PP component supports planning and control tasks for the production. The
planning includes the primary requirements planning (requirements for the end
products per time period), the material requirements planning (secondary
requirement) and the capacity (general) planning. The control includes the fine
control using production orders and the production monitoring.
Personnel Management (PA)
PA is used for the personnel recruiting (from the acquisition of the applicants data
through to the filling of vacant positions), the administration of personnel data
(organization structure of the company and the personnel) and the Personnel
Development (PD). The goal of the personnel development is to ensure the future
availability for the qualitative personnel requirements in all function areas of a
company.
Time Management (PT)
The PT component for the personnel time management is used to represent

personnel management processes for the representation, the acquisition and the
evaluation for personnel attendance times of the employees. Support is provided
for various working time models (flextime, normal working time and shifts).
Calendars or other means of managing exceptions are also available.
Payroll Accounting (PY)
This component is used for the payment accounting (wages, salaries, other
payments). Because legal and tariff regulations largely determine its structure,
country-specific configurations can vary widely.
1.4.5 Cross-Function Components
In addition to the company-oriented components, business application systems

also have a number of cross-section systems. These include the classical office
systems such as word processing and spread-sheet systems, workflow
management systems, document management systems, groupware systems,
decision support systems, and executive information systems (EIS). The Rl3
system includes most of these systems in the Cross Application Components (CA)
component.
Document Management (DMS)
The document management of the Rl3 system provides functions to manage

documents that are physically located both within or outside the Rl3 system. The
document management makes it possible to make documents available throughout
the whole company, and to link them with objects of the application system (e.g.,
material master record, update master record, manufacturing resources) from
various enterprise areas.
Documentation Tools (DOC)
With this component, SAP provides the user with the functionality that is also
used for the online documentation of the Rl3 system (which can invoked with the
FI function key, etc.). The user can change the existing documentation or enter his
own comments for objects that have not been documented.
Class System (CL)
The class system has the task of describing arbitrary objects (e.g., material master
records, batches, workplaces) using freely definable characteristics and to group
similar objects into classes using the values of these characteristics. The search for
objects is then performed using the classes and the defined characteristics. This
ensures that objects with the identical value or similar objects can be found as
quickly as possible.
CAD Integration (CAD)
The CAD integration is a coupling of the Rl3 system with external technical
application systems, e.g., for the computer aided design (CAD), for product data
models (PDM) and geographic information systems (GIS).
Computer Aided TesUool (CA TT)
This component is used to test transactions in the Rl3 system. Test procedures,
that cover several transactions, can be defined, run and tested here.
Open Information Warehouse (OIW)
The OIW component provides a standardized interface to access different

information systems from the areas of logistics, accountancy and human relations.
SAP provides a program (add-in) for Microsoft Excel to access this interface that
can be used to define reports.
This component permits the automatic (asynchronous) communication between

Rl3 systems, and between an Rl3 system and an external system. The information
exchange does not take place using a central database, but using a message service
at the application server level (see Section 1.4.1).
Business Framework Architecture
The Business Framework Architecture component combines those technologies

(see Section 1.4.1) that make the R/3 system to be a distributed, extendible and
component-based application architecture.
Internet Application Components (lAC)
The Rl3 Internet application components (lACs, also see Section 1.4.2) provide
selected managerial functions of the Rl3 system in the Internet using a Web
browser.
1.4.6 System Components
Following the function-related and cross-function components, system

components (Basic Components (BC) ) are now presented. This group includes
the operating system and database low-level components, and those components
responsible for the connection of the application system with the user interface
(presentation system SAPOUI). One of the most noticeable characteristics of the
Rl3 system is that works with relational database management systems, computer
systems and front-end computer systems from different manufacturers. Most of
the system components isolate the user from the peculiarities of the various base
operating system and database systems.
Basis Service (SRV)
This component can be used to perform the network configuration of the Rl3
system. This permits settings to be made that permit the Rl3 system to couple with
other systems, etc. In addition to SAP-specific communications methods such as
CPI-C and RFC, standards such as SNA, which is popular in the area of
mainframe computers (IBM, Siemens), are also supported. Newer
communications standards, including CORBA and DCOM, are also supported.
The SRV component also includes functions for the connection of e-mail
(Internet, X.400) , archiving systems (SAP ArchiveLink), and word processing
(SAPScript text editor).
Operating System Platform (OP)
This component represents an abstraction layer to the operating systems from the
various manufacturers supported by SAP. These include UNIX platforms from
Hewlett Packard, IBM, SUN, AS/400 platforms from IBM, and Windows NT
platforms from Microsoft. In future, the freely available Linux operating system
should also be supported.
Database Platform (DB)
This component provides the connection to relational database management

systems from various manufacturers. These include ORACLE (from Oracle), DB2
(from IBM), INFORMIX (from Informix), ADABAS (from Software AG) and
SQLServer (from Microsoft).
Frontend Services (FES)
The PES component includes

• the SAPGUI, namely the classic user interface (presentation client) of the Rl3
system that can be used to invoke all Rl3 functions
• the SAPGUI in Java, a variant of the Rl3 user interface written in the Java
programming language that permits the Rl3 system to be invoked from any
Java-capable Web browser
• the Session Manager, a tool to invoke the Rl3 functionality using a menu
structure; the Session Manager can be individually adapted to the company or
user requirements, and
• the SAP graphics component, which includes a number of components based
on the SAPGUI; the SAPGUI can be used to display and manipulate graphics
(statistics, Gantt diagrams, etc.).
ABAPI4 Development Workbench (DWB)
The ABAP/4 Development Workbench is the development environment of the Rl3

system (see Section 104.7)
Business Engineer (BEW)
The BEW component includes the Business Navigator and the customlZlng
component. The Business Navigator is used for the graphical representation of Rl3
reference model from and the navigation in the Rl3 reference model (see Section
4.7). The Rl3 reference model describes the most important business objects,
business process types, and organizational structuring capabilities of the Rl3
system. The customizing component permits access to the customizing
transactions that are used to parameterize the system. To support this technical
task, various tools are provided that help the planning, control and monitoring of
the implementation project, and also guides that simplify making the correct
settings. The central tool is the Implementation Guide (IMG), see Section 4.9.1),
which can be used to invoke all customizing transactions.
1.4.7 ABAP/4 Development Workbench
The ABAPI4 Development Workbench is the integrated development environment

for the Rl3 system. It is part of the Rl3 base component, which as a form of
middleware, is based on the operating system and the database system (DBMS),
and technical basis of the application level. This workbench can be considered to
be a collection of standard business applications. These applications, and also the
ABAP/4 Development Workbench itself, are ABAP/4 programs.
The workbench provides the user with a complete set of tools. These permit
him not only to adapt existing Rl3 standard applications for individual solutions,
but, together with tools from the ABAP/4 Development Workbench, also to
develop new client/server applications. In addition to the extension and creation of
the Rl3 applications, tools are also provided for the test, organization of the
development and the distribution of the applications.
The following sections initially discuss the ABAP/4 language. Finally, an
overview is provided of the individual workbench tools, and their function and
application described.
ABAPI4
The ABAP/4 programming language forms the central element of the ABAP/4
Development Workbench. The ABAP/4 acronym represents Advanced Business
Application Programming/4th Generation. ABAP/4 is a SAP-specific language that
is based on ideas from COBOL and fourth generation programming languages.
Programs are present as source text in the R/3 system and are converted at run-
time into a macro code and then processed interpretively by the ABAP processor
of an R/3 system work process (see Section 1.4.1). An ABAP/4 program consists
of statements that begin with an ABAP/4 keyword, which can be followed by
clauses and data objects, and terminated with a period. Sequences of statements
with the same keyword can be combined as a statement chain. The language
contains a number of constructions that provide special support for the use of sets
of tuples. These include, for example, internal tables that represent the counterpart
of the external tables of the DBMS and require ABAP/4 commands for the table
manipulation. The Open SQL statements used for database access are independent
of the SQL dialects of the database systems supported by the R/3 system (see
Section 1.3.2). However, native SQL statements can also be used to program
DBMS-specific SQL statements.
The described aspects of the ABAP/4 language concentrate on the processing
logic of the R/3 applications are primarily used for data processing. In addition to
the processing logic, an R/3 application also has flow logic. So-called dynpros (see
Section 1.4.7 and Glossar) define the flow logic for an R/3 application that
controls the interaction with the user. These dynpros, which are created from a
special subset of the ABAP/4 language, run on the Dynpro-processor of a system
work process and are coupled with the SAPGUI. They respond during the
program processing to user actions and pass these to the processing logic by
invoking the associated programs.
ABAPI4 Repository
An R/3 application normally consists of several modules. In addition to the

programs for the flow logic and processing logic, function modules, dialog masks
and menus also belong here. They are all designated in the R/3 system as
development objects and are stored in the ABAPI4 Repository. This repository is
part of the Rl3 database in which all development objects of the system are
managed centrally. Development classes are used to group the development
objects in the ABAP/4 repository. A development class is, for example, the set of
all development objects for an application. Once the work on the development
objects has completed, they are converted into run-time objects, i.e., set by the
development system in the productive system. The Workbench Organizer that is
part of the R/3 Change and Transport Organizer (see Section 4.9.3) is used here.
The user is provided with three tools for navigation in the ABAP/4 Repository:
the Repository Browser, the ABAP/4 Repository Infosystem, and the application
hierarchy. The Repository Browser enables the user to navigate through lists of
development objects, and to organize and manage the development objects in the
ABAP/4 Repository. The Repository Infosystem is used to identify development
objects and their relationships to other objects in the ABAP/4 Repository. For
example, the Infosystem can be used to determine which tables are used in which
ABAP/4 programs. The application hierarchy is a tool that can be used to analyze
the structure of the application components in the R/3 system. It displays the
objects that are used in an application. The developer must assign new objects
from the in-house development into this hierarchy.
ABAPI4 Dictionary, Data Modeler and Data Browser
So-called conceptional data models and, in particular here, the entity-relationship

model have established themselves as the starting point for the database
development process and as preliminary stage for the development of the actual
database scheme (see Section 1.3.2). The Rl3 system also provides the Data
Modeler. This permits the modeling of the contents of the application area of
interest using SAP's Structured Entity-Relationship Model (SAP-SERM). There is
a close coupling between an SAP-SERM scheme and a database scheme that is
based on the assignment of the SERM constructions, the so-called entity types
(refer to Section 1.2.2), to tables, views and foreign keys in the ABAP/4
dictionary, and in the reverse direction. For example, entity type tables defined in
the Data Modeler can be generated into the ABAP/4 Dictionary.
The ABAPI4 Dictionary contains the metadata ("data about data") of the Rl3
database, the database scheme. All elements of a concrete database scheme of an
Rl3 system (such as tables, field and key descriptions) are defined, stored and
updated here outside program limits. ABAP/4 programs can directly access data in
the dictionary.
The Data Browser is a tool that can be used to display the tuple in the database
tables without requiring a special ABAP/4 program. The tool also provides the
capability to branch to the associated test table entries for specific entries. The
Data Browser can also insert and update tuples for those tables for which the
update attribute has been set.
ABAPEditor
It has already been mentioned that not only ABAP/4 programs, but also other
development objects, are objects of the ABAP/4 Repository. The ABAP Editor is
the tool used to edit these objects. Because all objects are stored as entries in
database tables of the ABAP/4 Repository rather than in various text files, as is
often the case, this text editor should be used in preference to other text editors.
The ABAP Editor also permits the import and export of text files. It also provides
a number of typical text processing commands, such as those used to mark and
move text blocks, and also functions for the text searching and replacement.
Screen Painter and Menu Painter
The Screen Painter is used to develop the graphical user interfaces for Rl3 dialog
applications. The Screen Painter tool is used here to store dynpros and to layout
the associated dialog masks together with storing and initiating elements. Storing
elements are input/output fields, check buttons, and radio buttons. These are
assigned variables from the ABAP/4 programs, which implement the application's
processing logic. Initiating elements are buttons. When the user presses a button,
an event is sent to the processing logic of the application, which thus initiates
specific program functions.
The Menu Painter is the tool from the ABAP/4 Development Workbench that
provides the user with menus, symbolbars, button bars and function key
assignments for R13 applications that are used to create and update the graphical
elements for the selection of program functions. All these elements are assigned
function codes in the Menu Painter, which can be sent to the associated program
and processed there when the element is pressed.
Additional Tools
The Function Builder is a tool used to create and manage function modules.
Function modules are programs that make available generally reusable
functionalities and which can be called from any other programs. They are
managed centrally in a function library that the Function Builder can access. In
addition to creating new function modules, the tool is also useful for obtaining
information about existing modules.
The ABAP/4 Development Workbench provides a debugger and the CATT test
tool to test applications. The debugger permits a program to be interrupted at run-
time, and so check the flow logic and the results of the individual statements
during the execution. It can be used to detect errors in the program code. The
CATT test tool is used for the systematic testing of individually created R13
applications and thus for their quality assurance. Complex test procedures can be
built in modular fashion from the individual test modules, which, for example, can
be used to test field values in the database or to respond to changes made to the
customizing settings. The tool creates a log for the test procedures. CATT can also
be used to generate test and training data.
1.4.8 Organizational Structures of the Rl3 System
The SAP provides a predefined organization scheme to represent a company's

structure in the R13 system and to assign R13 functionality to the company's
organization units. This scheme can be assigned predefined rules with descriptions
of the organization units for a specific company (concern, businesses, production
business, production locations, warehouses, purchasing team, sales
representatives, etc.). Depending on the R13 system component, the user is
provided with various organization unit types, to which he can then assign the
company's specific organization units.
The organization scheme is largely structured hierarchically. The highest
organization unit in an enterprise is the concern, which the R13 system designates
as client. If multiple R13 systems must be set up for a company spread over a large
geographical area, the client is represented more than once with partially
redundant data stores on each system (refer to ALE, Section 1.4.1).
The following section discusses a selection of the organization unit types - not
quite correct, but simpler, we speak only of organization units - for the most
important components.
External Business Accounting
Rl3 designates the smallest organization unit for which individual accounts to be
produced to conform with the commercial laws as a company. Enterprise units that
result from tax considerations are represented in Rl3 as company codes. A
company consists of one or more company codes. A company code is the smallest
organization unit of the external business accounting for which a complete, closed
bookkeeping can be represented. Such a company code permits the creation of
individual accounts with balance sheets, and statement of earnings.
National companies or operational facilities for an internationally operating
company are normally represented as company codes. Two charts of accounts can
be defined for each company code, one for the operative management and one for
the classification in accordance with the country-specific laws.
The organization units required for the market or product view (segments such
as divisions, business fields) lie orthogonal to the organization units that result
because of legal requirements. The Rl3 system provides the business area
organization type here. Business areas (see Figure 1.17) are primarily used for the
concern-internal structuring of the enterprise over company codes with the aim of
producing an external segment-related report. This permits the production of
internal balance sheets and income statements, etc.
Business Areas
Figure 1.17: Company codes and business areas

Internal Business Accounting
The internal business accounting requires the definition of which layer the cost
system is to be located. This is made possible using the assignment of one or more
company codes to controlling areas. A controlling area is an organization unit of
the enterprise/concern for which a complete, closed cost system can be performed.
We can generally differentiate between a central (all company codes are part of a
controlling area) and a locally organized cost system for every company code. In
the first case, all company codes must use the same operative chart of accounts.
Although the implementation of a controlling area for each company code
increases the freedom for layouting the cost system, cost-related statements can be
made outside a company code either to a very limited extent or only after
extensive operations.
General LogistiCS
From the logistics viewpoint, the organization units of the enterprise are
subdivided into plants. A plant can be production plants, operational facilities or
branches. A plant can produce materials (PP component) or provide goods or
services (MM and PM). Works are always assigned to a single company code. The
analysis of materials for the material and order calculation can either be made at
the company code level or locally at the level of each plant. A valuation area must
be created to assign the evaluation. Because the plant organization type is used not
only in materials management, production, marketing but also in the maintenance,
the possibly conflicting goals of these areas may need to be resolved. Whereas
from the viewpoint of the materials management, a plant, for example, is
considered to be a stock maintaining unit, from the viewpoint of marketing, it is a
consolidating unit of several marketing organizations and shipping locations, and
from the viewpoint of maintenance, it is an operational facility in which
maintenance measures are planned and prepared.
The R/3 system provides the capability to organize products into groups (so-
called divisions) for the marketing of a wide product spectrum. Divisions are used
for the assignment of materials to business areas, etc.
Materials Management
The materials management provides two further organization unit types for the
purchasing and warehousing task areas, etc. Storage locations are concrete
locations (with address) of an enterprise in which quantified stocks can be
maintained.
Purchasing organizations are responsible for the procurement of materials
(including contracts, conditions, etc.) and services. A purchasing organization can
be assigned to several company codes (central purchasing for the concern) or a
single company code (each enterprise handles its own purchasing).
Sales
Analog to the organization units for the materials management, sales

organizations are defined for the marketing. A sales organization is responsible
for the marketing of certain products and services within a plant. The distribution
channel indicates the path the sellable materials or services follow to reach the
customer. Typical examples of distribution channels are wholesalers, direct
marketing or selling over the Internet. The combination of sales organizations,
distribution channels and divisions can be used to define sales areas (e.g.,
"Northern Sales", "Motor Wholesaling"). They are required for the price control
and the specific evaluation of sales data (e.g., sales analyses).
1.4.9 Rl3 Reference Model
SAP began early to systematically record and catalog those typical business
processes that can be processed with the Rl3 system. It supplies this catalog with
the Rl3 system in the form of the Rl3 reference model. Because the Rl3 reference
model documents the functions of the Rl3 software product with regard to the
supported business processes, the Rl3 reference model is a software reference
model (see Section 1.2.2). Simplified, the reference model is a representation of
the repertoire of available and implemented Rl3 functions. The major advantage of
the Rl3 reference model is in the description using predefined, uniform
terminology of the business contents of the Rl3 system in a form independent of
the information processing. Despite this background, it is also the possibility to
compare the business function repertoire of the Rl3 system with other systems at a
more formal level.
The Rl3 reference model describes business processes in the form of EPC
diagrams (see Section 1.2.2). Business objects are also described. We will
describe these in more detail.
Note that the reference model processes represent only those actions supported
by the application system. In contrast, actions that take place outside the Rl3
system, such as the physical delivery and storage of goods or the manufacturing of
products, are not described. However, interface events (or states) are defined that
occur outside the Rl3 system and result in the execution of transactions (e.g.,
processing of goods arrival and confirmation of manufacturing orders) in the Rl3
system.
Only the users of the system are considered as actors of the Rl3-related
business processes,. In some cases these can also be customers or suppliers when
they have been given direct access to the Rl3 system. Data and information are the
only objects that are created, consumed and transformed. The actions of the
business processes describe the transactions of the application systems that can be
used for the realization.
As we will see, reference models can be used in many situations of the Rl3
implementation, such as for the matching of the enterprise requirements with the
capabilities of the R/3 system, to create planned concepts, designs or for training.
The Business Navigator component (see Section 4.7) and other software products
from SAP partners can be used to view the catalog or the R/3 reference model.
Figure l.18 lists some business processes - more exactly: scenarios with their
low-level processes - of the R/3 reference model.
The structure of the R/3 reference model consists of a number of submodels
from various types and relationship types defined between these model types.
Initially process models and structure models can be differentiated for the model
types. These can be used to describe the structure and the behavior of the R/3
system.
Enterprise process area

Scenario
Process Group
'--_.1..-_-'-_ - ' Process
D
Enterprise Planning
Sales
sales order handling make-to-order
Sales order handling assembly-to-order
Third-Party Order Processing
Direct sale to consignment receiver
Direct sale to retail company
Product development and marketing
D
Supply chain planning
Production
Make-to-order production (with production order)
Repetitive production
Long-term continuous production
Repetitive manufacturing with make-to-order option
Asset management
Revenue and cost controlling
Customer service
Procurement
Procurement of consumable material
Procurement of stock material
Pur hase requisition
Purchase requisition proccessing
Purchasing
Purchase order processing
Transmission of purchase orders
Goods receipt
Goods receipt procesing with reference
Warehouse
Stock placemente processing
Invoice verification
/---"'----' Invoice processing with reference
Procurementof external services
External accounting
Financel management
Retailing
Human ressources
Figure 1.18: Business processes of the Rl3 reference model (selection)

Because the process models form the kernel of the Rl3 reference model, the
term Rl3 process model is often used rather than Rl3 reference model. Business
object models augment the process models. Business object types and
organization units from the Business Object Repository (BOR) or the Data
Modeler (see Section 1.4.7) of the Rl3 system are also assigned to the process
models. This links the process view of the Rl3 reference model with the data view.
Process models
Event-driven process chains (EPC) are the dominating notational form used in the
R/3 process model.
A process can be divided through vertical hierarchical assignment
(decomposition) and horizontal subdivision (concatenation) into several EPC
diagrams. This makes it possible to describe processes that are formed from less
complex EPCs.
The use of decomposition in the Rl3 process model results in a process
hierarchy that consists of two levels of scenario processes and low-level processes.
A scenario process consists of several functions that low-level processes describe
in more detail - often called simply business process or process. To better
illustrate this hierarchical assignment, a process symbol, represented by a violet
rectangle with rounded comers, replaces the function symbol in the scenario
processes. The higher-level scenario processes place the low-level processes in a
predecessor-successor relationship that links them horizontally. The end event of a
process also serves as start event for one or more following processes. Process
guides (see Section 1.2.2) are used here to illustrate this interaction in the
individual EPC diagrams. A process guide is represented as a white rectangle with
rounded comers that is shaded with the silhouette of a hexagon. These process
guides are normally modeled before a start event or after an end event, namely
instead of the process transition of an EPC.
In addition to functions, so-called function variants are also used in the EPC
representations of the low-level processes of the Rl3 process model. Function
variants represent specializations of a function with regard to the object type that
it is to process. The variants of a function have the same start and end events in the
process as the function itself. They are represented as a function symbol that is
shaded several times.
If alternative processes can be used analog to the described function variants
within a scenario process for a process node analog, this is modeled using specific
symbols for process variants in the diagram for the scenario process. A violet
rectangle with rounded comers shaded several times is used to represent these
symbols.
In addition to the EPCs, the value chain notational form is used in the Rl3-
process model. Value chains are used here exclusively as consolidated
representation of the scenario processes. Their diagrams consist of linked elements
with directed edges. These elements describe groups of subprocesses (process
groups) within the scenario process, which, in accordance with its time-related
sequence, are assigned from left to right in a value chain diagram. Directed edges
can be used to indicate the links between the elements. The relationships here are
represented just as simple predecessor-successor relationships.
Business objects, business object models, organization units
Business objects (also refer to Section 1.3.3) are used to represent company
objects such as employees, accounts or orders in the R/3 system and so belong to
the structure models. A business object belongs to a business object type, which is
often also called a class. However, this differentiation is not always made. To
simplify matters, we often just speak of business objects. In the Rl3 system, one or
more entity types (see Section 1.4.7) and the relationships defined between them
are assigned to each business object type, when then represent a section of the
SAP-SERM schemes and thus indirectly the basic database schemes. Because the
data structure assigned to a business object type describes its detailed internal
structure, we speak of the kernel or the innermost layer of the business object type.
The encapsulation of parts of the desired database schemes through the use of
business object types follows the goal of being able to communicate at the
managerial level without requiring detailed knowledge of the relational data
model. With this background, business object types on the one hand are used for
the explicit definition of data structures and their links with other data structures,
whose instances, in particular, must be defined for the development of a
component of the Rl3 system. On the other hand, they describe the data structures
in the granularity with which they can be used by the user to understand business
processes without burdening him with unimportant details.
The behavior of the business objects is determined by its methods. These
methods are the interfaces used to access the data for the business objects.
Primarily, the interface should permit external systems to access the functionality
of the system at business object level.
Business object models are of major interest as part of the Rl3 reference model.
These object models consist of a set of business object types and relationship
types defined between them. Business object models are available as diagrams in
the Rl3 reference model. Business object types in such diagrams are represented
as white rectangles. Whereas black edges are used for associative relationships
between business object types, blue edges are used for specialization relationships.
Because the assignment of the business object types in the diagram determines the
direction of the relationship between them, the diagrams are read from left to
right. Whereas a business object type at the left is an independent element, the
business object type at the right is the dependent element in a relationship. This
convention corresponds to the representation of directed relationships in the
structured entity-relationship model from SAP (SAP-SERM, see Section 1.4.7).
Analog to SAP-SERM, business object models are only represent at one level. The
data models and declarations of the business object types are assigned to them
below this level. These data models are not part of the Rl3 reference model; they
are restricted to the Data Modeler of the Rl3 system. The declarations of the
business object types cover there interfaces, key fields, attributes, methods and
events. The use of business objects for a type is also cataloged through the
processes of the Rl3 system.
The Rl3 organization units (more exactly: Rl3 organization unit types) are
special business object types whose objects are used to represent system-specific
organization structures. Consequently, they are also designated as modules for the
organization structure of the Rl3 system. These are objects such as company code
and business area in the financial accounting. Instances for these business object
types must be created during the customizing (see Section 2.1.3) of the system.
Rl3 organization units can be considered to be business objects that must be
present in the Rl3 system in order to perform processes.
2 Procedure Models for the Application System
Development
2.1 Development and Implementation
2.1.1 Development of Standard Software Systems
Up to and including the 1990s, application systems were principally developed

individually for each company. Mid-sized and larger companies normally also
maintained their own development departments. However, because many of the
software-supported procedures in the companies were similar, software
manufacturers increasingly developed their products to satisfy the requirements of
several companies or at least are easy to adapt to meet the different requirements.
Standard software products were the result of this increasing abstraction of the
one-off situation.
The trend to the use of standard software increased other aspects:
• The crisis in the custom software development: custom software was very
expensive to realize and modify, implementation times were difficult to
calculate and dependent on the "insider knowledge" of just a few developers.
• Because standardized DP services and employees with "standardized"
capabilities could now be sought, the companies became not only less
dependent on their DP department, but also from employees with specific DP
know-how.
• The rapid change of the general situation of the company frequently required
changes to be made to the software, often indeed fundamental nature. This was
especially the case for the fusion of companies or their departments.
As it is easy to appreciate, the form of the software development had to
fundamentally change over the years. Whereas previously every program was
developed as part of a development project or at least for the company itself,
nowadays business application systems are configured on the basis of standard
software products. The user purchases or licenses a product and modifies it
appropriately so that it meets his requirements. This means that rather than the
programming, the selection and the "correct" adaptations of a standardized
52 2 Procedure Models for the Application System Development
application software are paramount. Although we still speak of development, we

particularly emphasize the adaptation of software in the company because it
nowadays plays a much more important compared with the programming.
The development and implementation of business application systems
(application engineering) cannot be considered as being a one-off process that is
isolated from other company activities. Rather, application systems are embedded
in the development of the complete business information system (information
engineering) and consequently in the development of the complete company
(business engineering). The development of a business application system is also
linked with many parallel development projects for various application areas such
as financial accounting and production. Irrespective of which layer you consider in
more detail, you can define typical tasks and phases that are critical for a
systematic development. These tasks are designated as analysis, design,
realization, test and operation. The organization (project management) is an
activity that goes over task boundaries and serves the structure, monitoring and
control organization structure and flow logic of the project. The next section
describes these tasks in more detail.
In the areas of the software development and, in particular, the development of
standardized application systems, these tasks have progressed from being just a
simple company-related process to be a feedback multiloop system.
A loop takes place in the using companies. These use the (new) business goals
and any determined problems to define the requirements made on the future
application systems. These requirements are regularly analyzed and planned
business concepts defined for future application systems as part of the information
engineering. Once a standard software product has been selected, detailed work is
performed to determine how the specified structures of the product and the future
organization of a company can be reconciled. It must be decided to what extent
the predefined software structures and procedures must be adapted to the
organization or whether additional developments are needed in order to provide
adequate support for extended requirements of the company. Finally, the system is
implemented (adapted) and used (operated). If new goals or requirements arise,
return is made to the earlier phases and additional projects are initiated.
A further loop takes place in the software company that developed the standard
software. Such a company does not develop the software in just a single
development project. Rather, such a product is created successively and makes use
of as many users and/or consultants as possible. In every project (and every
subsequent extension project), the users' requirements are analyzed and in a
consolidated form formulated as planned concepts, designs created,
implementations realized, and test operations performed.
It is easy to appreciate that the two loops are closely connected with each other
and their successful realizations depend on each other:
• The software can only have success when it is oriented towards the users'
fundamental requirements.
• New requirements that result from user operation must be recognized by the
manufacturer and realized in the software.
2.1 Development and Implementation 53
• Errors that the user discovers must be reported to the manufacturer, corrected
by the manufacturer and then provided as new versions or error corrections to
make these fixes as fast as possible at the user site.
• The manufacturer or appropriately specialized consultants must offer the user
support during operations and the continuous improvement of his application
systems.
The advantages of this two-loop system are
• the user profits from the manufacturer's increasing know-how,
• the manufacturer through the feed-back from the users continuously extends
and improves the functionality, which
• continuously extends the areas of usage and the circle of users.
Disadvantages are
• the resulting standard software becomes ever more complex,
• the user who requires just part of the functionality, must first understand the
alternatives before he can decide on a selection, and
• the relationship between manufacturer and user becomes increasingly
"anonymous" with the increasing number of users.
To reduce the distance between manufacturers and users, supplementary

services such as early watch services (refer to Section 4.13) and supplementary
products (reference models, procedure models) are offered. There are also a
number of consultancies that concentrate on this problem and mediate between
software manufacturers and software users.
2.1.2 Tasks of the Development and Implementation
Irrespective of whether a software product is specially developed for a company or

standard application software is to be implemented, both require a systematic
procedure. Consequently, procedure models have established themselves in
computer science for the development. They generally orient themselves on the
tasks: analysis, design, realization (or implementation), testing and operation.
Depending on the application area and project size, these tasks are augmented
(e.g., through migration and user support) and weighted differently, and then
assigned time-oriented in phases to procedure models. The following section
introduces the most important tasks as preparation for a detailed discussion of the
SAP procedure models presented in Section 2.2.
Analysis
Analysis in the context of business application systems is the investigation and

description of the application area to be supported (actual analysis) and the
determination of the requirements made on a new or augmented business
application system. The requirements are normally determined before the
"analysts" select an application system. Such analysts can be either your own
employees or external consultants. The requirements are specified on the basis of
one requirements definition.
The actual state and the requirements can be determined using various methods.
These include
• the inventory method in which the required information is derived from
documents
• the interview method in which the individual persons or groups of persons
(conference method, workshop) are questioned, and
• the questionnaire method in which the "analyst" hands a prepared
questionnaire to the persons being questioned.
A weakness analysis is then performed. This tests the appropriateness of the

existing structures and work processes. In particular, business questions
concerning the company form are of interest.
The principal component of the requirements definition is the planned concept,
which contains both the software tasks and notes on the interaction and any
necessary restructuring of the application area. The interaction of employees,
machines and application systems are described here from the viewpoint of the
business processes, etc.
The planned concept is used as basis to initiate a feasibility study. This study
tests whether the envisaged application system can be realized at all and within the
general budget and/or time frame. If the company has decided to use standard
application software, a test is made during the feasibility study which software
products are to be considered, whether they generally represent a solution and
what is the costlbenefit ratio. In addition to the selection of the software product, a
consultancy company to help with the realization is also often sought. The last
step of the analysis phase is the planning of the project. This includes the general
determination of a time schedule and the setup of a project organization. This
project organization must provide clear decision and responsibility structures.
Design
In the analysis, because references to a concrete technical realization would

restrict the solution finding process unnecessarily early, whenever possible, the
requirements should be elaborated in a form that does not contain such references.
A concrete model of the future complete system is only developed during the
design. This, when realized in a concrete software product, should satisfy the
requirements. When a customized software is developed, the question arises how

the complex complete system is to be divided into easily understood units
(components, modules). If a standard software product is to be used, it must be
decided which components and functions are to be used to realize which
requirements.
If the software product is integrated in an existing information system,
interfaces must be developed to the running application systems in order to be able
to realize the cross-application business processes specified in the planned
concept.
The design process for procedure models such as the SAP Roadmap (refer to
Chapter 3) focus on the selected software product. It is assumed here that the
system largely satisfies the user's requirements and these can be covered through
the specific selection and configuration of the functionality. The user is presented
with a predefined software reference model. He can use a customized model to
adapt this his requirements.
Realization
An executable application system that should meet the requirements is during the
realization (implementation). Whereas customized development projects
concentrate on the programming, the requirements are appropriately adapted or
configured for application systems derived from standard software products.
Whereas the customized development normally concentrates on the isolated
implementation of modules, the software motivated modules playa secondary role
when standard software products are used. Instead newer procedure models
concentrate on the business process envisaged with the application system, thus,
provide a more horizontally arranged procedure. Rather than implementing
modules, software products are selected and configured business-process-oriented.
The adaptation of the standard software products, irrespective of the specific
procedure, is also known as customizing.
Testing
Testing checks the input/output behavior of programs (function test) and measures
the performance of the system (performance test). The function test can also differ
between module tests, integration test (to other modules and application systems)
and installation tests (for a change to the computer system).
Because normally an application system cannot be realized in a single step, but
rather continuously extended, the new functionalities must be tested both alone
and in conjunction with the existing functionalities. For this reason normally two,
or even often three installations of the software are necessary. The first system
(development system) is used for the development or installation and configuration
of new components, the second (optional) system (quality assurance system) tests
the new components and the third system (productive system) tests the actual
operation.
Migration
Migration is the change from a system to be replaced to a new application system.

Programs for the transfer of the old data must be developed and the time frame for
the replacement of the old system must be planned during the migration. For SAP
products, the migration from old Rl2 systems to Rl3 systems plays an important
role.
Usersupporl
The future users of the application system must receive comprehensive support
and recognize early that the implementation of standard software is a problem that
makes psychological demands, takes time and requires training. New managerial
procedures based on the software must be determined as part of the training
measures. The operation of the new system is initially learn during the training
and the users given the opportunity during the daily operation to improve their
knowledge and skills. This requires preparing the associated documentation,
organizing internal and external retraining measures, and that the appropriate
contact partners both inside and outside the company provide an appropriate
support for the running operations.
Operation
Although the operation does not belong to the actual implementation and
development of an application system, suitable measures must be adopted to
ensure that the system still meets the users' requirements. This means that security
and backup measures must be performed, and special software tools (monitors)
used to monitor the performance of the system and the access behavior.
Instruments and procedures must also be provided for the maintenance in order
that changes made to the system or updates/upgrades from the manufacturer can
be accepted in the system.
The managing of the change process, the company and thus also its application
systems assumes increasing importance during operations (Thome and Hufgard
1996).
Project Management
The project management's tasks cover the planning, organization, personnel

selection, management and monitoring of a software development or software
implementation project.
The project planning involves the creation of a project plan, which specifies
which (sub)tasks are to be performed, how, by whom, and by when. In particular,
the calculated costs and dates (milestones) must be observed. The difficulty in
measuring the software quality makes the project planning a very difficult process
task that requires much experience.
A differentiation is made between two subtasks for the project organization: the
flow logic and the process structure . The flow logic determines the exact work
flow in accordance with the selected procedure model. The process structure is
used to coordinate the project team by defining the group structure,
accountabilities, competencies, etc.
The heterogeneous nature of a project team and the often high fluctuation of the
specialists place special demands on the personnel selection. In addition to their
qualifications, the individuals must have, in particular, the ability to work in a
team. They must also be motivated through appropriate measures such as an
adequate salary, good future perspectives and an attractive working environment.
The heterogeneous nature of the team places high demands on the management
of a project team. In addition to the personnel management and the delegation of
tasks, the capabilities to support the communication and to avoid or resolve
conflicts belong to the necessary qualifications. The rapid further development of
the information technologies also demands an innovative project management, but
while still taking account of possible risks.
The monitoring task for a software project involves the continuous testing
whether the current project status agrees with that of the project plan. If significant
deviations occur, in particular with regard to the estimated costs or the milestones,
appropriate measures must be adopted.
2.1.3 Adaptation
As previously discussed, business application systems on the basis of standard

software products are no longer programmed by the user, but "merely" adapted to
the requirements of the company. Adaptation (also refer to Hufgard 1994) covers
at least the following three activities:
• parameterization (configuration)
• modification, and
• extension.
Parameterization/Configuration
The parameterization is the most important task involved with the adaptation of
standard software. Before the application system can be used, parameters must be
set to the selected values at definition-time, which then determine at execution
time (run-time) the behavior of the software. Depending on the type of the
software architecture used as basis, the interval between the definition-time and
the run-time can vary. In the best case, the user can immediately make use of the
effects of changed parameters and does not need the program to be reinitialized,
started or even recreated by compiling the program source. The R/3 system
behaves interpretatively with regard to the parameters. These parameters, also

known as customizing data, are set in the database using a transaction
(customizing transaction). The business application components that depend on
these parameters make immediate use (interpret) of these new settings. However,
these are some exceptions, such as for a change to the user authorizations (refer to
Section 4.10), which take affect only when the user has logged on again to the Rl3
system. Time intervals that place a time limit on settings can also be defined for
many settings.
Parameters (customizing data) can generally be used to affect structural and
behavior-relevant aspects of the application system. The structural parameters
include organizational parameters and parameters that refer to the company's
products (RHB materials, products and bills-of-materials) and plants (production
and heating plants). The organizational parameters primarily cover the company's
process structure. This must be structured from both the external (taxation and
business law) and internal (intra-company organization) viewpoint.
These examples show that the transitions between the master and customizing
data are flexible. The Rl3 system separates the master and customizing data that
must be updated at different parts in the system. For example, whereas material
types are offered using a customizing activity, the material master data are
managed as an application transaction using the standard user menu.
Procedure-relevant parameters determine the behavior of the system in
accordance with the selected parameters. A simple example is the price control for
the assessment and account coding of materials. During the customizing it is
possible to specify whether the materials of a material type are to be evaluated
• by default setting either as suggestion or binding (parameter 1), and
• using a moving average price or a standard price (parameter 2).
Depending on parameter I, the default price control procedure for a material

type can be overwritten when a material master is created.
To illustrate this, we can also consider the parameterization to be the
configuration of an And-Or tree (refer to Figure 2.1) whose branches and leaves
must satisfy certain conditions. This permits a subtree of the logistics to create an
arbitrary number ("1 :n") of material types. Zero or one price control can be
assigned to each material type. If a price control is to be assigned, one of the
above mentioned alternatives can be selected. Also an arbitrary number of goods
groups can be created in the customizing of the logistics, which, for example, can
be used later to define reports.
The affected user departments normally decide how a system needs to be
adapted, namely, which structures and procedures are to be accepted by the
system. Consultants and the DP department help the user department to make the
settings. However, because a company must adapt to the changing market
requirements and the resulting changed goals, the settings also do not remain
constant and must be adapted to the new situations. Consequently, the setting
mechanisms (customizing transactions) must be sufficiently easy to use so that the
user department can itself make the changes after consulting the other affected
departments.
0..1 Legend:
/ 7 = And Node (Procedure)
c===:> = Anribute
• = Or Node
- - - _. =contained to·be relationship
Figure 2.1: Configuration tree

A problem with the adaptation is the release capability, namely the requirement
that changed application systems still behave correctly after the manufacturer's
updates/upgrades have been applied. The software manufacturer normally
guarantees the release capability for the parameterization of popular systems such
as the R13 system.
Modification
A second method of adaptation is the modification of eXlstmg application

components. The leading standard software products on the market are nowadays
supplied with development environments that permit programs to be changed to
meet the user's requirements. A problem here is the mentioned release capability,
i.e., care must be taken that the next update or upgrade does not overwrite the
changes with the new supplied standard programs or unexpected interactions
(incompatibilities) arise with other programs.
Extension
The third and most extensive means of making an adaptation is to extend the
application systems with user-written components (customized development).
Here either components can be developed from scratch or derived from existing
components by being copied. The release capability must also be observed here. If
the standard components change, it is possible that interfaces change or even

vanish. Consequently, to avoid unnecessary complications, the user is normally
advised against using the last two adaptation techniques. However, practice has
shown that modifications or extensions to most projects normally involve the
adaptation of a software product.
The R/3 system provides predefined interfaces - so-called user exits - that can
be used to extend the associated components. This permits customized program
extensions to be developed and monitored while being included in the existing
control flow of the R/3 applications.
2.2 Software Development Processes and Procedure

Models
To structure business application systems so that they conform to the user's

expectations and to make a software project calculable with regard to the costs and
duration, in the past, numerous models were recommended for the methodology
(procedure models), both with regard to the development of customized software
and also for the implementation of standard software products discussed here. The
various procedure models are based on comparable methods (procedures). These
are initially introduced here.
2.2.1 Phase Model
The tasks essential for the development and implementation of a software product
are often assigned in a simple, sequential scheme using the concepts from
engineering disciplines such as those used in construction and in mechanical
engineering. Every task here is assigned to its own phase that is limited by a
milestone. A milestone consists of a deadline and a set of results (software
products, documents, etc.) that must be present at this date. The results of a phase
serve as input for the next phase until the result of the last phase is available as a
completed software product. This concept is designated as the (classic) phase
model.
Because, in practice, it is hardly possible to adhere to the phase model, it can be
considered as being an idealized model. Overlapping and returned steps between
phases are unavoidable for non-trivial projects with non-trivial problem situations.
Thus, it is common in software projects that contradictory requirements from the
analysis phase are often uncovered during the design phase. The realization
problems are discovered in the same manner. These problems can be rectified only
by correcting the software design. The appreciation of this fact permits reverse
jumps in extensions to the phase models (iterations, refer to Figure 2.2). Such
reverse jumps must be performed when the checking of a milestone shows that the
results of a phase do not correspond to the previously defined criteria. This can
2.2 Software Development Processes and Procedure Models 61
also result in the partial parallel processing of the phases - e.g. , the analysis is
continued even though the design has already been started.
Analysis h Requirements
1
. 1 defIn!TIon
[ Design Softwa"
1
Design
[ Realization Program sand

documentation
[ Testing
[
1"
Operation
completed «
so ftware product
1
!
Figure 2.2: Iterative phase model
Despite the possibility to return, several questions remain unanswered in the
iterative phase model :
• A runable version of the software product exists only at the end of the test
phase. This produces the problem that although the product may meet the
formulated requirements made in the requirements definition, because of
misunderstandings, it does not satisfy the user' s actual requirements.
• Although companies often understand their problems, they cannot immediately
formulate the concrete requirements for the application systems. The concrete
ideas develop only during the course of a development project, e.g., when the
user tests the first software designs or implementations.
• Often the requirements change during the course of the development. Thus, it
is quite possible that software systems are developed for specific business
strategies that at the time of completion have scarcely no importance in this
form.
• A further problem is the absence of the user in the development process, after
the analysis at the latest. To maintain the schedule specified by the milestones,
the developer frequently avoids making contact with the later users .
2.2.2 Extended Phase Models
Extensions made to the phase model attempt to rectify these disadvantages listed
above. The resulting concepts can be generally summarized with the terms
iterative, incremental, participative and evolutionary procedure.
In the iterative procedure, the development is realized in several cycles. Here
returns from the individual phases into arbitrary phases are permitted, which, in
particular, should counter the mentioned problem of requirements not being
known adequately or being formulated imprecisely. However, because companies
even at the beginning of a project still strive to achieve an implementation that is
as complete as possible, a functioning software product can be made available
only after the first passes have been made through the test phase. Consequently,
the user who has been involved only to answer the developer's questions can only
appreciate the full effects of the development relatively late.
In the incremental procedure, this problem is avoided by producing the
application system successively, namely, the functionality of the system is made
available to the user stepwise. If you combine this with an iterative procedure,
returns to earlier phases can only affect the last extension (increment). Technical
(what is essential to produce a runable system?) and business (which
functionalities provide the user in the next step with most benefits with as lower
costs as possible?) aspects take priority for the selection of the functionality to be
realized. The major disadvantages of the incremental procedure are technical. for
example, basic system functionalities may need to be extended repeatedly in order
to cover the requirements of the new applications. Thus, the conception of these
basic system functionalities requires particular far-sightedness.
In the participative procedure, the software development is considered to be a
cooperative process between manufacturer and user. The user is involved in all
phases (and not just in the analysis phase) of the development process, in which
frequently conflicting interests must be solved by making compromises.
The evolutionary procedure starts with the premise that the requirements made
on the new software product are largely unclear at the beginning. A first version is
initially used to gain experience and knowledge that are then incorporated in the
following versions. The development (evolution) of the application system is a
continuous knowledge process that never actually finishes. In contrast to the
incremental procedure, the functionality is not necessarily continually extended,
but can always be questioned. Furthermore, the influence of the new system on its
environment (feedback) is also taken into account in the development. Instead of
an incremental procedure, there is also the possibility to create "throw-away"
prototypes, which serve only to gain experience and determine the requirements.
Once sufficient experience has been gained with the prototypes, these are
normally no longer used and a new development process is started or a previously
initiated process continued.
2.2 Software Development Processes and Procedure Models 63
2.2.3 Classification of the R/3 Implementation
In the implementation of an R/3 system, a choice is made between a purely

sequential ("big bang") procedure and an incremental procedure.
An incremental procedure is possible in both horizontal and vertical steps. In
the horizontal case, the R/3 system successively provides support for the
company's function units or departments. The R/3 system usually first provides
support for with the components for the external accounting, and then,
increasingly, the tasks for logistics (materials management, sales, production).
This classic case was long known as the "ideal path" for the R/3 implementation.
In the vertical case, although it concentrates on the company's "typical" business
processes, the attempt is made relatively early for the R/3 system to support the
whole palette of tasks. The "80:20 rule" term often used in this context implies
that after the first step (increment) of the implementation, 80 percent of the
business processes that the R/3 system is to handle have actually been completed.
The remaining 20 percent are then realized in later steps.
It should be appreciated during the R/3 implementation that this process is
often part of a higher level project. This permits a company to recognize during
the strategic reorientation that a new (standardized) application system is needed
or the necessary and cost-intensive implementation of a new system needed in any
case for operative reasons can be the reason to consider the necessity for a
fundamental reorganization of the company structure and processes (business
process reengineering-project). In both cases, it is hoped that the implementation
of the new software results in a technically simpler and faster realization, but also
the questioning of the existing company structures and procedures provides the
opportunity for the managerial restructuring of the company.
Care should normally be taken during the implementation that it is not
restricted to the configuration. Parallel projects must often be defined in an
implementation project in which other adaptation steps need to be performed in
order to completely cover the company's requirements. These adaptation
capabilities include, for example
• the modification / further development of existing R/3 standard functionalities,
• the development and inclusion of components from other manufacturers,
• the use of the Internet or other communication paths to include systems from
business partners, irrespective of whether they are end users or suppliers and
major customers, and
• the development of workflow applications.
Thus, the procedure for the R/3 implementation depends both on strategic goals
and the degree to which the standard functionality of the system meets the
requirements.
2.3 SAP Procedure Models
2.3.1 AcceleratedSAP - The Accelerated Rl3 Implementation
The SAP has initiated a program with AcceleratedSAP (ASAP) to bundle

experience, documents and tools for Rl3 implementations "under a single roof'
and to use this as basis for a standardized procedure. As such, ASAP is less a
classic procedure model as rather a soundly-based initiative to reduce the time and
costs for an Rl3 implementation (the familiar meaning "as soon as possible" for
ASAP emphasizes the aspired time saving) and to improve the quality of the
implementation.
The tools incorporated in ASAP have been taken from a large number of
worldwide users and consultants from many industries. The central starting point
for ASAP is a hypertext system (Implementation Assistant, refer to Section 4.2)
used to navigate in the descriptions of the procedure models and to invoke various
tools and Internet services with the click of a mouse.
Although the original aim of this initiative was to simplify the implementation
of the R/3 system and thus reduce the time involved, ASAP is increasingly being
extended with solutions to questions related to the Rl3 implementation, e.g., for
version changes (upgrades, updates). ASAP Version 4.0 (December 1998,
German), on which this book is based, provides three procedure models
(Roadmaps) as starting point for the navigation in the hypertext system, namely
• for the implementation (Implementation Roadmap),
• for the continuous improvement of the application system (continuous
optimization), and
• for upgrades (Upgrade Roadmap).
The SAP procedure models are organized hierarchically. Every procedure

model consists of several phases. A phase consists of a group of work packages,
which are themselves subdivided into activities. An activity contains a number of
tasks. Because of the size of the procedure model - it encompasses several
hundred printed pages - we cannot provide a detailed description of all phases in
this book. We mention here only the most important tasks and subdivide these
according to phases and work packages. Following a short description of each
phase, the sequence of the work packages, as recommended by SAP in the project
plan template is shown graphically. Each work package is then described briefly.
2.3 SAP Procedure Models 65
2.3.2 Additional Roadmaps
Because the Implementation Roadmap is more oriented towards the requirements

for companies with few locations and simple concern structures, the SAP also
developed support suitable for larger companies. The specially tailored ASAP
version for concern-wide Rl3 implementations ("concern roll-out") under the
name Global ASAP that has been available since May 1999 handles the business
and technical questions, etc., that arise during the Rl3 implementation resulting
from the distributed operation of multiple Rl3 systems.
2.4 Tools for the Implementation and Development
The major goal for the adaptation of an application system is the execution of the
parameterization, namely the execution of the customizing transactions. A
fundamental problem involves making the "correct" settings. Several tools that
support the user in attaining this goal are available. Analog to the implementation
tasks, we can differentiate between function-related and cross-function tools. The
function-related tools presented in Section 2.4.1 serve individual tasks such as the
analysis of the requirements. The cross-function tools presented in Section 2.4.2
support tasks such as the inter-phase project management.
2.4.1 Function-related Tools
Analysis tools
Questionnaires and checklists are often used for analysis. These can be provided
either on paper or interactively on a computer. Irrespective of the selected method,
a formal terminology system for the investigated application area is produced
from the results. Such a system is normally presented to the users as a graphic
model (diagram). There are many diagram languages, for example the entity-
relationship model, the languages of the ARIS views (refer to Section 1.2.2) and
the UML (Unified Modeling Language), for which the software manufacturers
also provide appropriate tools. These can be subdivided into CASE tools
(Computer Aided Software Engineering) and enterprise modeling tools. CASE
tools are normally used for the development of new software product. They
support the software developer starting at the analysis through to the
implementation, test and operation, when appropriate. In contrast, tools for the
company modeling are more managerial oriented. They focus on the analysis of a
company (area) for the improvement of the company structures and processes.
Optimization criteria can be costs, processing times and quality. Because the
solution of managerial problems often involves the use of new application

systems, the methods and tools for both areas are closely related.
Sometimes it is appropriate to use analysis tools already during the interviews.
In this case, the organization structures and business processes of a company area
can be entered with the formality criteria tested by the tool. The involved persons
than can directly view and evaluate these graphical models. The problems here are
that these tools often provide too little support for the systematic procedure, the
graphical input of the information may be very time-intensive, the resulting
models rapidly become very complicated, and the questioned persons cannot
immediately understand the graphical models.
Although the same tools are often used for the documentation of planned
concepts as for the analysis of the requirements, the existing actual states are not
recorded and documented, but rather future structures and procedures of
customers and application systems describe how they should present themselves to
the employees in future.
Software reference models (refer to Section 1.2.2) can be used for the software
selection of the standard software products and later used for the creation of
planned concepts. This permits future business processes to be explained at an
early stage.
Design Tools
The future application system is designed in the design phase. CASE tools that
help the developer for the design of the system are used during the customized
development. The use of standard software products raises the question which
requirements of the planned concept are to be covered by which structures and
functions of the application system. Because the assignment at the general level is
always easy, this problem of reuse of existing programs normally does not arise
during the general design, but only during the later detailed design. In the case of
the Rl3 system, the accounting tasks are obviously realized using components
from the financial accounting (PI), the requirements of the ordering system
realized by functions from the MM components, etc. However, the assignment is
no longer simple when more special questions such as the design of Rl3-specific
company structure are discussed. Tools such as the Concept Check Tool (refer to
Section 4.6) that use an interactive question-and-answer mode to test planned
settings for company provide initial indications of possible problems.
Although software reference models can also be used as basis for the design
documentation, they must not be considered to be a finished design. Rather, they
must be "trimmed", "extended" and, with the assignment of reference model
objects (processes, organization unit types, etc.), individually adapted to the
company's objects (mapping).
2.4 Tools for the Implementation and Development 67
Implementation tools
The customized development is understood to be primarily the programming of

previously designed components. Standard software products contrast with ready-
programmed software products that only need to be adapted. There have been
various techniques and tools in the still short development history of standard
software products. The simplest orient on the software development techniques
already known in the area of "software configuration management". Whereas
these techniques could be used without requiring detailed knowledge of the
programming environments, modern standard software products provide the
configuring team (in ASAP, the members of the business process team, refer to
Section 3.1.1) with a graphic user interface that gives them the same user-friendly
environment as the end-user. Because most of the configuration settings are also
stored in the tables of the database used as basis for the applications, the
configurator is provided with special customizing transactions with which he can
make his settings. Because configuration settings are highly interdependent and, to
ensure that no configuration settings are forgotten, the navigation tool (refer to
Section 4.9.1) leads the configurator through the individual transactions.
Tools to test the implementation are provided both for the customized
development and for the implementation of standard software products. Generally,
tools can be differentiated into those for smaller function tests and those for the
subsequent integration tests.
2.4.2 Cross-Function Tools
Cross-function tools include not only typical office systems such as word
processing and spreadsheet programs, but, in particular, project management
systems and repositories. We assume knowledge of office systems - such as the
popular MS Office palette - but instead concentrate on the other two tool types.
Project management systems
Project management systems (refer to Section 4.3) provide support for all tasks
involved with the planning and control of projects. At the start of project
• the process structure of the project in which all project members (project team)
are entered as resources, and
• a project plan in which deadlines, cost rates, responsibilities and personnel
involvement are defined
must be created. Confirmations from the project can be determined during the
course of the project and input as actual deadlines. These planned-actual data can
be used as basis to monitor the project progress. For further control of the project,
new, updated plans can be created and then used as the new planned specification.
Repositories
Repositories are systems that manage the information about the objects from the
software development and implementation (e.g., planned concepts, reference
models, masks, structures), their description and relationships to each other. Such
repositories are available for the evaluation and the future use during the project
progress. Thus, the managed data are metadata, i.e. "data about data". A repository
does not contain concrete objects, such as the order with number 1234 from
company A to company B, but rather information on the structure and the status of
orders ("an order of type X has a number, a project sponsor, a supplier, ... ").
From a software point of view (refer to Section 1.3.1), a repository is a server at
the application level that uses standardized interfaces to provide, if possible, all
tools used in the project with access to the stored information and the capability to
set new information. These servers also use database management systems.
Repositories in the R/3 system are an integral part of these database management
systems.
Current popular standard software products often have two repositories. One is
used for the information during the implementation, because at this time the
application system is not yet fully available. The other is used during operations
and the further development of the application system.
3 The Implementation Roadmap
Chapter 3 introduced the Implementation Roadmap, the current standardized

methodology for R/3 implementations of the SAP. It is not possible to avoid
mentioning and briefly characterizing the tools already used for this procedure.
Chapter 4 provides a detailed description of the tools.
The Implementation Roadmap is primarily based on a sequential methodology
and consists of five phases that are executed successively
• Project preparation,
• Business blueprint,
• Realization,
• Final preparation and
• Go live and support.
Figure 3.1 shows these phases as a predefined project plan. This is a six-month
plan - the last phase no longer belongs to the implementation time - that will be
described in detail in the following phase descriptions down to the level of work
packages. All figures have been taken from the project plan that is supplied with
the ASAP CD-ROM (refer to Section 4.3).
01 02 03
No Task Name 1 Days M-1 M1 M2 M3 M4 M5 M6 M7 M8 M9
Phase 1: Project Preparation 15
---:;-- Phase 2: Business Blueprint 25
--;-;-- Phase 3: Realization 55
30 Phase 4: Final Preparation 35
~ Phase 5: Go Live and Support 23
Figure 3.1: Project plan

•
Although the six-month plan must be adapted to meet the project requirements,
it is well suited to be used to get a "feeling" for the times estimated by SAP or for
the time-related relations between the phases.

70 3 The Implementation Roadmap
3.1 Phase 1: Project Preparation
The preparation phase is used for the planning and preparation of the complete
implementation project. Some of the central work packages (refer to Figure 3.2)
provided for this phase must be performed independent of the R/3 system in
almost every project. Thus, general project management principles, etc., are listed,
which, when followed, increase the probability of project success. Important
prerequisites for the project
• clearly defined goals are assumed; it must be determined which managerial
tasks the new system is to serve and which goals are to be followed with
implementation,
• the implementation strategy (sequential, iterative, ...) has been specified,
• the project plan with the individual project phases, work packages, activities
and tasks to be performed have been defined,
• the project organization with its competencies has been specified,
• the project standards for procedures and documentation have been specified,
• the project budget has been approved, and
• the request and the assignment of the resources (personnel, rooms, computers,
etc.) needed for the project has been made.
Monlh1
No Task Name Durallon 2]. 30. 02. 05. 08. 11 . 14. 17. 20. 23. 26. 29. 01 .
1 Phase 1: Project Preparetlon 15
Inilla) Pro;eet Planning 7.5
Pro,ed Procedures 3.5
Projec1 KlckoH
Technical Requirements Planoirlg
OualilY Check Pro}ect PreparaHon Phase
Phase 2: Buslnen Blueprint 25
Figure 3.2: Work packages of phase 1

Other packages of the phase concentrate on the technical aspects of the R/3
system and serve the short-term provision of computer resources for the
implementation and the long-term provision of the productive system.
One item often noted in the Implementation Roadmap is that the special
success factors of an R/3 implementation for the project must be observed. These
factors include the requirement that the project charter and the planned project size
are clearly defined and can be changed only using specified procedures.
Competent employees must also be made available for the project - despite the
dilemma that, in particular, mid-size companies have: These employees are
normally also "essential" for the day-to-day work. A further factor is that the
3.1 Phase 1: Project Preparation 71
company's top management takes part in all important decision processes and
adopts a clear position for decisions that are made.
3.1.1 Initial Project Planning
Project charter
In comparison to the tasks of the classic procedure models introduced in Section

2.1.2, tasks and results are again presented in this work package. Some of these
have already been discussed as part of the analysis made prior to the selection of a
standard software product and must have been documented in a system
specification. However, in many R/3 projects the decision for this system did not
result from such a classic procedure. Often concern policy forced the company
management to implement the system without first being able to make concrete
requirements. Or the company decided for R/3 at relatively short-notice, because
of the market importance of the R/3 system it can be relatively sure that R/3 "fits"
and so can solve currently outstanding problems, such as the millennium change
or the implementation of the euro. In particular in these two last cases, it is
essential for the project realization that all additional and previously non-
formulated requirements from the company management and the departments are
determined and documented.
Consequently, at the start of the project, the principal reasons and goals for an
R/3 implementation project should be noted. The concrete requirements (business
drivers) associated with the R/3 implementation, are, for example
• reduced processing times for customer orders and
• reduced inventory levels for products and/or consumables,
should be documented explicitly and quantified to the greatest possible degree.
This requires the determination of (actual) key figures and planned improvements
before starting the R/3 project. This then provides an objective basis for the
assessment of the complete project.
In addition to these long-term factors, the best possible starting basis must be
provided for the project. This requires the definition of project key figures
oriented on the subgoals. For example, project milestones define when the design
(blueprint) is to be completed and which business processes must be handled with
the R/3 system by a specific date. In addition to the orientation to R/3 components
and the question when an R/3 component becomes productive, the question arises
which percentage of the company's business processes is to be handled using the
system. For example, the fact that the marketing component should be productive
by a specific date says nothing about the extent to which all types of sales-oriented
business processes (sales handling by wholesalers, direct sales over the Internet,
etc.) are integrated in the DP-part of the R/3 system.
All reasons, initiations, (sub)goals, requirements associated with the R/3

implementation are summarized in a project charter (similar to a system
specification) and approved by the company management. This project charter is
then distributed to all project members.
Project management
All project tasks included in a common project organizational structure are

performed by the company's employees or a commissioned consultancy. This
organization is used for the efficient processing of the tasks specified by the
requirements. The organization structure consists typically of a steering
committee, a project management and several project teams. The project teams
include the business process teams and the technology team (see below). The
steering committee consists of the persons with the main responsibility for the R/3
implementation. These are responsible for
• the long-term goals of the R/3 implementation,
• the approval of the required resources,
• the monitoring and control of the project progress, and
• the conflict management, etc.
The steering committee (refer to Figure 3.3) adopts at least the role (see below)
of the project sponsor, the customer project manager, the SAP project manager
and the SAP consulting manager. Depending on the company structure, other
persons may need to be added from the management level.
The project manager is responsible for several business process teams, which
each includes a business process team manger and a number of team members
(specialized employees). Such a team is responsible for the business processes of a
company process area (refer to Section 4.7.2), for example, the procurement, and
the individual members within this area are responsible for the associated function
areas such as purchasing and disposition.
3.1 Phase I: Project Preparation 73
Business Proces
Team Lead n
Member of the Member Of The Member of the

BPTeam BPTeam Technology Team
Figure 3.3: Project organization structure

In addition to these business-oriented teams, there is also a technology team for
the technical support of the project. This team is also indirectly responsible to the
project manager and directly responsible to a team lead. Depending on the
complexity of the projects and special requirements, this team is assigned
members that undertake tasks such as
• system administration and security management,
• data protection,
• database administration,
• network administration, and
• development (ABAP/4, SAPScript, Forms, etc.).
Employee roles in the project
The steering committee and the project teams have various roles that are
"placeholders" for employees with specific task packages and the associated
necessary qualifications. Depending on the project charter and size, these roles are
occupied by specific company employees or external consultants. It is quite
possible that one employee can assume several roles. SAP has predefined the
following roles:
I. Project sponsor: The project sponsor belongs to the company management and
accepts responsibility in the project for the company's long-term goals and
strategies. He alone is responsible for the success of the complete project and
so must also justify the Rl3 implementation in the company.
2. SAP project manager: The SAP project manager is a consultant commissioned
by the company and has considerable Rl3 knowledge with experience gained
from several implementation projects. He assists the company's project
manager with the definition and creation of project documents (e.g., project
charter, project plans) and supports him with his day-to-day work. In addition
to specific SAP knowledge, he also has special knowledge of the ASAP
concept , namely procedure models, methods and tools used for Rl3
implementation projects. If necessary, the SAP project manager helps the
individual business process teams to perform their tasks.
3. Customer project manager: The company project manager is responsible for
the day-to-day project management and acts as mediator between the project
sponsor, the SAP consultants and the team members. SAP and customer
project managers divide their tasks and responsibilities in accordance with
their capabilities. The customer project manager should know the company
very well and, in particular, have good communications capabilities and
management qualities.
4. SAP consulting manager: In order to estimate the costs and effort involved
with the Rl3 implementation and the use of SAP consultants, the SAP
consulting manager works together with the sales representatives (from SAP or
partners) right from the project start, namely during the software selection
phase. Afterwards he is available to advise the project by attending the
meetings of the steering committee and the project managers. He must have a
comprehensive knowledge of the Rl3 functionality and understand the SAP
procedure models.
5. SAP consulting manager for technology: The SAP technical consultant during
the software selection phase estimates for the sales representative the size and
cost of the technical components probably required for the Rl3
implementation. Later he supports the SAP project manager and the team
members for technical questions.
6. Quality auditor: The quality auditor is responsible for the assessment of the
Rl3 project progress and for the monitoring of the milestones and project
deadlines. He performs regular project reviews and makes recommendations to
both the project team and the steering committee. The quality auditor should
not come from the company itself.
7. SAP application consultant: An SAP application consultant is an expert for
one or more company process areas. He has Rl3 application knowledge and
knows how he can use Rl3 to meet the company's requirements. He supports
project teams by making use of his Rl3 knowledge to search for appropriate
solutions and during the configuration of the system.
8. Business process team lead: The business process team lead is responsible for
the project results of your business process area(s) and, together with the
project manager, defines the application areas of the Rl3 system, creates
project plans, assigns resources to these and monitors the progress of the
project. He is responsible for the realization of the plan concept and thus
during the design for the required assignment of the company tasks to the
functions of the Rl3 system. Once the design has been completed, he is also
responsible for the configuration of the system and ensures an appropriate
documentation and the definition of test scenarios.
9. Member of the business process team: The members of the business process
team (business area employees) require knowledge of both the application area
and also know-how for the business application systems. They determine the
requirements for the process area, perform the design and the configuration in
their application area and the integration tests with other business process
areas.
10. Business process owner: The business process owner is the employee
responsible for a company area (e.g., department manager). He works together
with the business process team lead on the Rl3 implementation in his area by
having major involvement in the form of the planned concept. He is also
responsible for the success of the project in his area. Business process owners
normally belong to middle or upper-management of the company and, under
some circumstances, can also be members of the steering committee.
II. Power user: The power user also works with the process team and is
responsible for answering the company's country, location, and business-
process-specific questions. He provides information and documents for those
typical tasks of his that are needed for the successful implementation.
12. Documentation developer: The documentation developer is responsible for the
creation of the user documentation that he completes together with the project
team members. The documentation should be used for both the end-user
training and for the support during the daily work.
13.End user training and development (EUTD) - trainer: The persons who
perform the end-user training prepare these training courses together with the
project team members. Training schedules must be prepared, a trammg
environment created in a computer system, and concrete training courses
defined and performed.
14. Technical team lead: The manager of the technical team is responsible for the
provision and the management of the technical infrastructure. Together with
the customer project manager, he completes the technical requirements that
have already been partially defined during the software selection phase and is
responsible for the design of the DP architecture and the resource planning in
the technical area.
15. Help desk provider and manager: The help desk provider is responsible for the
creation of a long-term support (help desk) for the users for both technical and
business aspects. In particular, at the start of the Rl3 operation ("go live"), this
task is performed by the business process teams and the system engineering
team. If these teams can no longer help, use can also be made of SAP services
(refer to Section 4.13).
There are also a number of further roles, which, depending on the size and
complexity of the projects, have different importance. These roles are mentioned
only briefly here. The current ASAP CD-ROM contains a detailed description.
A change management team is formed from company employees to provide
help with the company's reorganizations ofthe structures and processes caused by
the Rl3 system and interfaces to other companies (business partners such as
customers and suppliers).
There are also a number of employees in the technical project team that is
responsible for the development of new programs, for changes to existing
programs and for the inclusion of other programs. These include various
developers (ABAP development, layout development, development of cross-
application components). Other employees, such as system administrators,
database administrators, network administrators, and administrators for
authorizations, are responsible for the management of the Rl3 system.
It is essential that a project organization is defined in which the roles have been
assigned to qualified employees and/or consultants. The range and differentiation
of the roles recommended by SAP makes clear the extent of the required personal
engagement of an Rl3 implementation and the difficult task of the management of
such a large team by the steering committee and its members in each of their roles.
Other resources
In addition to the task assignment and the planning of the "person resource",
resources required for the project such as rooms, computers and communications
forms (e-mail, telephone, etc.) must be defined and procured. The timely
availability of resources helps with the early exchange of information between the
project members.
Rl3 training courses must also be planned and booked within this work
package.
Project plans
In addition to the project charter, there are also a number of other important
documents required throughout the complete project. These include:
• The project work plan: All information associated with the project
management that is to be monitored in a project plan should be managed with
a project management tool (refer to Section 4.3). ASAP provides predefined
project work plans that contain the time-logical sequence of the tasks to be
performed as part of the implementation. These project work plans were
derived from the phases, work packages, activities and tasks of the
Implementation Roadmap, and can be extended by adding special company-
specific tasks. Additional roles can also be added to the existing roles - these
were also taken from the Roadmap - and the start and end dates and the
planned duration of the individual steps defined. To permit the progress to be
monitored, status such as "running task", "completed task", "needs to be
checked", "quality inspection completed", "task not relevant" should be
defined and during the course of the project used for confirmation and
evaluation.
• The project budget plan: In addition to the date planning, the project budget
must also be determined more exactly than it was at the time of the software
selection. The budget must take account of such items as the personnel costs
(both internal and external employees), hardware costs (computers, printers,
networks, etc.), software license costs, training costs (in-house and SAP
seminars), service costs (e.g., SAP service) and travel costs. A predefined
generally structured budget plan is also available for the project manager.
• The project resource plan: The personnel resources must at least be planned
generally. This requires specifying when, which employees, in which project
phases, and for which percentage of their working time are to be made
available.
3.1.2 Project Procedures
To simplify the day-to-day processing of the project tasks and the communication
with other projects and the company's organization units, it is desirable to define
standards for the structure and the processing of the further project phases. They
should ensure that tasks are not duplicated or performed unnecessarily, to
guarantee the logical consistency of the overall implementation and to simplify the
communication between the project members. Clear decision structures are not
mandatory here.
The project teams and the steering committee should meet at least weekly and
monthly, respectively. Initially, the meetings may need to take place more
frequently than during the later phases that realize the concepts detailed in the
earlier phases. In these meetings, the project status is discussed and checked
whether decisions have been realized, the status of the pending tasks reported, and
new tasks defined and assigned. The ASAP CD-ROM contains appropriate forms
(templates) for the preparation required before and after meetings. These
templates can be used as basis for project-specific forms (agendas, reports).
Communications paths (distribution lists, e-mail) must also be defined that
describe how internal and external employees are to be informed.
Additional document types must also be defined for the project documentation
for
• the description of business processes,
• the user documentation (for training and for the daily work),
• the Rl3 configuration and customizing settings,

• the work papers of the project teams,
• the design and development of company-specific Rl3 extensions,
• updates on the basis of corrections supplied by SAP (aSS Notes and Hot
Packages, refer to Section 4.14.3) and
• service reports (e.g., analysis reports of SAP services, refer to Section 4.13)
and documentation.
The Implementation Roadmap (refer to Chapter 3) also provides templates for

some of these document types. These templates can be extended to cater for
company requirements. Software tools that simplify the creation of the appropriate
documents should be selected for other document types. For example, SAP, in
particular for the description of business processes, recommends the use of tools
for the business process modeling that can access the Rl3 reference model (refer
to Section 1.4.9). ABAP/4 Development Workbench (refer to Section 1.4.7)
components can be used for the design of company-specific Rl3 extensions, etc.
Another important item of this work package is the definition of a number of
guidelines that help with the overall organization of the project. The provision of a
issues database (refer to Section 4.4.3) is recommended to permit the systematic
recording and tracking of any problems that occur during the project. The
problems are stored in the Question and Answer database (Q&A database, refer to
Section 4.4), which is also supplied on the ASAP CD-ROM.
Other guidelines affect the management of the application area and of the
project content as part of the R13 project. At the start of the project it is defined
which company areas are to be supported by which functionalities of the Rl3
system. Because the project team's increasing experience with Rl3 can quickly
change these boundaries, care must be taken that these do not change arbitrarily.
For this reason, larger changes to the project content should be requested formally
(refer to Change Request form, Section 4.14.1), assessed for cost effects and the
availability of resource capacity, and approved by the steering committee. Any
changes should be documented.
Guidelines for a phase-related embedding of SAP services must also be
defined. Such services can be used for quality assurance measures, etc.
For the later phases (from the realization through to go live), it must be
specified for the configuration of the system which employees, at which time of
the project, and in which way are permitted to make changes to the system.
Depending on the type (global settings, organizational settings, master data
settings, transaction settings, customized developments), changes must be
performed and documented in different ways.
Strategies must be detailed for the quality assurance of the system. These are
used later to test
• the functions of individual components,
• the interaction between several components (integration test),
• the user acceptance,

• the performance and the response time behavior of the application system for
the processing of large data volumes and many transactions, and
• any necessary data changes, updates and upgrades.
End-user training courses needed for the later operation of the Rl3 system must
already be defined generally.
Implementation strategy
The implementation strategy specifies the processing scheme for the individual
tasks of an Rl3 implementation. The specification of the strategy must take
account of at least the following dimensions of the implementation:
• The methodology: It determines whether the Rl3 system is implemented in one
sequential pass ("big bang") or in several steps (incremental).
• The company areas: If the Rl3 system is to be implemented in several steps,
the criteria used to assign these steps must be defined. The extremes here are a
task-oriented or a process-oriented progression. In the first case, the individual
phases are structured to take account of the task grouping within the company
(organizational structure). In the second case, the steps are structured to take
account of the business processes that extend over department limits (task
flow).
Depending on the size and form of the company, regional aspects of the
implementation (where are the affected company areas located?) and
dependencies from the previously implemented application systems (when at the
earliest/latest must/can a system be replaced?) must be taken into consideration.
The results of this structuring are discussed amongst the project management,
the project sponsor and the affected business process teams, and the results
recorded in a document (enterprise process area content document, or EPA
document). The recommended assignment is based on the structuring of the Rl3
business process models. The scenarios and their processes are listed there for
each company area. A specific scope, a business process owner and a consultant
are assigned to each process. All the involved persons agree in writing.
If Rl3 implementation dependencies exist to other (possibly Rl3 related)
projects of the same concern, these must be recorded systematically, and any
conflicts and redundancies recognized and rectified successively. It is sometimes
desirable
• to define concern-wide standards for data formats,
• to standardize the reporting system,
• to strive for a consistent organizational structure and task flow, and
• to define consistent master data, which, for example, are organized centrally.
In addition to the structural comparison mentioned here, it is important to agree

guidelines that apply throughout the concern to ensure a consistent data storage,
also during the day-to-day operations.
An appropriate user support must be provided once the system has been
commissioned. For example, plan help desk systems and specify in which cases
and within which time frame, which persons provide help. The appropriate
members from the business process team must be provided to answer business
questions. Members from the technology team are required for technical
questions.
A security concept must be prepared to protect the company data from
unauthorized access.
Define the system landscape
Another task of this work package is to provide a general definition of the so-
called system landscape, in particular the number of Rl3 installations that are used.
SAP recommends the use of at least three separate Rl3 systems (SAP 1998); one
each for the development (DEV), the quality assurance and tests (QAS), and the
productive operation (PRD). If the development environment is used to make
major changes or extensions to the system during the implementation, the
configurations should be performed on a dedicated system (CUS) and not on the
development system (DEV). Although these systems do not all need to be
available at the start of the project, it must be specified when the individual
systems are required. In addition to the development, test and operations, the
systems are also used to train the end-users and to demonstrate intermediate
results. Thus several clients (refer to Section 1.4.8) with different tasks must be
installed on each Rl3 installation, which is identified with its own system [D.
Because the clients in some areas must access client-independent data tables,
special dependencies must be taken into account. For example, development
objects - ABAP function modules, dynpros, etc. - belong to the inter-client
settings and so are visible for all clients of a system. The following client types are
conceivable,
• reference client (SAPR) for upgrades to the Rl3 system,
• sample client (SAPS) of the Rl3 system,
• EarlyWatchService client (SAPE) of the Rl3 system (refer to Section 4.13.1),
• development client (DEW) for customized ABAP extensions and changes,
• customizing/development client (CUST) for customizing and minor
developments (when DEVT does not exist),
• sandbox (SAND) for general tests by inexperienced users (for example) or to
test alternative customizing settings,

• test client (TEST) for tests that the project teams wish to perform,
• quality assurance client (QTST) for tests that an independent test team
performs,
• training client (TRNG) for training courses for end-users,
• customizing-master client (MAST) for the parallel transfer of the configuration
settings in a nonproductive clients (PRD), and
• productive client (PROD) for the actual operation in the company.
Depending on the form of the R/3 implementation project, various assignments

between clients and Rl3 systems are appropriate.
Figure 3.4 shows a sample assignment of clients to a system landscape with
three systems (three-system landscape). To achieve a productive system, transport
paths must be specified (indicated in the example as arrows) over which the
developed versions are forwarded from the development system to the productive
system as part of the implementation (SAP jargon: transport).
DEY
51e1-+-+--+-+--+-+--1----1
~*
.:2>-
~-----+---r--+-~ >-~~_4---+---r--+---r-~--_1
PRJ 8~
- - -- = Transport - - - - - .. =Clienl copy D

Figure 3.4: System client assignment (example)
The last task of this work package concerns the version management (refer to
Section 4.14.3). It must be specified here when the Rl3 installations are to be
replaced with newer versions. Guidelines must be prepared that are used to define
whether a new version (or even only an error correction) is to be installed and in
which time intervals the various Rl3 installations are affected. The following items
must be taken into consideration,
• which persons are capable of performing version changes,
• how long the affected systems cannot be used, and
• who is affected by these system failures (downtime).
3.1.3 Project Kickoff
This work package is used for the official project start. If only selected employees
and consultants were previously involved in the project, this official start should
increase the awareness of all involved employees for the Rl3 project. The
employees should be motivated and, in particular, informed about the set goals,
the specified methodology, and the aspired time plan. The tasks of the individual
team and committee members (refer to Section 3.1.1) should also be clarified. The
results from the first phase such as project charter, organigrams, project standards,
work schedules, and communications standards and communications paths should
also be presented.
Public information systems such as e-mail, Intranet and notice boards should be
used to inform the company's entire workforce about the start of the project.
These information systems are also used for subsequent status reports and
important changes, such as system updates.
These produced guidelines and standards are presented in detail to all involved
project members in another meeting of the members. These include the plans
about regular project meetings, document standards (agendas, reports, status
reports, business processes), the handling of problems and project changes,
configuration standards, authorization concepts, help desk processes, and system
update processes.
3.1.4 Technical Requirements Planning
This work package is used to determine the requirements made on the necessary
hardware and to procure or ensure their availability of the first hardware systems
(computer systems, networks) and software systems (e.g., database management
system). SAP together with its partners have developed a software tool (Quick
Sizer, refer to Section 4.13.3; Quick Sizer is available over the SAPNet) that can
be used to determine the hardware requirements. This tool permits only a
preliminary estimate of the hardware requirements (processor power, main-storage
capacity, hard disk capacity). To make more accurate estimates, the requirements
for all levels of the CIS architecture, namely the presentation, application and
database level, and the network architecture must be taken into consideration. SAP
hardware partners can normally help here.
The first hardware components can be obtained and installed in the next step.
This includes initially the computer systems of the development system with the
corresponding peripherals such as backup systems. At this time, general
preplanning should have already been made for further expansions for the quality
assurance and the productive system.
The network connection to the SAP system should now be installed. This
requires either direct access using ISDN or over the Internet.
3.1.5 Quality Check Project Preparation Phase
Every phase of the roadmap completes at a milestone with a quality inspection to

ensure that the individual tasks have been performed and the results of a
subproject do not have unwanted effects on other project results. The customer
project manager officially closes a phase. He confirms with his signature that all
project results meet the requirements.
3.2 Phase 2: Business Blueprint
The goal of the second phase (refer to Figure 3.5) of the Implementation Roadmap
is to create the business blueprint. A business blueprint is understood to be a
design document that serves in the third phase (realization) as template for the
realization of the requirements of the company in the R/3 system. Thus, the
blueprint can be understood to be an abstract description of the future R/3 system.
When we discuss the business blueprint, we must distinguish between the creation
activity (task from phase 2) and the result as a document.
No
I
T•• k NlIN
PN .. 1: ProJKt PrePliratlon
I Ouralion
IS
17 20 23 2. 2. 0' .. 07 10 13 ,. ,.
Month 2
n 25 28 02
--,-- ~
---.-
PhIl •• 2: 0... 10." Blueprinl 15
T
I
---.-
2.
-
PfOt8d Management 8u&Ine5S Bauepnnl Ph&M
•
--..- .--
PIOfIICI Tllam Tra..w.g Bu5inHS Bluepmt Phue I
-
I
Develop Sy&lem EnvlronmIJnt 2'
-
--..-
" BusIne:55 Organization Structure 5.5
..,...
Bu&ineu Pn:lcKs OefDttlOO 18,5
- 13 Quality Check Bu!lnesa Bluep'*'1 Phase ,

- ,. PNae 3= FlNllzatJon 55
Figure 3.5: Work packages from phase 2

This phase is a mixture of classic tasks of analysis (what is to be realized?) and
design (how or with what is it to be realized?) known in the software development
and implementation. In the individual work packages, the requirements generally
determined in the first phase and the requirements specified in the project charter
are first refined, and then identified whether or not they are covered with the
standard functionalities of the R/3 system. In the latter case, further measures must
be initiated to realize customized solutions.
3.2.1 Business Blueprint Project Management
Because the foundation for the project management has already been laid in the
first phase, the handling of the day-to-day project business now assumes
importance. SAP recommends a number of measures, which depending on the
project size and requirements, should be used.
To ensure that the project completes on time, the project status must be
monitored regularly (weekly). The customer project manager holds status
meetings in which the current project status is presented and discussed. He
collects beforehand all status reports from the team members and uses the project
plans (starting with the Business Blueprint phase, also in the project IMG, refer to
Section 4.9.2) to monitor which tasks have been planned, started, processed, and
completed. The project progress is determined using this information and is
compared with the project plan. The results of this comparison can be evaluated
using the required times, the achieved results, and the consumed resources.
These status meetings raise a number of items that must be resolved or
reworked. The project manager is responsible for the allocation of the tasks to the
project members and, indeed, for the realization. Project tasks that run behind
schedule must be replanned and, when necessary, compensated by reorganizing
the project, such as the provision of additional resources or the shortening of other
steps in the project plan. All documents (project plan, project budget plan and
project resource plan) affected by the status reports and replanning of the project
must be brought to a current and consistent status, and distributed to the team
members.
The steering committee is informed monthly, if possible every two weeks
during the start phase, about the project progress. The project manager here
consolidates the status reports to the information of principal interest for the
steering committee and prepares summary reports. Any problems that could
increase the project cost or lengthen the project should be emphasized here. The
meeting should be prepared so that any necessary decisions can be made
immediately. All decisions are passed to the project team after the meeting and
agreed tasks provided for the realization.
Several workshops (system administration workshop, organization structure
workshop, business process workshop) must be organized and held. It must be
clarified beforehand which project members are to participate in which seminars.
Questionnaires should also be sent to the participants to help them prepare for the
workshops.
The project organization should be checked at the end of the phase when the
requirements made on the Rl3 system and the realization capabilities have become
more apparent. For example, it is possible that the business contact partners (e.g.,
the business process team management) have proved to have been wrongly chosen
or organizational changes no longer represent the optimum assignment to the
project team. The appropriate new assignments or reassignments in the project
team then should be aspired for. This represents a major challenge for the steering
committee or its project manager.
3.2 Phase 2: Business Blueprint 85
Change management
To prepare for the organizational changes in the company implicit with the Rl3
system, the change team develops the initial plans that should help with the
realization. This requires that the possible changes have been recorded and the
affected organizational units and positions determined. An initial strategy for the
change management (administration of changes that arise during the course of the
project progress) is then prepared, the details are determined and realized in the
next phases. Depending on the company culture, very different participation rights
- such as from the works councilor the personnel committee - must be taken into
consideration.
3.2.2 Training of the Business Blueprint Project Team
The members of the project team must have been given the appropriate training to
realize the business blueprint, namely the design of the business processes and the
company organization, most effectively and efficiently using the functionality
provided by the Rl3 system. The training plan for the team members prepared in
the first phase must be refined here. The additional application and technology-
related SAP seminars required for the project members must be determined and
booked when appropriate.
A debriefing should be held after attending the training courses and the
knowledge gained by the team members checked by the project manager. To
determine whether additional training is necessary, he should hold talks with
training course participants. If necessary, additional training courses must be
attended.
3.2.3 Develop System Environment
A number of design decisions must be made in parallel to the business-oriented

design of the Rl3 system. The system landscape further refined in the second
phase uses the results of the first phase. The functions and processes performed by
the company's organization units determine which functionalities must be
available and which special technical requirements made on the network, the
printers and PCs need to be satisfied. The interfaces still to be realized between
the Rl3 system and other DP systems (old systems) must also be determined.
Change requests
A formal procedure to process and execute change requests (refer to Section 4.9)
must now be defined for the complete project. Change requests affect the import
of new or changed objects that have been developed or changed at a client
(development client) and are to be passed to further clients (for example, quality
assurance client). Such objects can be settings for the customizing (customizing
data), added organization units or selected calculation procedures. To ensure the
quality of the accepted changes and that claimed for other systems, activities such
as
• the release of change requests,
• the import of the changes into the various systems (e.g., from the development
system into the quality assurance system (QAS»,
• the execution and checking of the quality inspections, and
• the import into additional clients or systems
must be regulated through providing clear responsibilities, normally from the

customer project manager.
Version Management
A similar procedure applies for the versioning as for the processing of changes.
The strategy prepared in the first phase must be refined by specifying,
• in which sequence the individual R/3 systems are promoted to a new system
version,
• which types of versions (functionality or correction releases, refer to Section
4.10) are to be used,
• when hot packages (collections) are to be imported, and
• which consequences the decisions to be made have on the availability of the
system.
In addition to the versioning of the application software, the versioning of the

presentation software (SAPGUI) is now considered. This is not actually one
system, but rather a number of systems and components that must be installed by
the user. In addition to the SAPGUI itself, graphic components (for the
development environment and the Business Navigator), special Office
components (word processing and spreadsheet systems) and interface systems to
these Office components are installed. The requirements of the various user
groups (clerks, field service employees, home worker on contract, employee of a
subsidiary, etc.) must be determined to specify what is to be installed on which
computer.
Because a new SAPGUI is supplied with every new version (functionality or
correction), the question arises, how (new) versions are to be installed on these
workplace computers. The simplest, but also the most involved method is the
installation from the CD-ROM the SAP supplies with these programs. Because
this method is no longer practicable in a company with several hundred PC
workplaces, there is also the possibility to copy the CD-ROM to a file server and,
for example, provide every employee with the capability to make the installation
from there. However, because this solution method is acceptable only for
technically-oriented employees, third-party providers offer solutions for the
automatic distribution (software distribution) of software packages (e.g., SAPGUI
and work processing systems) from a central server to multiple workplace
computers.
Development system (DEV)
The development environment is now prepared in the next step. The computers
(servers, PCs) may need to be installed and tested by the hardware supplier. The
required peripherals such as printers, additional servers, routers, etc. must be
connected with the network. The R/3 system (R3SETUP) then can be installed and
the clients for the development environment (refer to Section 3.1.2) set up. If error
corrections (hot packages) from SAP are already available for the installed
version, these can be obtained and installed from CD-ROM, ass or SAPNet
(refer to Section 4.13.4). A remote connection to SAP must be installed if ass is
to be used.
The workplace computers and the user master records for the project members
in the R/3 system are now set up. Because no security relevant master and
transaction data are yet held in the development and test clients, initially not much
attention needs to be paid to the exact assignment of authorizations. For this
reason, most users (project team members) are initially assigned the SAP_ALL
authorization profile. This permits them to use all functions of the system. In later
phases and, in particular, before using the productive system, detailed
authorization concepts (refer to Section 4.10) must be prepared and realized.
System administration
Because a first R/3 system has now been installed, it requires an orderly system
administration. The system administration tasks such as
• the creation of backup copies of the database,
• the monitoring of the users (access frequency, access problems, etc.),
• the planning of processes (in particular for running reports), and
• the analysis of the overall loading of the system (e.g., CPU loading of the
various servers, memory use)
must be assigned to the system administrators.

The specification and documentation of a backup strategy for the development
and productive system is one of the tasks to be performed. It must be ensured that
all members of the project team accept the backup strategy. They are responsible
for any resulting restrictions, such as down times for backups and recovery, and
the resulting loss of working time.
The Computing Center Management Systems (CCMS, refer to Section 4.14.2) is

available as tool for the monitoring and configuration.
Initialize implementation guide
The Implementation Guide (IMG) is part of the customizing tool (refer to Section
4.9). Because it is company-neutral, it must by copied into a tailored company
IMG and several project IMGs in accordance with the specific requirements of the
concrete implementation project.
The project scope previously defined in the EPA document has immediate
effect on the scope of the activities that need to be performed during the
customizing of the Rl3 system. Every business process passed to the project scope
uses a number of Rl3 transactions. Because most Rl3 transactions need to be
adapted to the company requirements during the customizing, the interrelationship
is immediately obvious: the business processes contained in the project scope can
be used to determine the company transactions and the customizing transactions
that need to be processed in order to configure the system in accordance with the
requirements.
The project scope determined in the Q&Adb (refer to Section 4.4) can be used
to create/generate project IMGs in the Rl3 system. However, because the project
scope is initially defined relatively general terms, reworking must be performed in
the Q&Adb and to the project IMGs.
3.2.4 Business Organization Structure
The settings made during the configuration of the Rl3 system can be differentiated
to take account of the structural and behavior-related aspects. Whereas the
structural settings made at the start relate to the structure of the company
organization (organizational structure), the behavior-related settings relate to the
business processes and the functions and procedures used for support.
The demand for the "best" company organization would be answered in the
ideal procedure starting at the goals (top-down, refer to Section 1.1.1) and could
be: which business processes should the company implement with which
organizational structure in order that the set goals can be achieved as good as
possible? However, despite the decision to implement Rl3, because every
company depends on specific inputs and general organizational conditions, these
should be matched as early as possible with the capabilities of the Rl3 system. The
Roadmap recommends that the basis business processes from the areas: external
accounting, sales logistics, procurement, logistics planning, financial and assets
management, the reporting system (controlling reports, logistics reports) be
included in a workshop, unless this has already been done in earlier phases of the
Rl3 implementation. Questionnaires are distributed to the participants to allow
them to prepare for the workshop. The questions can be taken from the Q&Adb
tool ("Questions about the business process", refer to Section 4.4), but obviously
can be extended with company-specific questions.
The following items are some things that should be taken into consideration for
the layout of an organizational structure:
• What is the commercial and tax structure of the company? An internationally
operating concern that consists of several companies must take account of the
applicable laws for the structuring and the disclosure duty (balance sheet,
profit and loss statement).
• Which process areas (procurement, production, sales, etc.) can be found in the
company?
• Which markets does the company serve, what products or product groups are
produced? Are mass products and/or made-to-order products offered?
• What is the management structure in the company? A differentiation is made
between vertically (markets and products) and horizontally (functional areas)
oriented structures. In the vertical orientation (divisionalization, division
organization), so-called quasi-companies (divisions) are often defined in the
companies. Their managers have relatively extensive decision-making
competencies for the development, production and sales functions, and for
which their own plans and short-term earnings statements for the period profit
are produced. There are different mixed forms between the vertical and the
horizontal organization.
• The information flow between the company's organization units is also critical
for the organizational structure. The assignment of logistical organization units
to those of the accounting determines the content of the information types
(balance sheets, profit statements, etc.). Thus, logistical information, such as
inventory levels, orders and proceeds, has an immediate effect on the balance
sheet, and the profit and loss statement. Consequently, with regard to the use
of the Rl3 system, the requirements made on the reporting system (reporting)
must be determined.
• The use of an application system distributed over several divisions and
locations must also take account of the technical restrictions for the form of the
organizational structure. For example, different availability times caused by
time zones must be taken into consideration in the same way as the cost of
communications that result from the distribution over several locations. From
the organizational viewpoint, the distribution affects the reporting system
(where are specific report lists produced?), and the input and management of
customizing and master data (where are data updated and then redistributed?).
The business processes and other requirements are then used in the workshops
to produce the best possible Rl3 organization structure for the company. This
requires that the company's requirements be compared with the restrictions of the
Rl3 system (refer to Section 1.4.8). This makes it critically important that
competent, experienced employees support the workshop.
The Structure Modeler (refer to Section 4.4.3) can be used to document the
company organization.
3.2.5 Business Process Definition
The requirements made on the business processes of the company are analyzed in
more detail in this work package. Again a number of workshops are held for the
involved project participants.
Initially, the scope of the business processes to be used in the Rl3
implementation are determined in more detail, and project employees (with
responsibility for business process) who can provide the required information
named for all scenarios and business processes (refer to Section 1.4.9). The project
scope is further refined and managed with the appropriate tool.
Standards to be observed during the configuration of the business processes and
their transactions are now defined. Special workshops are held in which the
various business process teams express their requirements. A differentiation is
made between generally applicable standards (refer to ISO and DIN) and
company-internal standards. It must be generally specified in which areas
(organization units, subcompanies) the standards should apply and what measures
are adopted to ensure their observance. Starting points for the standardization offer
• currencies, calendar, country-specific settings,
• number ranges (which number ranges should be used by which company
areas?),
• master data (which master data structures are used? Who updates these data
(central, decentral)?)
• units of measure (which units of measure are defined and used?)
• charts of accounts (which charts of accounts are used in which
(sub )companies ?),
• balance sheet and profit-and-Ioss structures (which account is to be assigned to
each item?)
• control of the data transfer (for example, how are master data exchanged for
distributed system architectures (refer to Section 1.4.1 )?).
Starting with the scenarios specified in the project scope, the company
requirements made on the business processes supported in future must be
investigated in more detail. Workshops are initiated in which the business process
teams specify and agree their requirements.
The questions in the Question-and-Answer database (Q&Adb, refer to Section
4.4) can be used for the preparation and as guide for these workshops. These
questions divide into process-specific questions (questions for the business
process) and general questions (blueprint form) that must be answered for every
process. The questions (including the blueprint form) can be answered directly in
the database. The R13 reference model (Business Navigator, refer to Section 4.7)
or equivalent modeling tools (refer to Section 4.8) can be used to illustrate
scenarios and the associated business processes. The R13 reference model
illustrates the scenarios and processes using the representation as EPC diagrams
(refer to Section 1.4.9).
Special requirements that require extended system functionalities, such as SAP
Business Workflow, ALE or Internet Application Components, must be
determined using the defined scenarios. These can include requirements from
distribution channels (Internet), inclusion of field service employees (Internet
Workflow) and the physical separation of the company (ALE). These
requirements can also be stored in the blueprint forms. The technical realization of
these special requirements normally takes place in later cycles or projects and then
not as part of the actual R13 implementation.
The requirements made on the reporting system (reporting) are also defined in
more detail during the business process definition. Special programs must written
to list and summarize the data that results from the information entered in the R13
system during the decision-making process within the business processes and to
monitor the business processes. These special ABAP programs are designated in
the R13 system as reports, and the results of running reports as listing. These can
be displayed directly using the SAPGUI, printed, sent as e-mail or exported in PC
file formats (e.g., for MS Excel).
The employees with responsibility for each business process now present the
previously used report forms and define the requirements for the new reports
required in the future. The requirements are compared using R13 system facilities.
The supplied standard reports and the screen masks are viewed here. If this
information provided as standard does not suffice - however, considering the wide
range of standard reports and masks, any "special wishes" should be questioned
critically - the required reports must be described by determining
• the tasks (what should be achieved with the report?)
• the associated information required (which data are required?),
• the estimated times and costs, and
• the recommended methodology for the development (which tools are used?)
Some business processes can be handled only by accessing data from other
application systems. To save the user from having to enter the data more than
once, it is normally desirable to develop interfaces between the application
systems and the R13 system. This requires determining the content of interfaces
(which data are to be transferred and what is their significance?) and alternative
realization functions such as coupling using BAPIs (refer to Section 4.11.3) or
mentioning the use of commercial interface systems.
If the R13 functionality does not suffice to realize all requirements, it must also
be discussed how any outstanding requirements are to be satisfied. In general, it is
possible to make use of supplementary products based on R13 or the customized
development with ABAP/4 (refer to Section 1.4.7) or BAPI technology. Similar to

the interface requirements, the associated business processes must also be
identified here, alternative solutions discussed, assessments made of costs and
time involved, and preliminary recommendations made.
Any additional developments (reports, interfaces, application systems) must be
requested in writing and approved by the appropriate instance (customer project
manager or steering committee). The ASAP CD-ROM contains the appropriate
forms to simplify producing the written requests.
Interfaces or the use of additional systems must be investigated in more detail
for any requirements that do not appear to be able to be met immediately using the
standard Rl3 functionality. The requirements for the business processes, reporting
system, interfaces, data conversion, extensions and authorization concepts must be
specified in detail, and suggestions made for alternative business process models.
These alternatives can be documented using EPC diagrams (refer to Section 1.2.2)
on the basis of existing Rl3 scenarios from the Rl3 reference model or by creating
new diagrams.
To provide an assessment of the benefits and disadvantages of the business
processes, it is necessary, that, to the greatest possible extent, they should run on
the Rl3 system (e.g., on configured training systems - such as the IDES system
from SAP (refer to Glossar) - or through prototype development).
Creation of the business blueprint document
A significant milestone of the second phase is the creation of the following

documents:
• EPA document to define the company process areas, scenarios and business
processes that characterize the overall extent of the project,
• organization structure with the assignment of the organization units of the
company to the Rl3 organization unit types,
• requirements made on the business processes, in particular the listing and
description of the requirements made on the business processes stored in the
Q&Adb,
• requirements for data transfers from old systems, customized program
extensions and interfaces as a listing of the requirements made on the
extensions stored as plain text in the Q&Adb.
The documents represent the quantitative (scope) and the qualitative result
contents from the business blueprint phase.
The selected business processes are also used here to determine the scope of the
so-called baseline configuration (baseline scope) in more detail. The baseline
scope covers the central requirements made on the business processes and
company structures that should be realized in an initial configuration step in the
Rl3 system. The company processes must be realized to the extent that the
consequences for the company can be recognized and their effects estimated. As
general rule-of-thumb, SAP recommends that 80 percent of the overall project
scope be accepted in the baseline scope. The remaining 20 percent will be realized
in subsequent stages (cycles). The BP Master List (refer to Section 4.4.4) can be
used to define and manage the baseline that is derived from the project scope
definition of the Q&Adb. The processes then can be assigned to the baseline (and
later the cycles) in the BP Master List.
As at the end of every phase, the steering committee must also check and
formally approve the business blueprint documents. The check takes place first at
the level of the employees from the project team with process or task
responsibility. The documents are distributed appropriately to the processes and
tasks. Particular attention should be paid to the checking of the interfaces between
the individual scenarios and business processes. These include the connections to
the central organization units (e.g., financial accounting, purchasing) and also to
the cross-application R/3 components (Workflow, Internet).
Together with the presentation of the technical and organizational decisions, the
presentation of the results before the steering committee should also be used to
mention any outstanding problems and reach the appropriate decisions. The
subsequent action, which is mainly derived from the business blueprint document,
should also be discussed.
Plan for user training and documentation
The creation of a training schedule is another task of this phase. This schedule
should ensure that the end-users are prepared for their new tasks beforehand and
that the appropriate user documentation is available. Depending on the type and
size of the company, different procedures are conceivable. Whereas small
companies usually attend seminars at SAP or in other training centers, large
companies organize alternative or supplementary seminars in-house themselves or
with third-parties. Depending on the starting point, the following tasks must be
performed to prepare for the seminars and the required user documentation
• analyze the project scope to determine the type, scope and number of seminars
required,
• define the training requirements, describe the goals, the business processes, the
target attendees and the type of the training,
• develop sample documents to serve as guidelines for the authors of the user
documentation,
• train the seminar managers so that they can also impart the necessary
knowledge,
• plan special preparation events (R/3 fundamentals) as lectures or as interactive
training units using CBT (Computer Based Training),
• prepare summary information to provide users with an overview of their tasks
in conjunction with inter-departmental business processes (scenarios),

• plan task and role-specific navigation instructions for the realization of
transactions (Business Process Procedure Document, workflow descriptions,
refer to Section 4.14.1), and
• determine training clients for the realization of seminars.
The appropriate assessment mechanisms (questionnaires, tests, system

monitoring) should be planned to obtain an overview of the seminar participants'
learning success.
3.2.6 Quality Check Business Blueprint Phase
All created documents are tested for completeness and consistency to check the
results of this phase. SAP provides the SAP Concept Check Tool (refer to Section
4.6) tool to support this activity. This tool checks those requirements and design
decisions that have an immediate effect on the R/3 system. These include, for
example, requirements made on the volume of transaction data to be processed
(projects, orders), technical decisions that affect the selected system landscape
(number of R/3 systems), and decisions regarding the use of specific
functionalities (project scope). Depending on the responses entered by the user,
the system indicates possible problem situations.
3.3 Phase 3: Realization
In the realization phase, the determined requirements and design decisions from
the business blueprint phase are realized as a company-specific R/3 system. Here
the system is configured as two work packages (baseline and final configuration)
and extended with specific functions (extensions, reports, interfaces). The system
is prepared for the productive operation after a final test. Figure 3.6 shows the
work packages from this phase.
3.3 Phase 3: Realization 95
...
7
Ta, kHame
PNse 2: Butlneu Bt .... ptlnt
I Our1tlon
2S
•• 2' 20c 06
Uonth3
13 20 27 03
Month"
'0 17 .. O.
MonthS
08 'S 22 29
---;.-- PNse 3 ; Re.. UutiOf't ., ~

....
I
---;s PrOtOd Man.agO",*,l RMIlU1JOn Phase 54
---;s Pro,ecs T'am TIimII19 ReaJiz.ttol Phit,&e ~
----,,-- Basetine ConIiguJillIOll and Conhm18bon .9 I

---;a Sys:Iem Management .8
---;a Anal Configuration and Confirmation 22
f--;o OeYelOp Conversion Progranw 38
r--;;- DeYeIOp APS*:&1IOtI b'l1ertac. PrOgrams '0
r--z. 0eYe1op Enhancemenll. 36
r--z. Cteate Reports. 39
r,;- Create La)'OU1 Sets 300
--.s E$I8b1aSt'1 AuthOfiZalJOn Concept 300
--.
E$I8b11sh Af(:h/Vftg MJn~gemenl 3Q
--v- I
.....,. F"",I 1I'IIIOrtltiOn T.II '3
.....,. End U.... DocumttUlIO(I and T~ MaUln&1 54
•
--..--
Quality Check RealiutlOD PI'I.\U
Pha •• 4: f inal Preparltion 35

I
Figure 3.6: Work packages from phase 3
3.3.1 Project Management Realization Phase
The tasks for the project management in the realization phase do not differ
fundamentally from the management of other phases. As before, a central
requirement is that the project management supports the communication between
the project teams and early recognizes, documents and finally rectifies any
problems. This makes regular working meetings unavoidable. Problems can be
documented using the Issues Database (refer to Section 4.4.3). The use of the
project IMGs in this phase also provides the capability to document directly in the
R/3 system all those settings made as part of the customizing and to use this
information for evaluations.
Planning for the help desk and the cut-over
To make the transition from the "old system" to the new R/3 system as friction-
free as possible, the planning and the procurement of the productive system must
have been completed, the creation of the help desks started and a plan for the cut-
over produced.
A help desk is an organization unit (department, group of employees) in the
company responsible for outstanding questions and problems associated with the
R/3 system. Within the help desk organization unit, the organization structure,
including roles and responsibilities must be clarified, and the help desk personnel
trained for their special tasks. Telephone lists and mail distribution list, and guides
for the use of the help desk by the Rl3 users must be produced and distributed to
the employees, and rules produced for the assigning priorities and the processing
of problems and questions.
The service to be provided by the help desk should be defined clearly. It must
be clarified here which services (answering of telephone and/or mail questions,
realization of smaller program extensions/reports) must be provided in which time
frame and which additional support capabilities (e.g., ass from SAP) should be
used. Large companies with so-called value contracts, namely contracts that
contain a license volume specified by SAP, can provide a help desk with increased
SAP support. These so-called Customer Competence Centers (CCC, refer to
Section 4.13.3) are help desks certified by SAP that act as a buffer between the
users of an Rl3 system and the support sites at SAP.
If, after the fifth phase (Go Live and Support), increased use is to be made of
SAP support, it is desirable to inform SAP early about the planned date of the
productive start to avoid possible lack of capacity.
A critical item for the change is that the data from the old system should be
transferred to be new Rl3 system as late as possible. Estimates must be made
beforehand for the time required for this data transfer. Measures must also be
adopted to ensure that those transactions from the old systems no longer required
are disabled so that no new data, such as orders and customer master data, can be
entered.
3.3.2 Project Team Training Realization Phase
Possible reorganizations of the project teams or changes to the project scope can
also change the training needs. For example, new employees added to the project
team may need to receive additional training or team members further trained to
obtain detailed knowledge of the Rl3 system.
3.3.3 Baseline Configuration and Confirmation
The realization of the requirements and design decisions is largely achieved

through the parameterization/configuration of the Rl3 system. Because the design
decisions (such as the assignment of the requirements to the components and the
organization structures of the Rl3 system) in the previous phases may not
necessarily be have been met down to the very last detail, the baseline scope is
refined in realization phase and the configuration performed using this as base.
The configuration is performed incrementally in several steps. The first and
second steps are designated as baseline and final configuration, respectively. The
final configuration itself consists of a number of smaller steps (maximum four so-
called cycles) that are performed successively. The requirements, design and
realization are compared with each other after every step, and any necessary
additions made in the business blueprint (result of phase 2).
The scope of the baseline configuration, which covers the company's main
goals, has already been defined in phase 2. It can be derived automatically from
the BP Master List (BPML) once the scenarios and processes to be processed have
been selected from the project scope. The baseline scope is now refined in this
work package and the first concrete configuration settings made.
The baseline configuration is performed in three steps, which must be planned
and realized appropriately. These steps are designated as configuration (in the
narrow sense), test and acceptance, and are documented in the associated plans
(configuration, test and acceptance plan). The initial settings (countries,
currencies, etc.) are made, the company structure (booking codes, plants, etc.)
entered, and the fundamental requirements made on the business processes
realized as part of the configuration (in the narrow sense). The customizing tool
from the Business Engineer (refer to Section 4.9) is used as tool.
The test is used to verify the settings actually made. These settings on the
quality assurance clients are transferred (refer to Section 4.9.3) and predefined test
cases (see below) run on the system.
In the third step, the project management accepts the results of the baseline
configuration. The completeness of the cases used as base are less important for
the acceptance, but rather their appropriateness for typical business processes of
the company.
The scope of the three steps is documented and monitored using the baseline
scope document and the plans (configuration plan, test plan and acceptance plan)
generated from it. To plan these steps, the baseline scope that covers the selected
business processes is extended with entries for the initial settings to be made and
the settings for the company structures. The separation between these settings was
made in phase 2. So-called cases must be specified that describe the contents of
the R/3 transactions to be configured, tested and accepted before starting the
generation. A case (configuration case, test case or acceptance scenario) is a
sequence of R/3 transactions (Business Process Procedures, BPP) that is defined
through the specification of a unique designation (for the case) and a number
suffixed to each transaction (for the position of the transaction in the case). The
planned realization dates and the employees with responsibility can also be
entered in the baseline document. The text template (case procedures) provided for
the detailed description of the cases permits the cases and the requirements made
on them to be documented comprehensively. Once the plans have been produced,
these, together with the descriptions of the case procedures, can be given to the
responsible employees, who can use them to log the results and actual dates.
Figure 3.7 provides another illustration of the association between the individual
documents used for the baseline configuration.
The project IMG should be adapted to the (possibly changed) structures before
performing the baseline configuration. This permits resource assignment made in
the configuration plan to be used to also add the appropriate employees to the
project administration of the R/3 customizing (refer to Section 4.9). The project
IMG can be invoked directly from the associated BPML documents during the
configuration. However, because the associated customizing transactions required
for the configuration of a business process must first be found in the project IMG,
the type of the assignment between the R/3 transactions (Business Process
Procedures, BPP) in the BPML and the project-IMG is relatively general. This
assignment can be refined by defining many smaller ASAP projects (refer to
Section 4.2) early in the project and then creating their own BPMLs and project
IMGs.
the
Reference to
in~iaJ settings
Reference to settings lor
entetprise structures
t Input of cases for conliguration.
lestlng and confirmation
Responslblli'r and planned dates

Requirements. comments '------~ for configuratIon and testing
Confirmation Plan Test Plan Configuration Plan
Actual Dates
Figure 3.7: Association between the BPML documents (baseline configuration)

IMG notes (refer to Section 4.9.2) are used during the actual configuration to
document all major changes to be made to the R/3 system.
3.3.4 Final Configuration and Confirmation
The system during the detailed configuration is then configured in two or more
cycles - the BMPL provides a maximum of four cycles. The configuration builds
on the results of the baseline configuration and extends or refines these. During
the detailed configuration, the cross-function aspects of the company assume
priority by considering and testing the processes and scenarios more closely
integrated in the association between the departments.
The individual steps within the cycles are comparable to those of the baseline
configuration. The configuration is also performed on the system in every cycle.
The results are then transported to the quality assurance clients and tested there.
Finally, the project management accepts every cycle.
To plan the cycles in detail, the baseline configuration is first tested for
completeness. All those configurations that have not yet been performed must now
be realized during the detailed configuration. Because it is possible that business
processes have also been included in the configuration, and thus in the project
scope, that were not originally envisaged, it may be desirable the update the
project scope in the Q&Adb and then regenerate the BPML.
In the BPML, the already configured processes must now be differentiated

from the processes still to be configured as part of the detailed configuration.
These are marked appropriately in the BPML. Although SAP provides a standard
assignment of processes to cycles, it is possible to deviate from this.
The configuration plans (refer to Figure 3.8) are produced after the assignment.
Because the scope of the individual cycles can change, the configuration plans
should be produced overlapped: the plan for the second cycle is produced only
during the configuration of the first cycle, etc. The configuration plans are
specified in more detail after being produced; this is done by determining the
planned end dates, and the employees needed for the configuration and the test.
More complex case procedures (sequences of interconnected transactions) should
be· produced in order that the R/3 system can be correctly configured and tested.
The associated authors, for example the persons responsible for the business
processes, who handle the case procedures should be named here.
The configuration plan can now be used to produce the work lists for the
configuration (in the narrow sense) and for the test. The configuration is executed
directly in the R/3 system, and all made settings must be adequately documented
as already done during the baseline-configuration.
The acceptance is prepared and executed once the configuration has been
completed. Acceptance scenarios are formed from the scenarios for the BPML and
from the test cases, and are checked and approved by the project manager and the
business process team leads.
Input of responsible persons

~o~~H~~~ test
Requirements, comments
Plal\ll8d dates for

configuration and
test
Work List Work List Work List

CONFIG TEST AUTHOR
Actual dates
Figure 3.8: Association of the BPML documents (final configuration)

3.3.5 System Administration
In the realization phase, the quality assurance system (QAS, refer to Section 3.1.2)
must be set up, and the productive system prepared and also set up. Because the
productive system should remain available throughout the complete working time
of the company and must handle the load of the activities (workload) for all users
and the parallel processes active in background, it must always satisfy more
requirements than the development and the quality assurance systems.
To guarantee the availability required for operations, plans must be developed,
which are followed when systems fail during running operations. In general, all
computers (presentation, application and database level) can be affected. CPU s,
hard disks, data backup devices (tape drives) and network cards can fail within the
computer systems. In addition, printers, network components (routers, switches),
printer, Internet, fax or EDI servers can fail. Depending on the effects on the day-
to-day business, short-term replacement and substitute components must be
provided for these components. Either in-house employees can install replacement
components or external service providers (hardware partners) can be contracted to
guarantee a replacement within specified time intervals.
To ensure an adequate performance of the complete system, throughput plans
for the final tests (refer to Phase 4: Final Preparation) should be prepared. These
can then be used to validate whether the installed R13 systems provide the
envisaged service. The critical transactions (e.g., create customer order) whose
execution, even at peak load (number of users working in parallel), is not allowed
to exceed a specific duration, should be determined. Similar plans should be
prepared for urgent and mass requests for printers and fax units.
The previously developed backup and recovery procedures should be checked.
In this case, saved data (copies of the database and the log files) are created and
reloaded to ensure that the selected procedures function in a critical situation. The
corresponding methodology depends on the hardware (including the operating
system) and the database management system.
A user's manual should be prepared for the routine operation of the productive
systems. It should contain the most important roles and responsibilities, and the
tasks assigned to these roles. These include
• the operational processes for the management of the productive system,
• the backup procedures,
• the tape management, and
• the procedures to start up and shut down the system.
The operation modes (refer to Section 4.14.2), the job planning and the alert
monitors to supervise the system are created for the system administration of the
productive system.
Once the system administration work package has been completed, the
productive system, the network environment, the printers and the workplace
computers are installed and configured, and software such as SAPGUI, MS Office
products, etc., installed, configured and tested. The complete configuration is

saved by making a backup of the operating system and database.
3.3.6 Development of Data Conversion Programs
Most implementation projects require stored data - irrespective whether these be

data from the financial accounting, the logistics or the production - to be
transferred from old systems into the R/3 system. Generally, two methods can be
used: the manual transfer by re-entering the data, and the automatic transfer using
automated data transfer from the old system to the R/3 system. The manual data
transfer is appropriate only when relatively small or poorly structured data
volumes (such as comment fields that have been "misused" to classify the data
records) are to be accepted by the new system. The conversion must take place
automatically for large data quantities. SAP provides standardized programs to
transfer the most import data records - the term Business Objects (refer to Section
1.4.1) is also used here - that permit the transfer of data records from sequential
text files.
Because, under some circumstances, some data records may depend on other
data records and so must be already present in the system before others records
can reference them (the principle of "referential integrity" known from database
theory, refer to Section 1.3.2). Some types of data records require that specific
sequences be maintained when they are imported (accounts, material master
records, bills-of-materials, etc.). For example, bills-of-materials can be imported
only when the referenced material master records have been imported beforehand.
To transfer the data, they must be read from the old system and written with the
appropriate R/3 format into a sequential text file. An SAP transfer program can be
used to read the data from the file and import them into R/3 system. If the
appropriate transfer programs (refer to Section 4.11.2) are not available, they must
be developed specifically. The transfer programs must be tested and transported to
the quality assurance system before being used.
3.3.7 Development of Application Interface Programs
Because the business information system is normally built using various business
application systems, interfaces must be provided to permit the efficient handling
of business processes over system limits. These should reduce so-called media
fragmentation, namely system-inherent discontinuities in the information flow.
Thus, it is not uncommon that one employee prints the information from one
application system, which he, or more often another employee, re-enters in
another application system. The aspects such as cost of the realization and the
updating effort, for example resulting from release changes, should be reduced for
these media fragmentations by providing connections (interface programs)
between the application systems.
The requirements made on the interfaces have already been determined and the
first designs for the interfaces produced in the earlier phases of the project. These
interfaces must now be realized in this phase. It must be considered which
interfaces (internal systems, interfaces to customers, suppliers) should be realized
using which technology (BAPI, OLE, etc., refer to Section 4.11.3) and which
employees should be given the task to realize the interfaces. The precise definition
of the interfaces requires determining the following,
• which data are to be transferred between the individual systems,
• which is the controlling system in two interconnected systems, and
• how general error situations can be corrected using restart procedures, namely
procedures that re-establish a consistent state throughout the system.
Depending on the systems to be coupled, the programming language to realize

the interfaces must be selected. Whereas on the Rl3 side, ABAP/4 (refer to
Section 1.4.7) has already been chosen, the language of the system to be
connected must be used on the other side. However, when standard interface
technologies, such as DCOM, OLE, CORBA (refer to Section 4.11.3), which the
Rl3 system also supports, are available, the language can be chosen freely.
That data do not need to be immediately available in the Rl3 system can also be
transferred periodically into the Rl3 system using batch interfaces. These types of
interfaces are based on the same technologies (e.g., batch input) that are also used
for the one-off data transfer (refer to Section 4.11.2) from old systems.
The interface programs must also be tested, approved and transported into the
quality assurance environment for the integration test.
3.3.8 Development of System Enhancements
If, despite an intensive "open" test, neither the Rl3 system nor other software
products provide the required functionality to perform the necessary business
process tasks, such functions must be specially developed. The "proof' of the
necessity should always be provided, i.e., demanded from the company
management. The program development can be given in contract or realized by
the company in-house. The required extensions can be developed with ABAP/4 in
the Rl3 system or externally using other programming languages and the Rl3
interface technologies. Because predefined user exits are provided in the Rl3
components that often simplify the extension, the development using ABAP/4 has
the advantage of simpler integration. The functionality of ABAP/4 Development
Workbench (refer to Section 1.4.7) supplied with the Rl3 system is available for
customized development. However, if existing programs are modified, care should
be taken to ensure no incompatibilities occur between the standard Rl3 programs
and the programs changed and added at a release change.
As with the interface development, some basic questions must be answered
during the design and the realization:
• which business processes are to be supported?

• which functionalities are required here?
• which data are required, which are created?
• can existing interfaces (user exits, BAPIs) be used?
• how and from whom are the system extensions maintained (for example, for
changes to the interfaces)?
Once the extensions have been realized, they are tested in the same manner as
the data transfer procedures and interface programs, accepted and transported to
the quality assurance system.
3.3.9 Create Reports
There is the danger in implementation projects that only the important

requirements of the pure data acquisition and processing (On-Line Transactional
Processing, OLTP), but not the requirements of the data analysis (On-Line
Analytical Processing, OLAP), are considered in adequate detail. In the best case,
the known report forms from the old systems are recorded as part of the actual
analysis, however, the new potentials, such as interactive reporting, real-time
processing and integration of the R/3 system are not used, for example, to cover
more advanced requirements.
When the reports are designed, the standard reports (refer to Section 4.12.1)
supplied by SAP with the R/3 system - several thousand in the meantime! -should
be investigated. These can significantly shorten the development time and so
produce, in particular, major mid-term and long-term savings.
SAP recommends that the following steps be observed during the development
or the selection of report programs (Simplification Group 1998a).
I. Determine the requirements of the business processes made on the reporting
system.
2. Assign the requirements to the application components.
3. Search for suitable standard reports within these components.
4. If suitable reports are available, the search has ended.
5. If no suitable report is available, comparable reports should be determined as
the starting point for customized developments.
6. Select a development tool for the customized development (refer to Section
4.12).
7. Develop any missing reports (possibly on the basis of similar standard reports).
Because complex database queries can load the system very heavily and thus
disturb the running operations, the development of the reports should pay
particular importance to the performance of the programs and thus the associated
effects on the complete system. For this reason, the report queries should be as
detailed and exact as possible. A test should also be made whether reports must be
processed online or instead executed in an "overnight" batch run.
Once the development has completed, the reports, as with all customized
developments (interfaces, system extensions, additional developments), must be
tested and transferred to the quality assurance system.
3.3.10 Create Forms
Some business processes require that special forms be filled with data from the
Rl3 system. These include, for example, invoices, credit notes and checks. The
Rl3 system provides the SAPscript tool to create forms and also for general word
processing.
In addition to the Rl3 documentation, the Printout Design Made Easy-
Guidebook, contained on the ASAP CD-ROM and also obtainable from the
Internet (refer to SAPNet, Section 4.13.4), can be used as guide for creating forms.
3.3.11 Establish the Authorization Concept
Once the responsibilities for the processes and functions have been determined in
the previous business blueprint phase, these must be broken down in phase 3 to
the level of the transactions and programs (activities). The workplace matrices
produced in conjunction with the user departments list vertically the
functionalities required by the department and define horizontally the roles found
within a department. Because the transactions can be grouped into functional or
business-process-oriented characteristics, it is obvious to use either the component
hierarchy or the process hierarchy as sort criterion in the workplace matrix.
The menu path must also be determined for every activity with which a user
can invoke it. This information is required for the profile generator (refer to
Section 4.10.3).
Because not all employees/roles have responsibility for all case procedures of a
task area, the third dimension in the matrices comes from the limitation of the
company's organization structures (organizational limitation in Figure 3.9). For
example, marketing departments can be divided into distribution channels or
purchasing organizations responsible only for specific booking codes. For these
reasons, the organization units must be included in the consideration of the
authorization concepts.
'\
Roles
Rl R2 R3 R4
Orgamzing CmpCd 1 CmpCd 1 CmpCd2 CmpCd 2

Defini1 ion PI""11 Plan12 Planl t Plant 2
T1
II)
c:-
.2 T2
t)
lJl -
c: T3
~-
T4 .
"-
Access Access to
to ali 1- '-- specific
data records data records
Figure 3.9: Workplace matrix
The creation and realization of the authorization concept must take place in
close cooperation between the system administrators and the responsible persons
from the departments / business processes (members of the business process
teams, refer to Section 3.1.1). This ensures that employees are not given too many
authorizations - which would endanger the security - or too few - which would
disturb the day-to-day work. The authorization concept must also take account of
the need to access R/3 system services (printer, SAPoffice, fax).
SAP recommends that when the profile generator is used, the authorization
admini stration should be adopted by three administrators (also refer to the roles in
Section 3.1.1) with different roles:
• the user administrator who sets up users, assigns groups of transactions
(activity groups) to the users and profiles generated by the profile generator,
• the administrator of the authorization data who sets up activity groups and
changes the authorization data and updates the assignments of the transactions,
and
• the administrator of the authorization profiles who defines authorizations and
authorization profiles based on activity groups.
The administrators perform only the activities of their roles. SAP Rl3
Authorization Made Easy Guidebook (Simplification Group 1998c) provides a
good overview of these problems.
3.3.12 Establish Archiving Management
Large data volumes affect the capabilities of the database and thus the complete
system. Because continuous transactions with business partners bring new data
into the database of the Rl3 system, stored data that are either no longer required
or required only partially should be archived periodically (e.g., monthly, yearly).
Unfortunately, technical and business requirements often conflict with each
other. Whereas from the technical viewpoint, the volume of data stored in the
database should be kept relatively small, the business viewpoint may require data
be retained as long as possible in the system, for example
• to perform trend analyses on sales, purchasing and production figures,
• to provide internal audits with proof of the correct handling of business
processes, and
• to conform to the external requirements resulting from commercial and tax
law.
Consequently, the archiving procedures must be considered in close

cooperation between the technical teams and the individual business process
teams. The use of SAP Remote Archiving Services (refer to Section 4.13.1) is one
way of realizing these services.
3.3.13 Final Integration Test
The final integration test has the goal to check the functional requirements of the
Rl3 system, and is used for the simulation of the productive operation on the
quality assurance system. Non-functional requirements are checked during the
performance test and with the user test in the fourth phase. Hot packages, test data,
programs, authorization objects, documentation and other customizing settings are
transferred to the quality assurance system for the test.
When typical business processes are run, the primary test is whether the
processes described and represented in the application system actually match and
correlate with the processes occurring in the company. In addition to the
functionality of the Rl3 system, the interfaces, program extensions, reports and
output functions (printer, fax, EDI) are also tested.
Special attention should be paid during the previously required planning of the
tests to the inter-department character, and thus inter-module character, of the Rl3
system. Consequently, the tests should not concentrate on the individual functions
such as for the baseline and detailed configuration, but on the interactions of all
departments (end-to-end scenarios) and thus on the transactions of the associated
business processes. Although the test cases from earlier phases can be used here as
the basis for the integration tests, it is important that the basic test data take
account of the integrating aspect. For this reason, common data or data that build
on themselves should be used throughout the business processes to be tested.
The business processes chosen for the test cases should be those with the
largest share of the day-to-day business. However, additional business processes
that have particularly critical interactions, such as between the R13 system and the
application systems of other companies (ALE or EDIFACT), must also be tested.
Whereas the project team still had the leadership during the tests of the first
cycles of the detailed configuration (refer to Section 3.3.4), the accountability now
increasingly passes to the true actors of the business processes, namely to the
future users of the R13 system.
The BPML (refer to Section 4.4.4) can again be used for the documentation of
the plan for the integration test. Two integration phases (or cycles) II and 12 are
predefined here; the critical scenarios and the end-to-end scenarios are entered in
II in 12, respectively.
The integration tests should take place under conditions as realistic possible.
Thus, for example, subsequent users from all (even distant) locations should also
be involved in the test. All problems and questions that arise during the test are
recorded in test logs and in the Issues Database. Once any errors have been
corrected and the integration test has been repeated, the person responsible for the
process accepts it, and the company management releases the system.
3.3.14 End User Documentation and Training Material
The training courses held during the production preparation phase prepare the
users for their future work with the R13 system. They can also be provided with
so-called end-user procedure documentation that guides them through their day-
to-day work. As preparation, the general training plans from the second phase
should be refined in this phase. Specifically, it must be specified,
• which users are to be trained,
• who is to produce the documentation (work procedures, training materials),
and
• who (e.g., power users), where and how are to do the training.
To help create the user documentation, the supplied ASAP CD-ROM contains
the Business Process Procedure Documents (refer to Section 4.14.1) that provides
models for many of the R13 transactions. They were selected in the third phase or,
if not already available, created specifically. Business Process Procedure
Documents are structured descriptions of R13 transactions and can be modified to
produce detailed end-user procedure documentation (EUPD). In this case,
additional company or user-group-specific information is added to these
documents.
The training program requires both materials for SAP implementation courses
and also for the business-oriented courses. If necessary, the courses must also be
adapted to the various user groups (occasional users, processing clerks, power
users). The EUPDs can serve as basis for the training documentation. In this case,
they are formed into groups appropriate for the associated course content. The
course content should be oriented to the typical business processes of the
company. SAP also provides a number of services (refer to Section 4.13 .1) that
simplify the producing of courses.
3.3.15 Quality Check Realization Phase
As at the completion of every phase, a test is also made in the realization phase
whether the required results have been achieved and the planned deadlines
(milestones) attained. To the extent possible, the results are tested for correctness
and completeness, and accepted by the project management.
3.4 Phase 4: Final Preparation
The fourth Phase (refer to Figure 3.10) is used to prepare the company and the Rl3
system (productive system) for the productive (running) operation. The last non-
functional tests, the user training, the system management, and the change from
the old systems to the Rl3 system (cut-over) must be performed.
"- T.:IIk tt.m.

..
I""'..... 07 '0
......
" " •• 22 ,. ,. 1 03 ... 09 ......"... '. " 2' l1 03
"
r--;.-
Ph... 3: RealIzation
~
,."
FINN 4: AI'III p,.~.tlon
r--,,-- I
T
F'T0fICt~1 FNI PreparallOfllPI\aM
-"""-
f--;;- Efldl&!trTrall'llftg ,.
f--;;-
r--;;-- DrHaiIddPro,lCt~
,."
f-;;- 0.00"" 7
r-;;-
I-;;-
~tyCl.:i:F""P~rafa)n~,.
PbaM5: 00 Uvto lInCI$uppoof1

2
., ~I! ...
Figure 3.10: Work packages for phase 4
3.4.1 Project Management Final Preparation
The project management tasks do not formally differ from those of the earlier
phases (refer to Section 3.2.1). Status and steering committee meetings are still
held.
3.4.2 End User Training
Now that the training of the users has been adequately prepared in phase 3, it
remains to hold the courses. This requires that the necessary resources such as
3.4 Phase 4: Final Preparation 109
seminar rooms, documentation, hardware and other equipment be made available,

user master records created in the training clients, and the required test data
copied.
The training results should be checked once the training has been completed.
For example, the participants can be tested using confidential questionnaires. On
the other hand, the training manager and the training team have an interest in
obtaining feedback and suggestions for improvement for subsequent training
courses from the participants. They can then analyze these and possibly
incorporate them in the training plan.
3.4.3 System Management
Whereas the previous phase primarily realized the functional requirements made
on the R/3 system, we now need to ensure that the required availability and
performance for the productive operation are provided. This requires that at least
the Computing Center Management System (CCMS, refer to Section 4.14.2) is set
up in the productive system. This system makes it possible to customize the R/3
system using time parameters to meet the requirements for the day and night
processing and during parallel operations to distribute the resulting workload to
the available R/3 instances.
Other settings that must be made using CCMS affect the following areas:
• The planning for the background processing of jobs that must be run at regular
intervals to reorganize the R/3 system. Because the file and table entries
produced during the running of the R/3 system occupy increasing amounts of
disk space, but most of which is no longer needed, the appropriate jobs should
be run to delete these unwanted entries. These include logs for the batch input
procedure or memory dumps produced as the result of system failures. Most
background jobs must be run once-daily, normally at night.
• System monitoring programs that permit the system administrators to monitor
the state of R/3 instances, the database management system and the network.
• The backup calendar that permits the planning and control of the regular
backups of the database management system.
The infrastructure for printing must be realized m accordance with the

requirements. Strategies must be specified here such as
• initiate and execute mass-printing requests,
• permit employees to use alternative printers under the control of system
parameters,
• replacement printer supplied in the shortest-possible time from the hardware
supplier's service department or the DP department, and
• protect confidential print requests against unauthorized access, e.g., using a
printer with restricted access.
Once the personnel have been trained internally for the system administration -
this is necessary only when the future administrators are not identical with the
previously trained members of the technical teams - various tests are performed in
accordance with the plan drawn up in the second phase:
• tests to check the throughput (data quantities per time unit) for the most
important transactions of the Rl3 business processes,
• system administration tests to check the most important system administration
tasks (job planning, correction system and transport system, system
monitoring, spool administration, etc.),
• disaster recovery tests to prove the strategies for a total failure of computers
and computer components, in particular in conjunction with the hardware
partners,
• tests of the backup and restore procedures to check the saving and restoring of
data (databases, log files) and
• print and fax test to check the associated hardware infrastructure.
SAP recommends that you make use of its offered GoingLive Customer Care
Service (refer to Section 4.13.3) when you have completed this work package.
3.4.4 Detailed Planning for Cut-Over and Support
This work package consists of two tasks. As part of the planning for the cut-over,
namely for the change from the old system to the Rl3 system, a final test must
now be made whether the productive system is ready for use. This includes
checking the realization of the data transfer programs, the estimate of the time
needed for the data transfer, and the development of an exact plan that specifies
when, which data, programs, customizing data, etc., are to be passed to the
productive system. Once the test has completed successfully that the cut-over can
be performed, the required approvals are obtained from the project and company
management.
The second task has the aim of making available a help desk to provide the
required support for the users when the system goes live. The procedure to be
adopted by the users in the case of problems must be clarified here, namely, how
they can find the correct contact partner and which medium is to be used to
address queries to the help desk. Finally, the precise task areas must be specified
internally for the help desk.
The concrete form of a help desk is highly dependent on the size and the
requirements of the company. Whereas smaller companies may well dispense with
the need for their own 'help desk and instead make use of the external services of
3.4 Phase 4: Final Preparation III
an R/3 data center operator or SAP itself, larger companies maintain their own
personnel who are exclusively available to support the users.
3.4.5 Cut-Over
The change to the productive system is performed in this work package. The
results of the other work packages of this phase merge here.
The customizing settings and R/3 repository objects (refer to Section 1.4.7)
previously tested in the quality assurance system are passed to the productive
system. The required master data and transaction data are then taken from the old
systems, from prepared files or entered manually.
The final acceptance decides whether the R/3 system can be used for the
productive operation (Phase 5: Go Live and Support) or whether additional
corrective work is still necessary. A backup copy of the productive system is
made. The passed data and settings, and important business processes and
interfaces to external systems are tested. Any changes made directly in the
productive system must be documented. If necessary, the complete productive
system must be saved again.
3.4.6 Quality Check Final Preparation Phase
As at the completion of every phase, a test is also made in the production

preparation phase whether the required results are achieved and the planned
deadlines (milestones) have been attained. To the extent possible, the results are
tested for correctness and completeness, and accepted by the project management.
3.5 Phase 5: Go Live and Support
In the fifth and last phase (refer to Figure 3.11) of the R/3 implementation, the
project team accompanies the productive operation until an adequate stability of
the R/3 system has been achieved.
I ,. .. ,. .. .. "
-
"'0I'I~7
,.
No T_1lI HelM DutaUOrl
" 21 27 >J
'" 'S-
" " " >0 0>
"
_....
"
.,"
Ph... 4: FlNlI P~f.tbl
-,,- "1
,..... PtIeN 5: 00 u.,. .N:II $109POf1
PI'OducIJOn Suppon 20
--;;- 3
Figure 3.11: Work packages of phase 5

Production support
The tasks during the first weeks of the productive operation concentrate on the
support for the user, checking of the results of the transactions performed with the
system, and the optimization of the data throughput.
The support for the users orients on the plans for the production support
produced in the fourth phase. If this plan envisages wide use of the OSS (either
internally as help desk system and/or over remote connection to SAP), the most
important users must be trained in the use of this system. The effectiveness of the
help desk should be continuously checked during the initial stages of the
productive operation to ensure that quick and competent help is provided.
The transactions performed for master and transaction data are checked using
the test plans created in phase 4. The throughput is tested in increasingly larger
time intervals - initially daily, later after the associated month, quarterly and
yearly accounts. The actual quantities of the entered or processed business objects
are tested using the previously listed targeted goals. Any differences can indicate
limited acceptance or problems the users have with the R/3 system.
If problems are recognized in the productive operation, any necessary program
and customizing changes are performed first in the development system, tested in
the quality assurance system, and only then passed to the productive system. The
R/3 GoingLive Customer Care Service (refer to Section 4.13.3) provided free of
charge from SAP for every productive start can be used here as additional support
in this early phase of the productive operation.
At the end of this work package, the project management prepares for the
acceptance of the productive environment by the steering committee or the
company management.
End project
The project should be officially ended at the completion of the implementation

project. The project team is relieved of its responsibility when all outstanding
problems have been cleared up or they have passed from the project team task area
to the task area of another organization units (help desk, DP department, user
department), and so the ability to trace them has been assured.
To the extent possible at this time, the business and project goals specified in
the phase are compared with the achieved results to provide a critical assessment
of the complete project.
4 Tools
This chapter presents current software tools used during the implementation of
R13 , sometimes also in combination with other business application systems.
4.1 Tools in the R/3 Implementation Environment
The following sections of this chapter describe the tools used during the R13
implementation. The summary in Table 4.1 shows them with a brief description
initially assigned to the phases of the Implementation Roadmap (refer to Chapter
3) in which they are principally used.
Although most tools are part of the ASAP CD-ROM or are supplied with the
R13 system, some tools must be ordered separately (often free of change) from
SAP.
Table 4.1: Rl3 implementation tools
Tool! Phase Supported tasks Source

Services
Implementation 1-5 Documentation of the Roadmaps and ASAP CD-ROM
As. islam the means of calling the tools and
(refer to 4.2) accelerators
MS Project 1-5 Project planning and tracking Project plans are present
(refer to 4.3) on the ASAP CD-ROM ;
MS Project i also
required
Q&Adb 1-5 • Analy i and documentation of ASAP CD-ROM
(refer to 4.4) the requiremenls made on Rl3
• Documentation of the
a signment of the Rl3 function .
for the company's requirements
• Problem managemcnt (manage
open questions, etc.)
StrucLUre Modcler 2 Create graphical Rl3-conform process The ASAP CD- ROM
(refer to 4.5 ) stn.lctures u ing predefined con tain a template;
organizational unit types (in Vi io Visio 5.0 is a lso
template) required
Concept Check Tool 1.2 Quality in pection of the project ASAP CD-ROM
(refer to 4.6) preparation. of the technical
infrastructure and the configuration
settings

114 4 Tools
Table 4.2: Rl3 implementation tools (continued)

Busine s Navigator 1, 2, 3 Visualization and navigation of the R/3 RJ3
(refer to 4.7) rcfercnce model
Tool for the 2 Documentation of the bu ine . Products from SAP
busi ness proce processe . panners
modeling adaptation of the RJ3 refcrencc model
(refer to 4.8)
Customi7jng 3 Configuration of the RJ3 sy tem RJ3 (customizing
(refer to 4.9) components)
Authorization y tem 3 Definition and a signment of the RI3
(refer to 4.10) authorizations for the usage of the RJ
system
Application ystcm 2, 3 Anal ysis and assessmenl of the variou Special CD-ROM (can
interface possibili tie for the coupling rthe R/3 be obtained free of
([nlerface Advi er) sy (em with external systems harge from SAP)
(refer to 4. I I)
RepOit creation 2-3 Selection f tandard repons, RJ3
(ABAP/4 Query) creation of repons
(refer to 4.12)
SAP ervice 1-5 Variou s SAP service On request from SAP
(refer to 4.13)
4.2 Implementation Assistant
The Implementation Assistant is a hypertext system based on MS Windows that

permits the navigation in many linked documents and the invocation of the tools
needed for the implementation of the R/3 system.
The central navigation structure (Figure 4.1) is organized hierarchically using
folders. These folders contain documents that the Implementation Assistant can
open, read and print. As usual, it is possible to "jump" in the documents (navigate)
to other documents. From some documents it is possible to open other tools (e.g.,
MS Word, MS Project). It is also possible to include in the structure documents
that result from a concrete implementation project.
4.2 Implementation Assistant 115
Ii? AcceleratedSAP Implementation Assistant I!I~ Et
~ ~ ~ ~.
Hide Back Forward Refresh Print Options
----,-.."..,..,,...
[!] What's New

Implementation Roadmap
13 Phase 1: Project Preparation
.£l U Initial Proj ect Planning
[±] Project Procedures
fi:l LJ P roject Kickoff
[±] Tec hnical Requi rement s P a
l nning
l!!u Quality Check Project Preparation Phase
ill Phase 2. Business Blueprint
[±]. Phase 3 : Realization
r±l L.J Phase 4: Final Preparation
r±l Phase 5: Go Live and Support
[!] Implementation Accelerators
ill L.J Continuous Change Roa dmap
e Continuous Change Accelerat ors
I±l w Upgrade Roadmap
2 Upgrade Accele rators
ill Business Information Warehouse Roadmap
® fJ\N Acce lerators
& Project Plan
~ Question and Answer Database

[!J Open Issues Database
!!J Business Process Procedures
i Knowledge Corner
[!] Glossary
[!] Help
Figure 4.1: Central navigation structure of the Implementation Assistant

The highest level of the folder hierarchy permits entry capabilities
• to the text descriptions of the roadmaps (Implementation Roadmap,
Continuous Optimization, Upgrade Roadmap, refer to Chapter 3),
• to the "accelerators" (refer to Section 4.14.1) of the associated roadmaps,
• to (predefined) project plans (refer to Section 4.3),
• to the Q&Adb and the Issues Database (refer to Section 4.4),
• to the Business Process Procedure Documents (refer to Section 4.14.1),
• etc.
116 4 Tools
The user during the installation of the Implementation Assistant can choose
between a local and a central installation. The installation on a central file server
permits the parallel and distributed access from several project participants to the
tools and documents of the Implementation Assistant. This is of particular
advantage when the documents produced during the project, such as concrete
project plans for project participants, are to be available using the Implementation
Assistant.
The ASAP CD-ROM setup program during the installation also creates the
structures and documents for the first implementation project, which then can be
managed by the Implementation Assistant. As explained in Section 3.3.3, it may
be desirable for an Rl3 implementation project to define several ASAP projects,
for example, when you wish to implement the Rl3 system in several stages or
parallel at several locations in independent projects. The setup program can be
used here to define additional projects. A disadvantage of this approach is that the
projects are managed completely independent of each other. Documents such as
descriptions of inter-project standards may need to be introduced in every project
system. In addition, only one project per PC workplace can be open at anyone
time. This hinders working over project boundaries.
4.3 MS Project
The Implementation Assistant contains various templates for project plans, which,
depending on the ASAP version and estimated realization time (six to nine
months), can be used to manage an implementation project. These templates are
supplied as MS Project files. This section now briefly describes the MS Project
project management system concerning its use in an Rl3 implementation project.
4.3.1 Basic Principles
A project plan represents in a chronological and logical sequence the tasks to be

performed during a project. MS Project defines these tasks as so-called activities.
Activities can be assigned in a hierarchy. Thus, an activity - a so-called group
activity - consists of a number of lower-level activities, which are either further
group activities or just simple activities. Simple activities are elementary and
cannot be further subdivided.
For such an activity
• activities can be defined that specify which other activities must be closed
before the new activity can be started,
• the estimated duration can be specified for the expected time range required to
perform an activity, and
4.3 MS Project 117
• the resources can be specified, which, for example, the represent the
employees required to perform the activity or are needed for the activity to be
performed.
The duration of a group activity does not need to be specified explicitly. It is

calculated automatically from the base dates of their lower level activities by
taking the difference from the end date of the latest activity and start date of the
earliest activity.
Many aspects can affect the availability of an employee. The available working
hours per day is always entered by creating a calendar with the daily working
hours and the absent days. Deviations for individual employees for a predefined
calendar can be entering as additional work-free days or changed available
working hours per working day. The availability of an employee can also be
restricted to a fixed time interval and the proportion of the working hours defined
for the project. Part of this proportion can be taken for every assignment of an
employee to an activity. If a resource represents several employees, the proportion
can be set to a multiple of 100 percent. The system can use these figures to check
whether resources are overloaded, namely the work needed to be done on specific
days exceeds the available working hours.
4.3.2 Project Plans for the R/3 Implementation
The ASAP CD-ROM contains several predefined project plans for MS Project that
can be used during an implementation for the project management. They differ
depending on the ASAP version (3.1 and 4.0) and the predefined total project time
(six and nine months). The figures show extracts from the project plans at the start
of the five phases of the Implementation Roadmap (refer to Chapter 3).
The basic concept of the project plan lies in the representation of the tasks of
the Implementation Roadmap as activities in MS Project. The hierarchical
structure of the roadmap (refer to Section 2.3.1), which consists of phases, work
packages, activities and the elementary tasks, is represented directly. The first
three levels are represented here as group activities and the tasks as simple
activities. The activities are brought into a logical sequence that results from the
dependency of the activities from the results of other activities. Durations and
resources have been assigned to all simple activities.
The employee roles of the project (refer to Section 3.1.1) have been assigned to
the activities project resources. In accordance with the default settings selected by
SAP, every resource is assigned as being available 100 percent of its working
hours; similarly and every activity is also assigned 100 percent availability.
118 4 Tools
4.3.3 Adaptation of a Project Plan
The default settings supplied by SAP in the project plans must be adapted to meet
the requirements of a project. If MS Project is to be used, the following steps
should be performed:
1. Set the start date: The planned start date for the project should be set first. All
activities are planned starting at this date (forwards scheduling).
2. Customize the company calendar: The company calendar contains the basic
working hours of the company. These include the daily working hours without
Sundays and public holidays. Deviations can be made to this company
calendar by assigning specific calendars to individual resources.
3. Definition of the resources: As mentioned previously, SAP has represented the
employee roles as resources in the project plans. Because some roles are
assigned more than once - there exist almost certainly several business process
teams and thus several team leaders and members; similarly, one employee can
adopt several roles. Consequently the resource definitions must be adapted.
Resources used by several persons must either by defined more than once (see
below) or as so-called group resources increased in accordance with the
capacity actually required (so-called "available maximum units"). If an
employee adopts several roles, his or her capacity must be distributed amongst
the resources. In addition, the names or at least the abbreviations for the
resources should be adapted to the names of the project participants.
4. Update the capacities and activity duration: In accordance with the specific
general project conditions, estimate the available capacities - mainly the
employee resources - and the planned duration for the activities and enter
these in MS Project. Although SAP recommends that its six or nine month
time plans be retained, some tasks, such as system extensions or interface
developments, depending on the project involved, may require more time than
was estimated by SAP.
5. Monitoring of the project: To monitor the project, a so-called base plan should
be produced shortly before the start of the project. A special monitoring view
makes it possible to compare the current situation of the project with this
original plan. Obviously to use this, it is important that the current status of the
project is represented in the system. For this reason, the results from the
preparation for the project meeting (refer to Section 3.1.2) should also be
documented in the project plan and prepared for the meeting. MS Project
provides several reports, e.g., for activity status and resource loading.
Note, when resources are defined (3rd step), because some activities must be
performed independent of each other in several business process teams, it can be
desirable to copy such activities. This can achieve a more exact planning for the
individual teams. The resources should also be duplicated after the activities have
been duplicated. Another, more elegant, method involves creating and managing
4.3 MS Project 119
several project plans (also refer to Section 3.3.3) that can be added to a central
project plan under MS Project. For example, a dedicated file with its own
activities and resources can be created for each business process team. All files for
the project plans are added to a central file where they can be planned and
monitored.
4.4 Question & Answer Database
The Question & Answer Database (Q&Adb) is used to record and manage the
requirements of the company implementing Rl3, and also for the recording,
management and forwarding of design decisions. The Q&Adb is a database-
supported question catalog supplied with a number of predefined questions.
Individual questions or even groups of questions can be selected and answered
from this catalog. You can also extend it with your own questions. As with the Rl3
system itself, a basic differentiation must be made in the Q&Adb between the
definition-time (refer to Section 2.1.3), in which you select and questions and add
new ones, and the run-time, in which the questions are answered. The questions
are classified in accordance with the known process hierarchy of the R/3 system.
The Q&Adb tool can be generally subdivided into three areas (also refer to
Figure 4.2): "General Questions for the Enterprise" (Section 4.4.1), "Process
Hierarchy" (Section 4.4.2) and "Issues database" (Section 4.4.3). Whereas Section
4.4.4 covers the Business Process Master List and the documents that can be
produced from it, Section 4.4.5 provides a final short outlook.
120 4 Tools
Figure 4.2: Structure of the questions in the Q&Adb
4.4.1 Overview Questions for the Enterprise
The overview questions area is used to manage questions and answers for the
actual state and for the future requirements of the enterprise. Thus, these questions
are answered during the analysis and apply to technical ("questions concerning the
basis") and organizational aspects ("questions concerning the company") of the
enterprise.
The technical aspects include questions for
• the existing application and computer systems in the current enterprise,
• the number of end-users,
• the number and type of the locations that work with the application system,
• the type and size of the computer networks, and
• the type and number of the workplace computers (pes, terminals).
The organizational aspects include questions relating

4.4 Question & Answer Database 121
• any expansion plans of the enterprise,

• any (de-)centralization plans,
• the main requirements made on the components to be used in future,
• the customer structure,
• the products / product groups and services, and
• the structure of the enterprise/concem with regard legal, functional and
product-related viewpoints.
All questions are managed in a database and can be answered and printed there
after entering free text. They can also be used as template for questionnaires that
should be completed by project members in the two initial phases of the
implementation (project preparation (Section 3.1), Blueprint (Section 3.2» for the
preparation for workshops.
4.4.2 Process Hierarchy
The "x structure" (x = release, e.g., "4.0B") subarea of the Q&Adb can be used to
define the scope of the Rl3 implementation project, and manage the requirements
and design decisions associated with the defined scope. The Q&Adb structure is
oriented on the process hierarchy of the Rl3 system (refer to Section 1.4.9). As
Figure 4.2 shows, this hierarchy consists of the levels of the
• enterprise process areas,
• scenarios,
• process groups, and
• (low-level) business processes.
The transactions (business process procedures) of the Rl3 system are located
below the lowest level, the business processes.
At the first four levels, the user can decide whether or not this and the lower
areas, namely also the transactions, are to be included in the project scope. If the
user wishes, for example, to include the sales enterprise area, this can be realized
using an appropriate function ("enterprise process area in the scope"). All lower
level areas (scenarios, process groups, business processes and transactions) are
also included in the scope. If, for example, a scenario from sales is now to be
excluded from the project scope, an appropriate function (deactivate "scenario in
the scope") can be used to perform this. This means that all lower level areas
(namely all business process groups and business processes, also refer to Figure
4.3) are also not used. Consequently, to keep the work effort as small as possible,
you should proceed as follows: If it can be assumed that a company needs most
business processes of an Rl3 enterprise area, this area should be included first in
122 4 Tools
the project scope and then all scenarios, process groups and processes not required
should be excluded. If only very few business processes are used from an Rl3
enterprise area, successively include only the required areas (business processes,
process groups, scenarios) in the project scope.
Enterprise Process Areas
Scenarios
Process Groups
Business Processes
Figure 4.3: Limitation of the project scope

Initially all transactions from the selected business processes are included in the
project scope and an suggested assignment (standard configuration plans) made
for the baseline or for the final configuration. The user can change this (refer to
the "Business Process Transactions" subsection on page 125).
At this point, it should be noted that the use of Q&Adb assumes that the user
understands the associated terms and functions of the Rl3 system related with the
areas of the process hierarchy, and knows how he must assign the areas of his
enterprise in this hierarchy. However, an assignment between the Rl3 enterprise
areas designed by SAP and those of the own enterprise is not always easy to find
and often not unique. These assignment decisions must be appreciated as being a
central, economic design decision. This means that the Q&Adb user determines
which scenarios and processes of the Rl3 system are to be used to handle and
support the specified business processes of the company.
The user can define additional enterprise areas to supplement those areas
supported by the Rl3 system. This makes it possible to include in the Q&Adb
requirements that the Rl3 system does not cover. Thus, the structure of the process
hierarchy can be completely changed and extended by defining new enterprise
areas, scenarios, process groups, business processes and transactions. Similarly, it
is possible to copy and rename existing elements, such as a scenario with all
subelements of the structure.
Questions can be managed for the upper four levels of the process hierarchy. A
differentiation must be made here between general questions that are identical for
all levels (refer to the "Blueprint Form" subsection) and the special questions for
the levels. The current Q&Adb (ASAP 4.0, December 1998) is supplied only with
special questions for the highest level (Enterprise Process Area) and the lowest
level (Process). However, the user himself can add and delete the questions in all
levels.
At this point, it should be emphasized that, from the technical viewpoint, the
answers to the questions are no prerequisite for the project progress. However, the
questions-and-answers help with the systematic analysis of all requirements, and
the resulting answer catalogs, are indeed essential not only to understand and
follow the decisions to be made but also for the concrete realization of the
configuration (refer to Section 3.3).
Questions concerning the business process (enterprise process area

level)
The questions to the Rl3 enterprise process areas for the Q&Adb cover the
organizational requirements of the company with regard to the associated area.
These determine the legal regulations, location dependencies of the individual
organizational units, market and product-related structure characteristics and time-
related requirements of the enterprise.
For example, the following questions are asked in the sales area,
• whether the organizational units for marketing can sell products only from
specific product groups or all products,
• which criteria (e.g., product groups, regions, customers, distribution channels)
are used to structure the marketing activities of the enterprise,
• whether the invoicing is organized centrally or decentrally, and
• whether there are several shipping locations within a operational site.
Although the questions primarily concern the use of Rl3, additional questions
can be added to both the existing and to the self-defined enterprise areas.
Questions concerning the business process (business process level)
At the process level, requirements are recorded or design decisions made that now
only apply to the level of the associated business processes. The procedure is
largely identical with that of the level of the Rl3 enterprise areas.
Processes at this level are normally closely related to specific documents or
business object types. Typical documents and business objects here are a customer
order or a material master. Thus, some of the questions asked for the "customer
order processing" business process (marketing / warehouse sales to industrial
purchaser / customer order),
124 4 Tools
• when customer orders are produced,

• the means with which the enterprise receives customer orders,
• which employees have access to the various types of customer orders and on
which criteria (product group, customer type, distribution channel) does the
access depend,
• which business partners are involved in the order processing, and
• which rules are used to test the available inventory level.
Blueprint form
Questions for a so-called blueprint form, a list of general questions, can be

answered for each of the four levels of the process hierarchy. These questions
represent a major item in the analysis of the requirements of the enterprise, and
their answers form the main part of the business blueprint document (refer to
Section 3.3). It refers to
• the expectations of the user by describing the future business processes and
requirements from his viewpoint,
• special events (triggers) that cause the execution of a process, and special tasks
that must be solved during the process,
• special features of the business process that exist in conjunction with specific
organizational structures of the enterprise,
• whether business process models (diagrams) are managed, and, if yes, by
whom,
• problems to be expected as the result of organizational changes,
• improvements or deficits that can be expected during the implementation of
the R/3 system,
• short-term measures to avoid deficits (additional reports, supplementary
programs, in-house developments),
• future projects that can be used to counter the larger deficits,
• recognized configuration problems,
• measures to transfer (old) data from other systems,
• planned or requested interface developments and report developments, and
• measures to develop authorization concepts.
The answer of these questions is a prerequisite for producing the business

blueprint documents, which serve as starting point for the configuration in the
third phase of the Implementation Roadmap (refer to Section 3.3). This document
is used repeatedly during the project as information source, and can be extended
and regenerated after the necessary change requests have be approved by the
project management or the steering committee. The document can be produced
from the Q&Adb with the "press of a button".
Business Process Transactions
The matrix that exists for every business process lists all R/3 transactions that can
be used to realize this process in the R/3 system. The matrix (refer to the example
in Figure 4.4) contains the transaction code (refer to Glossar), the name and the
type (TR=transaction, DA=dialog, RP=report) of the transaction. It can be
specified whether the process is to be part of the baseline configuration (BL) or in
which cycle (CI-C4) the transaction otherwise to be configured and be tested
(Section 3.3.3 and Section 3.3.4 contain further information for the baseline
configuration and the cycle concept).
The information specified here is used in the Business Process Master List
(BPML, refer to Section 4.4.4).
Code Type Is:: aa C2 C3 CAM 12
V.02 Display Incomplele Sales Orders lR X X
V.14 Display BlocI<ed Orders lR X
V.15 Display Backorders lR X
VZ3 Release Orders for Billing lR X X
V25 Release Customer Expected Price lR X X
VN)l Create Sales Order lR X
VA02 Change Sales Order lR X
VA03 Display Sales Order lR X
VN)5 Ust 01 Sales Orders lR X X X
VA07 SaleslPurchasing Comparison lR X
VA08 Display: Compare Sales·Purchasing lR X
Figure 4.4: Transactions for a business process

126 4 Tools
4.4.3 Issues Database
The Issues Database is used for the simple management of all outstanding
questions and problems that occur during the project. As Figure 4.5 shows, the
questions and problems can be entered in natural language and described with the
following attributes
• problem description,
• responsible person(s),
• priority (low, medium, high),
• problem area (business process, system administration, administration, etc.),
• status (created, opened, delayed, completed),
• requirements date and
• date of completion
The tool also provides a number of predefined reports and a simple report
generator.
~In u e Edllo l
Issue jAUthenzeuen fer User Miller
Issue Detells I
a ...smccben IAu1l1en'DiJen Pnonty IMedlum
PrOject Phese IReell'Dbon ·lnlegrDllon Test SIDlu. lOosed :::J .

Respenslble 1 IJeerg Riner JR Dele Requ"ed 116 01 .00
Respo.nsible 2 I Dele Reso.lved f7.0100

Issue Reso.lUtlo.n
o.1l1er Duthen,eilen prefile was ,..signed to. Mr Mllier
Seve Ce.ncel
Figure 4.5: Issues Database

4.4.4 Business Process Master List
The Business Process Master List (BPML) is a spreadsheet (MS Excel sheet) that
can be generated from the Q&Adb. This tool contains the complete process
hierarchy defined by the project scope, including the transactions to be configured.
The BPML is used for the organization for the tasks to be performed in phase 3
(refer to Sections 3.3.3 and 3.3.4). This is done by creating configuration, test and
acceptance plans for the baseline and the cycles of the detailed configuration. This
tool also contains functions that can be used to access blueprint form questions
(see above) and so-called Business Process Procedure Documents (refer to Section
4.14.1).
Parallel to the creation of the BPML, a predefined project IMG (refer to Section
4.9) in the R/3 system can be tailored for the customizing transactions needed for
the project scope. Figure 4.6 illustrates this dependency. The components of the
R/3 system and the business processes for the R/3 system that make use of the
functionality of the individual components are symbolized there as vertical
rectangles and horizontal arrows respectively. This dependency means that all
components (here with dark gray background) used to support the business
processes (here with gray background) defined by the project scope must also be
configured and thus belong in the project IMG.
Components (Project IMG)
Processes I..,-----'-'---..J..l-_____
(BPML)
> >
L _ __ -'
Selected
processes (scope) O Necessary
components
Figure 4.6: Dependencies between scope and IMG
4.4.5 Outlook
SAP has announced a number of new features for the next versions of the Q&Adb
(4.5B and later) that we briefly discuss here.
128 4 Tools
The main characteristic of the Q&Adb is that it in Implementation Roadmap

(refer to Chapter 3) is increasingly becoming the central, cross-phase tool for the
Rl3 implementation. Consequently, the presented structure of Version 4.0B has
been greatly extended and replaced by a structure with the following items:
• business strategy *,
• organization,
• general settings*,
• master data *,
• business processes,
• cross application components*,
• training and documentation*, and
• development*.
The new items indicated by an asterisk ("*") show that all areas of the
implementation, in particular the business blueprint phase, thus also the definition
of the business strategies, the development of appropriate organizational structures
and any supplementary developments, are now represented in the Q&Adb.
The integration of the Q&Adb with "associated" tools - such as components
from the Rl3 system itself and modeling tools for the Rl3 reference model (refer to
Section 4.8) - has also been improved. Thus, in addition to the BPML, appropriate
lists for the organizational structure are produced and the chosen organizational
structures have an immediate effect on the IMG of the Rl3 system.
The ASAP CD-ROM contains the new Diagram Explorer (refer to Section
4.8.3) that can also be invoked from the Q&Adb to view the Rl3 reference model.
4.5 Structure Modeler
Like the Business Modeller (refer to Section 4.8), the Structure Modeler is a tool
that makes use of the Visio drawing tool (current version 5.0). Visio is a software
product that can be used to create diagrams, normally graphics, for predefined
diagram types. Visio operates in two modes: in the definition-time mode, in which
diagram types (so-called templates) can be defined, and in the run-time mode, in
which concrete diagrams based on previously defined or supplied diagram types
can be created. To define a template, the user specifies the node and edge types
(so-called shapes) for a diagram type. The user selects at run-time these shapes
and uses them to create concrete diagrams of a diagram type.
SAP supplies on the ASAP CD-ROM a template (Structure Modeler Template)
to define organizational structures that it has also developed. The combination of
Visio with the Structure Modeler Template tools is then designated as the
4.5 Structure Modeler 129
Structure Modeler. Note that the Visio tool must be licensed from the company
with the same name, thus, is not included on the ASAP CD-ROM.
The Structure Modeler can be used in advance to represent as layer diagrams
the organizational units and structures to be created for a company in the Rl3
system (refer to Section 3.2.4). Figure 1.17 shows a simple example. The modeler
is provided with a shape for each organizational unit type (client, company,
company code, etc.). The shapes do not differ in the form but only in their color
and size, both of which can be determined by the modeler.
4.6 Concept Check Tool
As with the Q&Adb, the Concept Check Tool is a tool also supplied with the
Implementation Assistant on the ASAP CD-ROM. This tool is used to document
and, to a limited extent, the automatic checking and assessment of the decisions
made during the first two phases of the Implementation Roadmap (project
preparation and Business Blueprint, refer to Chapter 3). The system asks the user a
number of questions, which, in according to the phases, are divided into two parts.
These phases are divided into topic-related checklists. Some of the questions
cannot be answered in natural language, but only by selecting predefined
responses. This permits the system to draw conclusions, and to issue warning,
recommendations, notes (using ass Notes, refer to Section 4.13.4) or
confirmations for the decisions that have been made.
Specific comments can be stored for all checklists and questions. All questions,
together with the responses and the supplementary comments, can be viewed on
the screen and printed.
The questions for the project preparation refer to
• general details such as selected systems (operating systems and database
management systems) and contact partners for the various SAP components
in the enterprise,
• the project organization (the selected project organizational structure, the
number of subproject teams, the size of the teams, the system administration)
and
• application-system-related aspects (Quick Sizing [refer to Section 4.13.3], the
expected data volumes for the most important transaction data, such as orders
and projects for the used SAP components, system landscape and client
concept, refer to Section 3.1.2).
The questions for the business blueprint phase are used for the lower-level
analysis of the affected decisions for the parameterization of the Rl3 systems.
Individual checklists that request the system settings are provided for the most
important components of the Rl3 system (FI, CO, La, MM, QM, PP, PS, SD, HR,
PD, PA (refer to Section 1.4.3)). The aim of the questions is to inform the user
130 4 Tools
about potential bottlenecks in the system capacity and to provide help in making
high-performance configuration settings for the choice and the realization.
4.7 Business Navigator
The Business Navigator is part of the Business Engineer (refer to Section 1.4.6)
and thus integrated in the base component of the Rl3 system. It is a tool with
which the user can navigate in the Rl3 reference model (refer to Section 1.4.9) and
access the associated information of the help system or the transactions of the Rl3
system. Because the Business Navigator permits the visualization of the scenarios
and business processes of the Rl3 system, it can be considered as being a
supplementary tool for Q&Adb. Consequently, it is also increasingly being used in
Phase 2: Business Blueprint (refer to Section 3.2). The functionality and the
design of the Business Navigator is oriented on the structure of the Rl3 reference
model.
The following sections initially describe the basic capabilities of the Business
Navigator used to view the R/3 reference model (refer to Section 4.7.1), then the
two layers of the reference model (Sections 4.7.2 and 4.7.3), and finally the more
advanced uses of the Rl3 reference model outside the Business Navigator (Section
4.7.4).
4.7.1 Navigation in the R/3 Reference Model
The Business Navigator provides two different, hierarchical navigation structures

for the exploitation of the Rl3 reference model by the user: the process hierarchy
and the component hierarchy. The low-level processes and functions of the Rl3
reference model can be accessed in both hierarchies at the lower levels. All other
elements are embedded in just one of the two navigation structures. Whereas
business object models, business object types and organizational units are located
only in the component hierarchy, scenario processes and value chain diagrams
(VC-Diagram) are restricted to the process hierarchy. Both navigation hierarchies
are realized as trees, whose nodes represent not only the discussed elements of the
Rl3 reference model or their diagrams but also elements of the structuring of the
Rl3 system. A number of specific navigation capabilities are offered appropriate
for the type and position of a model element.
4.7.2 Process Hierarchy
The form of the process hierarchy (refer to Figure 4.7) is oriented on typical
business process structures. With regard to the level of detail, a differentiation is
made between the following six levels: enterprise process area, scenario, process
4.7 Business Navigator 131
group, process variant, process and function. The elements of the R/3 process
model are assigned in this hierarchy and can be accessed by the user at the
appropriate level. The model-inherent links can be used to navigate (refer to
Section 4.7.4).
R/3 Reference Model
-.......
Fll\a.nce Management
EnlcrpMo PfCICOSS As..
Scenario
pn)C8S$ VanlU1t
•••.•...SecuntIe!l accounllra:nr.sler ).-.-.~-."",,-.-w.-.--· G
Figure 4.7: Structure of process hierarchy

The complete model at the highest level is initially subdivided into various
enterprise process areas that represent task fields such as sales, production and
procurement. No diagrams are associated with the enterprise process areas, but
rather they have just a structuring character.
A number of scenarios (2nd level) are assigned to each process area. Scenarios
are used to describe sample business processes that go over department
boundaries. A scenario includes subtasks from various components of the R/3
system and illustrates the business flow for the processing of several tasks by
several clerks who can be in different departments. The scenarios are represented
at two different levels of detail. Starting for the scenario nodes of the process
hierarchy, it is initially possible to navigate to a value chain diagram. The
individual elements of this diagram correspond to the process groups assigned to
the scenario. A process group combines the processes of a business segment.
EPCs (refer to Section 1.2.2) of the scenarios (scenario EPCs) can be reached
from this compressed view. They represent the scenarios as process chains and so
attain a higher level of detail. Rather than the process groups of the value chain
diagram, an EPC represents here in a diagram the individual processes and their
time-logical linkage. The areas of the individual process groups can be given a
colored background in the diagram.
The business processes modeled in the scenario-EPC are formed from the
processes and process variants of the R/3 system. The process variants are initially
inserted into the process hierarchy under the process group as an additional level
132 4 Tools
of detail. Several alternative processes are assigned to a process variant. If no

variants are required for a task, the level of the process variants is bypassed and
navigation is done directly at the process level.
A low-level process (level 5) in the R/3 reference model describes the handling
of one or more R/3 applications by a user while processing a business process.
Low-level processes can be considered as being abstractions of concrete R/3
transactions. Thus, a low-level process describes several alternative transactions.
If a process covers the handling of several main components - the general
ledger account master handling process uses, for example, eight R/3 components -
the individual functions must be assigned to these different components. Starting
at the process, it is possible to navigate to an input/output assignment, which can
be used to display the transaction codes of the transactions assigned to the process
and its business object types. The functions used in a process are assigned as
leaves of the tree in the process hierarchy under the process nodes.
The process of a scenario is often a specific process variant that was eliminated
for the unwanted functionality of a basis standard process. In the Business
Navigator, it is possible to optionally display the reduced process variant as
generated EPC representation of the complete process with the transparent
displayed but not needed functionalities. The process path (refer to the EPC
symbols in Section 1.2.2) in both cases supports the horizontal navigation at the
level of the processes.
4.7.3 Component Hierarchy
In contrast to the process hierarchy, the component hierarchy (refer to Figure 4.8)
provides a function-oriented navigation structure that is based only on the
components of the R/3 system and which represents the structure of the
applications of the R/3 system. The applications of the system are formed from
individual modules, the components. Each component can itself consist of a
number of additional subcomponents. Depending on the size of an application, the
number of components and the structure depth can vary, although a depth from
four to six levels is typical. The size and the level of detail of an application are,
after all, dependent on the implemented, business function scope in an area. The
resulting component hierarchy then describes in increasing detail the scope and
the functionality of an application of the R/3 system (top-down). This component
hierarchy is also used outside the Business Navigator in the R/3 system, e.g., in
the implementation guide (IMG, refer to Section 4.9.1).
RI3 Reference Modef
........
........
~
~
~,
Processvarlan!
- - -- . ( $ubEPC)
Process OuanCity Contract
Func:bCn Process BuSl'leSS Patlf\Or
FunctIOn valianl Procea: Pr.·s. ... P.ann",
Figure 4.8: Structure of the component hierarchy

A description and detailed information are stored for each application
component. The description contains a definition of the component that describe
their business functions, additional subdivisions, etc., and thus permits an
assignment to and differentiation from other components at this level. In addition,
the criteria listed in the description describe in which context the use of a
component is necessary or the extent to which the component is obligatory for the
R/3 system. The subconditions relevant for the connection of a component for the
configuration of the system are stored here in text form. The descriptions can be
invoked from the online help pages of the R/3 system. In addition, system-related
detailed information is stored in an overview mask.
The elements of the R/3 reference model are displayed as three different
assignment levels in the component hierarchy. A separate view is provided for
each of the processes, business object types, and organizational units. The
elements are appended in each view as leaves at the nodes of the associated
application component. The scenarios can be assigned in the component hierarchy
using their cross-component character.
The low-level processes and functions of the application components of the R/3
system are displayed for the selection of the assignment view for processes. The
assignment is always made at the level of the finest level of detail of a component
in the component hierarchy. Processes have not yet been assigned to all
application components of the R/3 reference model.
Starting at the nodes (events and functions) of the low-level processes it is
possible to navigate using the appropriate symbols to the EPC diagrams of the
processes. These EPCs provide a variant-neutral representation of the processes.
134 4 Tools
Additional nodes for the functions of the processes and the process variants are
also added to these nodes. In contrast to the representation of a specific process
variant in the process hierarchy, all variants of a process are displayed in the
component hierarchy. If the appropriate function variants exist for a function, they
are listed below the function.
Business object models and business object types are assigned in the hierarchy
of the application components to provide the assignment view for business
objects. Here, the diagrams for the business object model are assigned to the
components in the higher levels. The business object types used in the business
object model are placed either at the level of the business object model or lower
beside their specific components. Descriptive attributes are also maintained for
business object types as part of the Business Navigator. The Data Modeler (refer
to Section l.4.7) can be used to navigate in the Rl3 data model from the graphical
display elements of the business object types.
The business object types in the component hierarchy acting as organizational
units are displayed in the assignment view for the organizational units. The
instances of their attributes are also available as text. The assignment provides an
overview of the organizational units that need to be defined as part of the
customizing of the individual application components of the Rl3 system.
4.7.4 Navigation Capabilities
The previous discussions have shown how the elements of the Rl3 reference
model are presented to the user of the Business Navigator using two different
navigation structures (process and component hierarchy). Depending on the type
of an element, different navigation capabilities are available to display the objects
and their properties in both hierarchies. The following section provides an
overview of which navigation capabilities with which elements exist and the
associated information. A differentiation can be made between three types of
information: models (or model assignments), additional information, and
information integrated in the Rl3 system.
The group of the models and model assignments includes all graphically
prepared information such as the EPe diagrams for the low-level processes and
scenario processes, the value chain diagrams for the scenarios, and the diagrams
for the business object models. There are also model assignments that describe the
input-output assignments and the assignment of organizational units to processes.
The input-output assignments display in list form which information objects a
process requires as input or produces as output. The organizational units
assignment displays in list form all organizational units that are significant for a
specific process. It is possible to navigate from the diagrams of the business object
models in the data model of the data modeler used as basis.
The group of supplementary information permits the display of attributes,
component short descriptions, usage references, and the description of business
object types. The attribute displays are primarily used for scenarios, processes,
functions, and variants. They provide detailed information, such as the processing
type of a function, for the individual objects. Processes are generally considered to
be functions (refer to Section 1.2.2) and given the corresponding attributes. A
component short description is reserved for the application components of the
component hierarchy. Usage references are available for scenarios, processes,
functions, and variants. They represent a list of all diagrams or components that
use the selected object.
The information integrated in the Rl3 system also provides the capability to
invoke transactions and to browse the Rl3 documentation. The user can navigate
from processes and functions to lists that show the assignment of Rl3 transactions.
These transactions can be invoked directly from these lists. It is possible from the
nodes of the component hierarchy to navigate to the activities of the
implementation guide (refer to Section 4.9.1) assigned to a component of the Rl3
system. The user can jump directly from the Business Navigator to the
corresponding activity of the implementation guide. If an entry in the Rl3 online
documentation has been dedicated to a model element, this can be directly
selected from the Business Navigator. In a similar manner, it is possible during
project documentation to invoke SAPoffice for the enterprise-specific
documentation of components and processes. A structure for the project
documentation is created in the SAPoffice during the generation of a company
IMG (refer to Section 4.9.1). This structure from the process view of the Business
Navigator can be supplemented with folders for scenarios and processes.
Filters
During the implementation of SAP Rl3, the user can generate enterprise IMGs and
the project IMGs (refer to Section 4.9.1) based on them. The subset of functions
for the complete Rl3 system defined in these implementation guides should be
considered during the implementation. The component hierarchy of the Business
Navigator displays as standard all components of the Rl3 system. The filters can
be used to reduce the component hierarchy to the scope defined in the
implementation guide. This navigation structure can then only access those model
elements that are relevant for the selected functionality.
4.8 Tools for the Business Process Modeling
Tools for the business process modeling (BPM tools) can be used to document not
only the business processes but also the process structure and other structures of
the company or its business information systems. Depending on the phase of the
implementation of company standard application systems (analysis, design,
operation, improvement/maintenance), they can be used for the analysis of
existing systems, for the design of future systems or for monitoring current
systems. Depending on the aim and nearness to the technical realization, DP-
l36 4 Tools
technical aspects, such as computer network structures and database schemes, can
be described in addition to the commercial aspects.
Some of these tools can be coupled to the R/3 system using interfaces and then
used to adapt the R13 reference model.
4.8.1 Model Adaptation and Improvements
There are a number of possible uses for the R13 reference model, which, however,
for various reasons, could not previously be realized in the R13 system:
• The R13 system provides several possibilities for the user to navigate in the R13
reference model and to search for additional information. However, because
the Business Navigator is integrated in the R13 system, these functions can be
used only after the installation. This delays the mapping of company-specific
requirements with the function scope of the R13 system on the basis of the
reference model. However, this disadvantage will be rectified in future ASAP
versions (from 4.5) through the provision of a dedicated repository that makes
the reference model available independent of an R13 installation.
• In its current form, the Business Navigator has only read access to the R13
reference model. This sets certain limits to the intensive use of the R13
reference model. Although a company-specific business process models on the
basis of the R13 reference model can be built with additional tools (refer to
Section 4.8.2), the changed reference model (Release 4.0B) cannot currently
be reimported into the R13 system.
• During the implementation of a standard business software product, the
configuration could be performed directly using a reference model. Thus, it is
conceivable that changes made to the diagrams of the business processed have
direct effects on the configuration of the system. SAP does not support this so-
called model-based customizing. Rather, the Q&Adb is the starting point for
the configuration during the R13 implementation, which, however, allows a
restriction of the customizing transactions.
Manufacturers of BPM tools attempt to counteract these deficits of the Business

Navigator with regard to the model availability and the model adaptation by
providing the R13 reference model outside the Business Navigator in self-
contained tools. The model in this case is normally provided as a copy and so
permits the processing and, in particular, changes to the reference model
independent of any specific R13 installation.
Currently the following tools are available:
• ARIS for R13™ from IDS Scheer AG,
• Business Visualizer™ from IntelliCorp, Inc. as add-on to the Business
Modeller™ from Visio, and
• iGrafx EnterpriseCharter™ from MicroGrafx, Inc.
4.8 Tools for the Business Process Modeling 137
4.8.2 ARIS Toolset
Various software manufacturers have positioned tools in the Rl3 system

environment that provide additional capabilities for the business process
management in addition to the model adaptation of the Rl3 reference model (refer
to Section 4.8.1).
ARIS Toolset is the leading tool. It is based on the ARIS concept in which an
application or information system is described from various perspectives (views)
and can be integrated in a process view using EPCs (refer to Section 1.2.2). In
addition to the presented views, a differentiation can be made in each view into
the three levels: system design, DP concept and implementation. These are used
for the phase-related documentation of the development of application systems
and complete information systems. Thus, the layers generally correspond to the
phases: analysis, design, and implementation.
Several additional components are provided for the ARIS Toolset that are used
for the analysis, assessment and presentation of the created business process
model (EPCs). These include a simulation, an activity-based costing component,
and a Web component.
The simulation component permits a stochastic quantity and time-related
simulation of the EPCs. The calculated times and quantities are initially used for
the validation of the created process models with regard to the actual situation of
the company. Future business processes can be modeled on this component
(planned concepts) and use it in their evaluations.
The activity-based costing component is used for the assessment of the EPCs
using modem methods of the activity-based costing that permit even secondary
processes, namely processes not directly involved in the value added, to be
assessed according to the service they provide.
The Web component permits publicizing the models created with the ARIS
Toolset in the Intranet and Internet, and these to be viewed with simple Web-
browsers. For example, standardized business processes can be placed online as
process instructions in the company-internal network and be made accessible for
every employee.
4.8.3 Outlook
As from Version 4.SB, the ASAP CD-ROM contains the so-called Diagram
Explorer that provides the functionality of the Business Navigators outside the Rl3
system. This supplementary tool makes it possible to view the diagrams of the Rl3
reference model even before an Rl3 system becomes available. Support is also
provided for direct navigation between the process hierarchy of the Q&Adb (refer
to Section 4.4) and the Diagram Explorer.
138 4 Tools
4.9 Customizing
The customizing component is the second component of the Business Engineer on

addition to the Business Navigator. It is used, mainly in Phase 3: Realization (refer
to Section 3.3), to adapt the application system to the requirements of the
enterprise. Thus, this tool integrates all important information items. Namely,
without the "correct" settings, the Rl3 system cannot function according to the
requirements of the enterprise.
The major part of this component is the implementation guide (Section 4.9.1).
Information for the project steps can be stored (Section 4.9.2) for the
documentation that accompanies the project and for evaluation. The Change and
Transport Organizer (Section 4.9.3), also a subcomponent of the customizing
component, permits the transport of settings between various Rl3 systems and
clients.
4.9.1 Implementation Guide
The Implementation Guide (IMG) is a tool for the planning, realization and
documentation of a specific configuration of the Rl3 system. The IMG can be
invoked either directly in the Rl3 system or from the BPML (refer to Section
4.4.4) using project-specific views (project-IMGs).
The IMG has a hierarchical structure based on the component structure of the
Rl3 system (refer to Figure 4.9). The customizing transactions form the lowest
level of this hierarchy and so represent the elementary activities of the
customizing. Expressed more simply, this means that the implementation of the
Rl3 system consists essentially of the realization of these transactions. All other
activities (with the exception of the technical measures such as installation of
computers and software) are used exclusively for the preparation of these
elementary activities. Even subsequent changes to the organizational structure or
selection of procedures are performed using the IMG.
For every activity, i.e., transaction to be performed,
• the online help can be invoked that contains detailed explanations for the
transaction (explanation of terms, prereqUlsites, standard settings,
recommendations and individual steps for the realization of the transaction),
• project and status information (see below) can be requested, and
• comments can be stored that have been derived from previously defined
comment types (e.g., system setting, status report, error message).
4.9 Customizing 139
Rl3 Implementation Guide
Component 1
Component 2
1----.... Subcomponent 2.1
1----,-.... Subcomponent 2.2
D ~ "" Customizing Transaction 2.2.1
D ~ "" Customizing Transaction 2.2.2
'----.-.... Subcomponent 2.3
D ~ 5! Customizing Transaction 2.3.1
Component...
Legend :
== Online Help
== Perform The Customizing Transaction
== Update Project and Status Information
= Update Notes
Figure 4.9: R/3 Implementation Guide (IMG)

The IMG activities should be processed in sequence, because this order takes
account of the dependencies between the settings. However, because not every
user the requires the complete functionality - a trading company, for example,
would not use the production planning system - it can restrict the IMG (SAP
Reference - IMG) in several levels (refer to Figure 4.10). A differentiation is made
here between
• the enterprise IMG that contains only those activities of the SAP Reference
IMG supplied by SAP that the complete enterprise/concern is to perform,
• the project IMG(s) that contains the activities to be performed during a
(sub )project of the Rl3 implementation, and
• the views for the project that permit additional restrictions (e.g., mandatory and
optional activities) on a project-IMG.
Figure 4.10 shows at the right-hand side the various IMG types and in the left-
hand part a sample representation with its own activities from the SAP Reference
140 4 Tools
IMG, which through the selection mechanisms of the customizing component can
be restricted or divided into smaller IMGs (three project-IMGs) and IMG-views
(seven views).
Activities
SAP Reference IMG

(all activities)
,
, I,
, , , " , , ,,
, , ,
, A , I \ .'
, ,, ;' t
,, ,
, I
I I I I
Views to I 1 I I
Project IMGs (7) I I I I
I I I I
Figure 4.10: Restriction to the SAP Reference IMG

The enterprise itself specifies the enterprise IMG at the project start and, if
possible, should contain all activities that are to be performed sometime during the
project. Various project teams specify the project IMGs and the resulting views. If
the enterprise IMG is changed, these changes must be duplicated explicitly in the
project IMG.
According to a statement from SAP, Rl3 from Version 4.6A will have several
changes in the Rl3 system that include the omission of the enterprise IMG.
4.9.2 Project Documentation and Analysis
As previously implied in the earlier section, project and status information with
reference to the activities of the customizing can be stored in the customizing
component of the Rl3 system and then evaluated later. This requires that some
4.9 Customizing 141
settings be made in the project administration of the customlzmg component

before the actual configuration of the R/3 system is started. In particular,
• different project states ("in progress", "completed", "quality assurance
performed", ... ) must be defined to which the project activities can be assigned
later,
• selection fields must be determined that are used for the specific classification
of the status information for the customizing activities,
• all resources (project members with responsibility) selected from the circle of
R13 users that are eligible for the realization of the customizing, and
• comment types specified that permit a classified assignment of project-relevant
information (e.g., system setting, status report, error message).
The project activities than can be defined in more detail. For all activities,
• dates for the scheduled start and the scheduled end can be specified,
• resources (employees) assigned that are responsible for the realization, and
• selection fields selected that permit a structured evaluation of the project
information.
The assigned employees are responsible for updating the project information
during the actual configuration of the R13 system (baseline and detailed
configuration, refer to Sections 3.3.3 and 3.3.4). They select the "Update Project
and Status Information" button at the start of the realization of an activity in the
IMG the specify, for example, "in progress" as current status. This automatically
sets the start date (actual), which, for control purposes, can be subsequently
compared with the planned date.
From the project management viewpoint, various reports can be invoked from
the customizing component for the monitoring and control of the project.
Predefined reports to determine all planned activities that have been started but not
yet ended, all activities that have been started, and activities that have been
completed, etc. Specific reports are also possible. This also provides the means to
check the completeness of the baseline configuration or the specific detailed
configurations.
Because the system logs in a history file every change to the status information,
repeated changes to an activity can be tracked for control purposes.
4.9.3 Change and Transport Organizer
SAP recommends a three-stage procedure for the implementation of the R13

system: settings made during the adaptation are first made to the development
client and then checked on a quality assurance client, and finally actually used in
the productive clients. Because some configuration settings are destined for all
clients of an R13 system (client independence), it is recommended that each of
142 4 Tools
these three clients runs on its own Rl3 system (refer to Section 3.1.2). In this
connection, SAP provides with the Change and Transport Organizer (CTO) a tool
that permits settings to be exchanged between clients and systems (SAP jargon:
transport). This tool makes it possible to transport both client-dependent and
client-independent settings from one system, e.g., the development system, to
another system, e.g., the quality assurance system.
To initiate the transport of the setting, a so-called change request must be
created in the system. Such a request can be used to transport both client-
dependent (customizing request) and client-independent configuration settings and
software developments of the ABAP/4 Development Workbench (workbench
request). To log all the settings, which, for example, are made during the
development, an appropriate flag can be set for the entry of the client.
4.10 Rl3 Authorization System
The Rl3 authorization system serves as basis for the "Establish the Authorization
Concept" (refer to Section 3.3.11) and the concrete specification of rights to users
as part of Phase 3: Realization (refer to Section 3.3).
4.10.1 Security Concepts
Complex protective mechanisms are necessary to ensure the integrity - through

the maximum possible restriction of unauthorized changes - and the
confidentiality - through inhibiting unauthorized data access - for the information
processed by an application system. These mechanisms are present everywhere
where other "systems" such as human beings, computers and other programs
bound on the interfaces of the application system. These interfaces include not
only user interfaces (SAPGUI), but also computer, network and software
interfaces. The appropriate protective mechanisms are required at all levels. This
sections discusses only those authorization systems concerned with the interface to
the user. It does not discuss other mechanisms, such as the encryption required to
protect the data communication (refer to Buck-Emden and Galimow 1996).
Authorization systems must satisfy at least three goals, some of which conflict
each other:
• the company wishes to achieve a high-degree of security for its data,
• the employees require adequate rights in order to be able to perform their work
efficiently and without hindrance, and
• the administration of the authorizations and user data must be handled as
simply as possible.
4.10 Rl3 Authorization System 143
SAP for quite some time has provided detailed functionality in the R13 system
to achieve the first two aims. Since Version 3.1G, the profile generator has also
been supplied to simplify the administration. Authorizations can be assigned
directly, i.e., through the definition of authorization objects and the authorizations
that build on these, or, alternatively, organized indirectly using the profile
generator. SAP recommends the latter method, which we describe in more detail
in the next section.
4.10.2 Principle of the Authorization Validation
A user before he starts the work must always log on with a user name and the
associated password. The R13 system validates both these entries. The SAPGUI is
then available to invoke the R/3 functionality (transactions, reports). The
prerequisite for an invocation is that the user has been given adequate
authorizations. The user master record created for every user of the R13 system
contains the data (name, password, activity groups, authorization profiles)
required to validate his authorizations.
The R13 authorization system differentiates between three fundamental types of
information that must be used to validate authorizations. These are
• transactions (which transactions can a user invoke?),
• fields (which fields must be checked here? also refer to Section 1.3.2.), and
• values (what values can these fields assume?).
Authorization fields are defined and authorization objects assigned here. An

authorization field is an attribute whose value must be checked before the
execution of a transaction. An authorization object (refer to Figure 4.11) is a list
of fields that always and independent of the user must be checked in one or more
ABAP programs before the associated program can be further processed. The data
element from the ABAP/4 Dictionary assigned to a field defines the permitted
value range (domain). To improve the organization, the authorization objects are
grouped into object classes.
An authorization in the R13 system is interpreted as being the combination of
an authorization object and an assignment of values to the individual fields of the
authorization object. One or more values (set or interval) are assigned to each
field. This assignment indicates which user values such an authorization is
permitted to have at run-time, namely for a specific call of a transaction. Thus,
these fields during the validation can assume only the assigned values.
Figure 4.11 provides a small example that illustrates this interrelationship. This
specifies an authorization object "1" that consists of two fields "ACTVT" and
"WERK". These fields have been defined in the ABAP/4 Dictionary and each
may only ever assume three different values (0010, 0011, 0012 and 01, 02, 03),
i.e., even outside the authorization system. These authorization objects can now be
used to define additional authorizations; the example has two, namely "la" and
144 4 Tools
"lb". The authorization "la" has been defined so that only the values 0] and 02,
and 0001 are valid for the ACTVT and WERK fields, respectively. The test is
made at run-time for the execution of all transactions that check the authorization
object "1" whether the current values (e.g., from an input mask for a transaction)
are valid in accordance with the" I a" authorization for the users.
Thus, to validate the authorization, the checking program passes a value for
every field of an authorization object. Such a value can, for example, come from
the user's input. The authorization system then checks whether the passed values
are permitted in the user-specific authorizations. Processing of the transaction
continues only in the positive case.
'"",,1110_,.,
Oataelements
"'_IlIJonoo,oct
e-
"'_ ,
WEAKS
.0010-"""'_'
,CI01. ·Malntenance'
,OO12·Warehousa"
~ ...
Refer8nct Reid
." .
!.oeM
~
Values
01.(l2
0001
-
ACTIVj.lffi<
.010_
V
..
.02': Cnango
.03' OIspiov 1\ ....1horiza"""oq... AuthorizatiOn 2a
~
~terenc Foeld
W<RS
,OOC)1"
,0002"
I'CfVT 01,02
I-
,0003"
r--e W<RS 0001
Figure 4.11: Authorization objects and authorizations

The Rl3 system includes a large number of authorization objects and the most
important task of the authorization assignment is to allocate the correct
authorizations to the correct users. To simplify the work, the authorizations can be
grouped into authorization profiles, which in turn can be grouped into more
complex profiles. Such a complex authorization profile then typically contains the
authorizations that an employee requires in a specific role to perform his tasks.
The example in Figure 4.11 shows two profiles, each of which contains two
authorizations.
If the user administrator defines the authorizations based on these profiles, it is
easy to appreciate that he can easily lose an overview, in particular when
subprofiles for a complex profile contain identical authorization objects with
different authorizations.
4.10.3 Profile Generator
Whereas the definition of authorization profiles previously required a very

detailed knowledge of the techniques used in the Rl3 system, the profile generator
now provides a tool that offers an easier, business-oriented access to this topic.
The profile generator is based on two structures whose elements must be assigned
4.10 R/3 Authorization System 145
to each other. One of the structures is the menu structure (enterprise menu) that
contains executable activities (transactions and reports) using the Rl3 system. The
other structure is the organizational structure of the enterprise that contains the
organizational units, positions and employees (including Rl3 users) of the
enterprise. The definition is made during the assignment of which users from the
organizational structure can use which functionality (activities) of the menu
structure of the Rl3 system. The selected functionality can be used to determine
the authorization object to be tested and the values specified for the fields of the
authorization objects define concrete authorizations.
Menu structure
The menu structure (refer to Figure 4.12) can be used to define activity groups by
specifying along the known menu paths of the Rl3 system which activities are to
belong to a group and which do not. Thus, activity groups define sets of
transactions and reports that can be executed by a group of users that is defined
later. Because the authorization objects to be used in the authorization validation
(refer to Section 4.10.2) can be determined directly from the activities, the
authorization objects for a complete activity group are also known. To be now
able to generate authorization profiles from an activity group, the fields for these
authorization object values (sets or intervals) must be assigned. The user can enter
or change these for each field (refer to Section 4.10.2). The organizational units of
the Rl3 system (company code, plants, sales organizations, refer to Section 1.4.8)
is a special group of fields that are maintained centrally for all authorization
objects and then can be adapted specifically for each authorization object.
146 4 Tools
Enlerprlse
menu
Office logislics Business Accounling
I
Maleriais Managemenl Sales Procluclion
I
Purchasing Invoice Verification
Inventory
I Outline Agreement
Purchase order Requisition
I I I
Create Change Display ... XXX yyy ZZZ
(MES1) (ME52) (ME53) ~ ~
I II
.............................................~j ................ ·········· .. ··· ..·1··1.. ····· ... ··· .. ···· .. ····· .... ··... ···· .. ·· ........... .
( Activity Group 1 ) ( Activity Group 2 ) ( Activity Group 3 )
( Authorization Object 1 ) ( Authonzalion ) ( Authorization )
( Authorizalion ObJ9Ct 2 ) ( Authorization )
( Authorization Object 3 ) ( Aulhorizalion ) ( Authorization ) ( Authorization )
( Authorization Object 4 ) ( Authorization )
Figure 4.12: Menu structure

Once all values have been entered, an authorization profile can be generated
and assigned to the user master record.
Organizational structure
In addition to the predefined organizational units (refer to Section 1.4.8) used to

represent the enterprise structures in the Rl3 system, there is also the possibility to
represent the organizational structures independent of the basic functionality of the
system. The PD component (refer to Section 1.4.4) can be used not only to
document the enterprise from the human relations viewpoint but also for the
workflow management and the authorization management.
The PD contains the following elements to describe the process structure of an
enterprise:
• Organizational units: These include all classification units of the enterprise,
such as departments, subdepartments, groups, etc.
• Positions: These are the organizational units to which both concrete employees
and Rl3 users can be assigned. Normally just one employee or user is assigned
4.10 Rl3 Authorization System 147
to a posItIon. If several employees share a position in the enterprise, for

example as part-time job, several employees can also be assigned to a position.
• Jobs: Jobs describe similar positions. Thus, they can also be considered as
being a job type. Typical jobs are "secretary" or "head of department". To be
able to define positions, jobs must have been defined previously. Every
position is based on just one job.
• Rl3 user: All employees that are to have access to a system are administered as
users in this system.
An organizational structure can now be defined by building a hierarchy of

organizational units to which positions are assigned. Rl3 users are assigned to
each position (refer to Figure 4.13).
Because the organizational structure is organized according to business and
disciplinary aspects, it is well suited to be used to assign authorizations. In the Rl3
system, all elements of the organizational structure can be assigned to activity
groups. Groups of activities generally performed by all employees of an
organizational unit, such as printing and viewing the supplier master file in the
purchasing department, are directly assigned to this organizational unit. More
specific authorizations (e.g., add, delete, change suppliers) are assigned to a lower
hierarchy level, e.g., such as a specific "Purchasing Clerk 1" position. Independent
of this hierarchical structure, it is also possible to assign the same authorizations to
positions from different departments by deriving them from a common job (job
type). Here you divide the activity group(s) for a single job.
Note that the assignment of activity groups to organizational units, jobs
(positions) and users has an effect on the user only when
• the activity groups are valid at the appropriate time,
• the authorization profiles that belong to the activity groups have also been
assigned to the user master records, and
• this assignment has been made before the user logs on to the Rl3 system.
Because the validity can be given a time limit, this would assign certain
activities to a user only for a previously defined time period. Because
authorization profiles are generated from the activity groups, a periodic check
must be performed whether a profile is still valid and, if necessary, regenerated
and assigned to the authorized users. A transaction (PFUD) and a report for the
periodic processing as background job (RHAUTUPl) are available for the
automatic assignment of the valid authorization profiles to the user master records.
148 4 Tools
O'I/ani.
zatlonal
Units
(0e~1)
Purct\iJ""O
(Oepo~~
OISpOSitIOll
)
.Pu~. .-.!si'9 I. .~2' .~. Ma_ Pit"

I .~.} os tOns
l(-:~r()! ''';=It::;l }""

Menog.. CIeri< Clod< ""'-,
c:=:=J c=J} Users
Figure 4.13: Organizational structure
4.10.4 Outlook
Start at Version 4.6A, SAP has promised several changes in the authorization
system. The primary aim is to further reduce the configuration effort. This is to be
achieved by allowing the using company to select from a number of typical user
roles that contain predefined activity groups.
4.11 Application System Interfaces
Interfaces are required where (distributed) application systems not initially

integrated with a shared database are to be connected with each other. A basic
differentiation can be made between interfaces for the one-off data transfer (refer
to Section 3.3.6) that are only required for the change from an old system to a new
application system and thus do not need to be maintained after being used, and
permanent interfaces (refer to Section 3.3.7) for two application systems that may
need to be adapted to meet changing general conditions (release change).
Section 4.11.1 initially provides an overview of a central tool for the interface
development. Section 4.11.2 then discusses selected tools for the one-off data
transfer. The following sections describe the permanent communication for
several application systems (Section 4.11.3).
4.11 Application System Interfaces 149
4.11.1 Interface Adviser
The Interface Adviser is an information tool that provides support for the design
and the implementation of interfaces. It is not part of the Rl3 system, but can be
obtained free of charge from SAP over the Internet (refer to Section 4.13.4). The
Interface Adviser is available for various release levels (3.1 and 4.5) and
languages (English, German), and consists essentially of a structured collection of
text items concerned with "Application System Interfaces" in which it is possible
to navigate using a Web browser.
The text items are arranged hierarchically and permit a navigation based on
typical distributed business processes and the business objects they use, and then
also approaches the technical realization capabilities. The Interface Adviser at the
highest level contains the following items:
• Data transfer: This item presents the procedures and techniques for the one-off
data transfer (refer to Section 4.11.2).
• Scenarios: This item presents the typical commercial problems associated with
distributed application systems and the appropriate solutions provided and
assessed. Scenarios consist of a number of interactions (interaction schemes)
for two or more application systems in which business objects are exchanged
between the application systems. It is possible to make direct reference from
the scenarios to these objects and the alternative transmission types.
• Objects: This item lists all business objects in a similar manner to the
component hierarchy (refer to Section 4.7.3). The Rl3 system import and
export interfaces for each business object are listed. A reference is made to the
appropriate technical descriptions for alternative techniques.
• Technique: This last item presents the techniques supported by Rl3 system
(RFC, ALE, BAPI, etc.), and assesses their advantages and disadvantages. The
various tables arranged according to selected criteria (synchronization,
technology, availability, etc.) are of particular interest.
4.11.2 Data Transfer Programs
SAP provides a number of tools to simplify the task of transferring old data to the
Rl3 system. The Data Transfer Workbench (see below) provides the simplest
method to transfer data. If this standard tool does not suffice, you can yourself
develop the appropriate programs to transfer data.
Overview
Because the data transfer is a time-consuming and error-prone task, it should be

planned carefully. The following steps are the minimum required to ensure a
reliable transfer of the data to the Rl3 system:
150 4 Tools
I. Identification of the fields that must be filled in the data records (business
objects) in the R/3 system and thus must be supplied with information from the
old system. For example, the standard dialogs of the R/3 system can be
analyzed to provide the corresponding field names.
2. Analysis of the data and data formats of the old system that are to be
transferred.
3. Representation of the data structures of the old system. This requires making
the assignments between the fields (attributes) of the old system and the R/3
system, and, if necessary, conversion routines developed to convert the
encoded data from one system (e.g., measurement units) into the specified
encoding of the second system.
4. Preparation of the old system. If possible, all obsolete data in the old system
should be deleted. All other data should be checked for consistency and
corrected if necessary.
5. Data transfer. The data transfer involves either directly exporting the data
from the old system in the format required by the R/3 system or exported in an
intermediate format and then converted into the readable format using a second
program (e.g. , in ABAP). The R/3-conform file (transfer file) is then imported,
for example, using the Data Transfer Workbench.
Data Transfer Workbench
The Data Transfer Workbench (also DX Workbench, refer to Simplification

Group 1998b) provides transfer programs for the most important business objects.
These include master data for customers, suppliers, personnel, material and bills-
of-materials, and transaction data in the form of orders and sales orders.
Table 4.3: Structure of the transfer file for material master records
Data record Structure File content
BGROO User, client
Session record
Header data for BMMOO Transaction code material number, industry ,
1st group material type, plant ...
Data I BMMHI Basic quantity unjt, material short text, ...
Data 2 BMMH 2 Country, VAT, ...
... ...
Header data for BMMOO see above
2nd group
Data 1 BMMHI see above
Data 2 BMMH2 see above
... ...
The data transfer is made using a transfer file. A transfer file is a sequential text
file (character format) that contains a number of records (rows of the file) having
different types. A data record has the same structure as a data structure from the
ABAP/4 Dictionary. The first field of such a structure contains a number that
identifies the record type.
Each file starts with a so-called session record (structure BGROO, record type 0)
that contains the most important information (refer to Table 4.3) for the data
transfer. The several groups of data records that follow the session record each
define a concrete object (for example, a material master record). Such an object
consists of a header data record (for material master records, for example, the
structure BMMOO, record type I) and a number of specific data records having
different structures (record types 2, 3, ... ) for the further data. Because the position
in the file rather than the record type is used to reconstruct the contents of each
data record, those data records not required for the objects to be transferred can be
omitted from the transfer file.
The type of the data transfer objects (material master, supplier master, ... ) for
which the data transfer is to be organized must be specified at the start of working
with the workbench. The following functions are then available for the user:
• Create an initial (empty) transfer file. This file contains all data records (one
session record, one header data record and all other data records) that can be
used to create a single object in the Rl3 system. The initial file can be used as
template for concrete files.
• Create test data. This function makes it possible to create transfer files from
business objects that have been entered previously in the Rl3 system. These
files can also be used as template (prefilled) for your own transfer files.
• Change afile. The data records for a previously imported (possibly initial) file
can be filled interactively with values, copied and deleted. The files can be
read from both the file system of the presentation system (using SAPGUI) and
from the file system of the application system.
• Copy a file. This function can be used to copy a file from the presentation
system to the application system, etc.
• Data transfer. This, the most important function, is used to transfer the data
records from the file to the Rl3 system. A differentiation is made between two
methods: the batch-input method and the direct-input method. The user has no
influence on the choice of the method used in the workbench. Normally there
is one data transfer program for each data record type that is based on one of
the two methods.
• Create structure definitions for programming languages. This function can be
used to create structure definitions for other programming languages (COBOL,
PLIl, C, RPG), which then can be used to create data transfer programs in the
old system or conversion programs. A structure definition in each required
programming language can be created for each ABAP structure (e.g., BGROO,
BMMOO, BMMHI, ... ).
152 4 Tools
To become familiar with the described functions, it is best to first create a

business object using a standard transaction, then use the Workbench to create a
test file, change this test file, for example, by changing the short text for the
object, and finally reimport this file using the data transfer.
Othertoo/s
Because the Workbench does not provide the appropriate data transfer programs
for all data object types, you can also develop such programs yourself. A
differentiation is made between two basic methods: the batch-input method and
the direct-input method. Because SAP recommends the batch-input method (BI)
for in-house data transfer programs, it is briefly described here.
In the BI method, an ABAP program rather than the user invokes the
transactions and the navigation, and the filling of the screen masks (dynpros, refer
to Section 1.4.7). The associated inputs are not made by the user from the
keyboard but read from a control structure (batch-input session). This method has
the advantage compared with the direct insertion of data in the table structures of
the database in that the same validations apply for the user input as for the data
transfer.
The control structure consists of a number of commands that exactly represent
the interaction steps normally performed by the user: the call of the programs, the
input of values into the fields, moving the cursor, the invocation of function keys
(save, exit, ... ), etc. The same ABAP data structure (BDCDATA) is used for all
actions. Thus, it fulfills at least two functions: the invocation of dynpros and the
filling of fields with values. A batch-input session is now a file that contains a
series of BDCDATA entries that contain the flow for the processing of several
transactions, including the interactions with the dynpros. Thus, the complete data
transfer takes place in three steps:
1. Create a sequential file in the old system.
2. Produce the BDCDATA entries for all required fields per data record, and
those for all data records of the sequential file. These entries are written to the
so-called batch-input session.
3. Execute the batch-input session: The control data for the session are now used
to execute all transactions as required.
The CALL TRANSACTION method should also be mentioned as alternative to

this "classic" BI method. This method omits the intermediate storage of data by
the batch-input session and directly calls the application functions, but, however,
provides less support for the logging of errors and thus for determining faults.
Outlook
SAP provides with the Legacy System Migration Workbench (LSM Workbench) a
tool that should further shorten the processing time for the data transfer. This
provides a so-called Batch-Input Recorder (also called Transaction Recorder) that

records the user's inputs during the processing of a transaction and then produces
a program to create batch-input sessions. After the appropriate adaptation to the
data structures of the old system, this program can be used for the data transfer.
The LSM Workbench has the advantage that it further reduces the programming
effort.
Although the LSM Workbench is not part of the Rl3 system (version 4.0B), it
can be requested free-of-charge from SAP on CD-ROM.
4.11.3 Technologies for Permanent Interfaces
SAP supports various interface technologies, and on the basis of these

technologies, various predefined ("business") interfaces for the coupling
(program-to-program communication) from Rl3 systems amongst each other or
with other application systems. This section introduces the most important
technologies and predefined interfaces.
Analog to the three-level architecture (refer to Section 1.4.1) of the Rl3 system,
interfaces can be realized either to the database layer, to the application layer or to
the presentation layer. However, SAP does not support the direct connection to
database management systems. It is only possible using the application layer or
with tools from the database supplier (e.g., using ODBC interfaces) to access
information in the database. The main problem for this type of coupling is that the
authorization system of the Rl3 system is bypassed, because this can only hinder
the call of ABAP programs but not the importing of tables "that bypass the Rl3
system".
The most important technologies that can be used in the Rl3 system and also
recommended by SAP, are the RFC (Remote Function Call) from SAP and the
OLE (Object Linking and Embedding) from Microsoft. RFC is a technology that
permits the communication between two application systems on different
computers with various operating systems. OLE permits the communication of
two programs at the level of presentation systems.
Remote Function Call (RFC)
The Remote Function Call (RFC) is the basic technology for the invocation of
ABAP subprograms (function modules) between computers. In contrast to a
locally (only on a single computer) executable function module, the RFC requires
another parameter for the function call, namely the destination application system
on which the module is to be executed. The RFC is available in three variants
(refer to Brand 1999):
• as synchronous RFC (sRFC) in which the calling program waits until the
called function module has finished processing and has returned any computed
results,
154 4 Tools
• as asynchronous RFC (aRFC) in which it is only determined whether the

called system is available but does not wait until the end of the execution of
the function module, and
• as transactional RFC (tRFC) that ensures the consistency property (refer to
ACID property, refer to Section 1.3.2) of a series of function calls by
guaranteeing to the calling system either to execute all function modules or, in
the case of an error, not to perform any changes. The transactional RFC is also
performed asynchronously.
To couple Rl3 systems with external systems, SAP provides RFC libraries
(including C++ and Java) that provide the appropriate interfaces (APIs) to
establish connections and to call function modules.
Object Linking and Embedding (OLE)
Object Linking and Embedding (OLE) is Microsoft's technology to create and

manipulate documents (compound documents) on a presentation system (desktop).
OLE can be used in the Rl3 environment to couple programs of a presentation
computer (e.g., MS Word or MS Excel) with the Rl3 system. Two forms of
communications equipment must be differentiated: either the Rl3 system calls a
program (presentation server) on the presentation computer, or a program on the
presentation computer calls function modules of the Rl3 system.
In the first case (Rl3 system as OLE client), special RFCs can be called from
ABAP/4 to start OLE servers (MS Word, MS Excel) and to call commands
supported by the server. These RFCs are received from a SAPGUI and forwarded
as OLE commands to the programs.
In the second case (Rl3 system as OLE server), OLE commands from desktop
applications (e.g., MS Excel) can also be issued to an SAP automation server,
which is also started on the presentation computer. This converts these commands
into Rl3 RFCs.
BAPls and Business Objects
SAP with the term Business Application Programming Interface (BAPI, refer to
SAP 1999b) provides a number of predefined interfaces that distributed systems
can use to access the functionality of the Rl3 system. The BAPIs are based on
SAP's Remote Function Call (RFC) technology.
A BAPI is a predefined RFC-capable interface of a function module, i.e., can
be executed over computer limits, that has been developed with the ABAP/4
Development Workbench. Future BAPIs will also support the loose
(asynchronous) coupling of several Rl3 systems using ALE and the coupling of
external systems using interface standards (e.g., CORBA, DCOM).
Object-orientation aspects are brought into the Rl3 world through encapsulation
(refer to Section 1.3.3) of BAPIs into type definitions of business objects. The
BAPIs (also refer to Figure 4.14) for a business object type, also called methods,
are typically functions to create, find, change and delete concrete business objects
(such as project, customer, supplier).
The information on which business object types are defined in the R/3 system
and which BAPIs exist for a type is maintained in the Business Object Repository
(BOR) and can be viewed in the R/3 system or changed from other systems, e.g. ,
development environments, exported using predefined interfaces, and used for the
automatic creation of interfaces (wrappers) between the BAPIs and other
programming languages (C++, Java, ... ).
Table
AMl
Table
BBB 1
ABAP/4 Data Dictionary
Function Module
BAPI_xx_CREATE
Function Module
BAPI_xx_FIND
Function ModUle
BAPI-",,_ ...
ABAP/ 4 Development Workbench

Rl3-Server
Figure 4.14: Business Objects, BAPIs
Figure 4.15 shows an example for a "getdetailO" BAPI call (computer 2) from
one Java application (computer 1). The Java application determines the detailed
information for the company code 0002 (CompanyCode) in which the primary key
(COMPANYCODEID) is first used to create an objectId and then a company code
object. This empty object serves as representative (proxy) for the ABAP table
entries over which the detailed data can be loaded using the
"getCompanyCodeDetail" method.
Thus, the Business Object Repository, together with the BAPIs, provides an
object-oriented view of the functionality of the R/3 system and also administers
the type definitions of the objects along the component hierarchy of the system. It
also provides a version control for the BAPIs that makes it possible to still
reconstruct and use older interface versions even after program changes.
SAP provides predefined Business Objects and BAPIs that are being extended
continually. In those cases in which the ABAP/4 Development Workbench has
been used to develop customized programs or required BAPIs are not yet available
from SAP, these can also be developed individually. The development guidelines
should be observed to ensure the correct behavior of the components ID
conjunction (e.g., for the transaction processing) with other systems.
156 4 Tools
The methods for the Business Objects can be subdivided into two classes:
instance-dependent and instance-independent classes. The instance-independent
methods can be used to create concrete objects (the name of the BAPIs then ends
with "CREATE") or existing objects sought ("FIND" or "GETLIST'). The
instance-dependent methods can be used to read ("GETDET AIL"), change or
delete concrete objects (instances). The first argument passed to instance-
dependent methods is always the primary key of the object that is as unique
identifier (ObjectId) to reference the correct object.
Comp u ite rl : Java-Application I

Objectld oid • CompanyCode .getEmptyOb jectld () ;
oid .getKey Fiddl.COMPANYCOD&ID") . setStri ngl. 0002 " ) ;
CompanyCod e companyCode = new CornpanyCode (oid) ;
CompanyCodeGetdetail Paramo export • companyCode i'9~td~·t·;':i·i'( )
1 / 0 RPC 0/
Bapi0002_ 2Structure struct • export ,getComp anyC';(leDets rn);
System.out . println(struct.getCompCode( ) + "/' + struct . getCompName () + ... );
COmp u te r2 : ABA P/4-Applicatio n I Call
FUNCTION BAPI_ COMPANYCODEj~~?~~~~f

/ 0 IMPORTING
-
VALUE (COMPANYCOD&ID) LIKE BAPIOOO2 2 - COMP_ CODE
EXPORTING
VALOE (COMPANYCOD&_DETAIL ) LIKE STRUCTDRB BAPIOOO2 2
VALUE (COMPANYCODE_ADDRESS) LIlt!! STRUCTURB BAPIOO02 3
VALOE (RETURN) LIKB STRUCTURB BAPIRETURN 0/
-
BBGIN
SBLECT SINGLE ° PROM TOOl WHBRB BUKRS - COMPANYCODEID.
COMPANYCODE_ DETAIL - COMP_ COD& - T001 - BUKRS .
...
COMPANYCODE_ DETAIL - COMP_ NAME • T001 - B\JTXT,
Figure 4.15: Java-Rl3 communication
4.12 Report Generation
One of the most important points for the implementation of the R/3 system is the
selection or development (Phase 3: Realization, refer to Section 3.3.9) of suitable
report programs (reports). After all, it is not very useful when you manage large
amounts of operative data and so support the work flow, but do have only
inadequate information and monitoring instruments for decision making and for
evaluating your own company situation.
For SAP, and many partner and competitive companies, these requirements are
continually gaining in importance under the term data warehouse. A data
warehouse is a system that provides integrated time-oriented data from various
databases to support the decision-making process and, furthermore, used to find
previously "unknown" but significant data relationships (data mining). The
corresponding software product from SAP is called Business Information
Warehouse (BW) and belongs to the so-called New Dimensions products. To
4.12 Report Generation 157
permit a differentiated data mining independent of the base operative databases,

data warehouses are generally formed from their own databases whose data have
been loaded from operative systems.
However, the first step for the evaluation can already exist in the direct use of
the operative data that the R13 system provides in its tables. SAP provides a
number of tools here. As already indicated in the Implementation Roadmap (refer
to Section 3.3.9), it is important before you start with your own development of
reports to check whether suitable standard reports from SAP are available. Custom
reports should be developed only when this possibility has been excluded. In
addition to the complete custom development on the basis of the ABAP/4
Development Workbench, there is also the possibility to create interactively so-
called ABAP/4 Queries (refer to Section 4.12.2). These require only limited
ABAP/4 knowledge. The Report Writer and Report Painter tools provide other
alternatives for the creation of reports without requiring ABAP/4 knowledge.
Although the Report Painter is easier to operate, it is not as powerful as the Report
Writer.
4.12.1 Standard Reports
The standard reports include the reports that can be found directly in the menus of
the application components of the R13 system. However, if you are not in the
appropriate application component (e.g., Sales), you can invoke the reports for
other components (e.g., Purchasing) only with the direct input of the program
name.
Another possibility to search for and execute reports is provided with the
navigation through a reporting tree (general report selection) that can be found
under the Info Systems/Gen. Report Selection menu item. In this tree, the user can
search for the supplied standard reports, the in-house developed reports, and the
lists already produced by the reports. In addition to this global tree, many
application components contain smaller selection trees tailored to the associated
application area.
The tree for the general report selection, which can also be specifically adapted
to the company requirements, is divided into four levels:
1. application components,
2. work areas,
3. objects (optional), and
4. reports and lists generated by reports.
After invoking a report (from the menu of a component, directly with its name
or using the general report selection), the user must enter the selection criteria that
restricts the search area for his requested data. To avoid re-entering all criteria for
every invocation of a report, so-called report variants can be created in which part
of the selection criteria has been predefined.
158 4 Tools
4.12.2 ABAP/4 Query
The ABAP/4 Query tool is used to link to the contents of the tables of an Rl3
database and to convert these into report lists. This creates special report programs
(queries), which then can be used by the user to create lists. The queries are
created largely menu and window-controlled, and require no or little knowledge of
the ABAP programming language. However, because the created queries build on
the table structures of the Rl3 system, knowledge of the ABAP/4 Dictionary (refer
to Section 1.4.7) is advantageous.
The reports created with the queries can be created in text form on the screen,
and be output graphically using SAPgraphics and in MS Excel. Three different
groups of persons typically work with ABAP Query:
• employees from the user departments who use the system to create new
queries and the resulting lists,
• system administrators who perform the necessary system settings so that the
employees can with the system, and
• translators who translate the text items for the user interface into various
languages.
However, the authorization system must first be used to assign the necessary
user rights for ABAP/4 Query to the associated groups of persons.
System administration
Because the Rl3 system with more than ten thousand (!) tables is normally too
complex for the user department employees, the system administrator can classify
the attributes of the tables and the derived structures (so-called logical databases)
into departmental aspects. Figure 4.16 illustrates this relationship. The base
elements from which the employees later construct queries are the fields (refer to
Section 1.3.2) of the tables from the Rl3 system. It is necessary to structure these
according to departmental aspects and to make them available to the user. The
functional groups defined here represent groups of fields from the tables and/or an
intermediate logical database of the Rl3 system. Logical databases in SAP jargon
are special programs that link tables hierarchically and make them available again
as fields.
Several functional groups then form a functional area. For example, it can be
useful to define a functional area for the employees from Purchasing with fields
from the tables of the Materials Management (materials, orders, etc.). This would
then permit them to create task-oriented individual queries for their specialist area.
An additional authorization system is needed to stop employees from importing
arbitrary tables (e.g., an employee from Purchasing reading the salary tables from
the Human Relations department). Consequently, the system administrator must
define user groups to which he assigns the functional areas needed by the users.
4.12 Report Generation 159
( Functional Area~
o o o I ,
,
,
o o
,,
0
,
I I
(Functional Groups)
I' \
,,>;
ttt
I "
I, ,
Logical
Databases it(\\ "
I '\ '\ \, ,," ,
Tables
itt' ttt 11t1if*
Figure 4.16: Functional areas, functional groups and logical databases
Use of ABAPI4 Query by an employee from the user department
Once the necessary customizing (definition of functional areas and the assignment
to the user groups) has been performed, an employee can now create and execute
queries interactively. In this case, he selects the fields from a functional area to
which he has access and that are required for the query to be created. He can now
use the fields as basis to define three different list types:
• basic lists that represent a sorted and possibly accumulated listing of the
selected fields,
• statistics, which, for example, calculate totals, average values and percentages
for these fields , and
• ranked lists that represent subviews of the basic list and so can emphasize
particular field combinations.
A basic list and several statistics or ranked lists can be defined for each query.
160 4 Tools
4.13 SAP Services
SAP AG provides various services that support the implementation and operation
of the R/3 system. This section provides a summary of these services and
discusses elements such as the Online Service System (aSS).
Because during the implementation of an R/3 system there is still little
experience in the enterprise with the system, these services can be very important,
especially in this phase. In particular, the support services and obviously the
training services must be mentioned here. If the Implementation Assistant (refer to
Section 4.2) is used, this contains an assignment of the services to the associated
project phases of the implementation (SAP 1999a). Whereas some of the services
described in the following sections are part of the purchased R/3 license, other
services must be licensed separately. There are also third-party providers for some
services, e.g., training. Generally, a differentiation can be made between the
consulting services, the training and educational services, and the support services.
4.13.1 Professional Consulting Services
The professional consulting services provides consulting services for which it is

not economical for the company to retain its own employees, because they are
used too infrequently orland require more extensive R/3 expert knowledge. Thus,
these services assume the character of typical outsourcing services.
Conversion Services
Should the structures of the data in an enterprise change significantly during the
operation of the R/3 system, and, for example, the financial accounting requires a
new chart of accounts, it may be necessary to adapt the programs or transfer the
previous data to the new structures (keyword: scheme evolution). The conversion
services provide support for such an adaptation of the R/3 system. The pending
changes can affect typical adaptation such as the apportioning of a controlling area
to "all currencies" to make special customer-specific adaptations or even for the
selection of the procedure for the adaptation.
EarlyWatch Service
The aim of the EarlyWatch Service is at an early stage to recognize and avoid in
the continuous operation any tendency to cause system bottlenecks of the R/3
system. The configurations and system loading of the servers, the database
management systems and the application systems from SAP or partner companies
can be analyzed preventively and regularly using remote connections. The status
4.13 SAP Services 161
report produced during this service contains recommendations for the fine tuning
of the system.
Euro Service
Although the Rl3 system is euro-capable, SAP provides additional training

services, central euro-information services, a remote conversion of the Rl3 system
to the euro, and an euro consulting.
Going/ive Check
The GoingLive Check supplied by SAP should prevent problems arising during
the productive start with many users, e.g., performance problems arising because
of incorrectly set system parameters or poor load distribution between the various
systems. The SAP experts use here a remote connection to check the customer
system.
OS/DB Migration Service
Various modifications are necessary should a change need to be made to the

database management system, the operating system or the computer system used.
The Rl3 licenses associated with the computer and database platforms must also
be changed. The as/DB Migration Service helps with the associated Rl3
conversions.
Remote Archiving Service
The use of the Remote Archiving Service passes to SAP specialists the tasks
required for the archiving of data from the Rl3 system. A regular, specific
archiving improves the hardware usage and can prevent performance problems.
Remote Upgrade Service
The Remote Upgrade Service performs an upgrade or release change in the

customer's Rl3 system by the SAP specialists. This is an outsourcing of the work
steps needed for an upgrade.
Quality assurance/project review
This quality assurance service contains reviews of the project status in the various
project phases each of which takes one to two days. Independent of the project
team, this provides the customer's top management with an objective second
opinion on the implementation progress.
162 4 Tools
Remote consulting and short-notice on-site consulting
This service is appropriate if only short consulting questions arise that possibly
can be solved with remote consulting or on the basis of very short-notice
consulting on-site. The external consultants can supply detailed knowledge for a
special topic.
4.13.2 Education and Training Services
Training service for users
To ensure that the system is used in the most appropriate and effective manner,
seminars are provided for the users of the Rl3 system. SAP supports the
development of in-house seminars at the user site and provides a library with
course material, which can be modified when necessary. The Rl3 Advanced
Training Solutions keyword covers the IDES (International Demonstration and
Education System), various CBT systems (Computer Based Training) and an Rl3
Information Database (InfoDB), etc. The InfoDB provides the customers with
complete and continually updated material for the seminars.
Training service for the project team
Special seminars tailored for the implementation of the Rl3 system are provided
for the members of the project team (refer to Section 3.1.1). There is a broad range
of courses that cover both the Rl3 application components and the Rl3 base
components. Seminars are provided directly by SAP and from SAP partners, and
can also be reserved over SAPNet.
4.13.3 Support Services
Customer Competence Center (CCC) program
The CCC program builds an organizational unit (department, group of employees)

in the customer's company that is to act as the central, competent contact partner
for the implementation and the operation of the Rl3 system. This is a type of on-
site support from SAP. The CCC also provides the help desk. As prerequisite for
the creation of a CCC, the customer signs a value contract (special contractual
form between SAP and the customers based on the contract volume of the Rl3
license).
Problem Solution Service and OSS
The Online Service System (OSS) is primarily an application system at SAP to

which the customers report online their problem cases and from which the SAP
support can return solution suggestions to the customers. It is the central
communication system for the support. Additional important elements are the
access to previously solved problem cases and other information for the operation
of the R/3 system. You can also download error corrections, the so-called Hot
Packages (refer to Section 4.14.3), to update your own system.
Information and Communication Service (SAPNet)
The known functions from OSS are successively made available over the Internet
under SAPNet. The multimedia capabilities and the simple operation of the
Internet using a WWW browser can also be used here. However, the access to the
central problem processing is not yet available.
Quick Sizing Service
The Quick Sizing Service can be used before the first budget planning using the
forecast number of users to make a general estimate for the required hardware
(CPU, hard disks, and memory capacity, etc.). However, detailed estimates should
be made in conjunction with the potential hardware and database partners.
R/3 GoingLive Customer Care Service
The Rl3 GoingLive Customer Care Service provides the customer with a
competent contact partner at SAP who can answer specific questions for the
productive start. If the contact partner cannot directly solve problems, he ensures
that competent help is provided by some other area of SAP. This service is
provided free of charge by SAP.
R/3 New Customer Care Service
The Rl3 New Customer Care Service is provided for new customers during the
first six months of the contract and primarily provides a fixed contact partner at
SAP who accompanies the customers throughout the project and makes any
necessary contacts within SAP.
164 4 Tools
4.13.4 Online Information Services in Detail
Various information items are available online to SAP. The Internet is the
principal medium used. The SAP homepage can be found under http://www.sap-
ag.de or http://www.sap.com.
Online Service System (055)
The SAP process provided to solve problems that occur at the customers consists
of several levels. Although SAP support can be reached using conventional media,
such as the telephone or fax, the Online Service System provides the central
access. The Online Service System can be started from any presentation client
(SAPGUI). The prerequisite is that the customer maintains a network connection
to SAP. The customer can the use OSS to send a problem description or an error
message to SAP.
The message at SAP is processing in various levels. At the first level, simple
questions can be answered immediately, more complex situations are forwarded.
In the last level, a complex problem can be passed to the SAP development team.
The response to the support question is also provided over the OSS. Any
clarification questions from SAP are also handled over the OSS.
To summarize, the OSS provides the following capabilities:
• individual processing of questions,
• use of information from the so-called SAP Knowledge Database that contains
collective information about the Rl3 system,
• check the current status of your own problem reports,
• read Hot News (new features from the Knowledge Database),
• download Hot Packages (collections of error for the Rl3 system),
• requirements from Remote Consulting (billable consulting),
• update of your own customer data,
• open/close a remote connection to SAP over which various other services can
be realized, such as EarlyWatch or Remote Upgrade,
• view training information and order documentation or brochures, and
• registration of modifications to the Rl3 software that the customer itself has
performed.
The SAP license includes the fees required to access the OSS. Every user that
requires direct access to the OSS must request an identification and password from
SAP.
SAPNet
The SAPNet primarily provides the functions of the ass over the Internet
medium. Access can be made using the same identification as for ass. The
Internet allows the use of multimedia components and a more ergonomic user
interface.
As supplementary services to the ass, the SAPNet provides the information
for SAP products and services, and the discussion forums, and self-service
functions (download of descriptions, etc.). The SAPNet can be reached from the
SAP homepage in the Internet or directly using the address http://sapnet.sap.com.
SAP Labs
SAP Labs in Palo Alto (USA) is one of SAP's worldwide development groups.
Innovative developments, such as the ITS Internet Transaction Server for the
provision of Rl3 functionality in the Web, are pursued here. The Internet address
is http://www.saplabs.com.
Simplification Group
The Simplification Group (refer to http://www.saplabs.com/simple) of SAP Labs

is working on the simplification of the implementation process and the use of the
Rl3 system. For example, programs (ABAP programs, BAPI and RFC libraries),
manuals (Made Easy guidebooks), and tools can be obtained using this server.
Because, in addition to detailed descriptions for selected problems (data transfer,
reporting, etc.), the Made Easy Guidebooks also contain sample scenarios that
illustrate working with the Rl3 system using sequences of screenshots, they are of
particular interest for users.
4.14 Additional Tools
4.14.1 Accelerators
In addition to the discussed tools, SAP provides so-called Accelerators that can
further reduce the time for the Rl3 implementation. These accelerators include
• form and presentation templates, and
• various documents to support the processing of the projects.
166 4 Tools
Form and presentation templates
Form templates are normally MS Word or MS Excel documents that are used to
standardize and formalize the communication between the involved roles in the
R/3 implementation project. The templates can be used as the starting point for
enterprise-specific forms. Examples are
• the change request form that can be used to request changes to the project
scope,
• the data transfer form to describe the assignment of data fields of the old
systems to those of the R/3 system,
• the Meeting Agenda and Meeting Report templates to prepare for and
document the project meeting (refer to Section 3.1.2),
• the templates for the weekly and monthly project status reports (refer to
Section 3.1.2), and
• the Business Process Procedure Documents that represent predefined
descriptions of R/3 transactions. They can be used for the definition of
business and test cases, and for the description of the end user's individual
processes (user documentation).
Documents for project support
To support the projects, various types of documents are provided for a range of
topics (Rl3, ASAP, project management, etc.). The following general types are
available:
• how-to documents and white papers, which are guides for the use of the form
and presentation templates, and instructions for the realization of selected
project tasks, and
• Made Easy Guidebooks that describe step-by-step and clearly the transaction
sequences required to perform technical tasks such as printer configuration,
system administration and the setup of the authorization system. The made-
easy guidebook for the SAP Simplification Group (refer to Section 4.13.4) has
already been mentioned at a number of places in this book.
4.14.2 Computing Center Management System
The Computing Center Management System (CCMS) is used for the central
technical administration of the R/3 system. It provides functions such as the
configuration of the operation modes and the logon groups. This section discusses
only these two configuration aspects important for the implementation. The other
functions for monitoring the R/3 systems are not discussed.
4.14 Additional Tools 167
Operation Modes
The definition of operation modes makes it possible to vary the number of work
processes that an R/3 instance is to provide for its logical services (refer to Section
\.3.1). This is useful, for example, when between two work days background
processes for the generation and the printing of reports or to update database
contents are to be performed that require a large amount of computer resources.
Because normally no work is performed at night, the ratio of the work processes
for service at night should be configured differently to that during the day.
Typically more dialog work processes run during the day, whereas at night more
processes for the background processing (batch processes) should be made
available.
An operation mode defines per R/3 instance an assignment of work processes
to services. Operation modes are assigned globally to a 24-hour cycle, namely for
all instances of the R/3 system. As Figure 4.17 shows, an R/3 system can, for
example, consist of three instances (1-1, 1-2, 1-3) for which the two operation
modes (day and night) are defined. It can now be defined for each instance how
many work processes for the specified services (dialog, batch, ... ) are to be
activated during an operation mode. Thus, in the example, the R/3 instances
receive ten dialog and three batch work processes during the day and two or three
dialog and ten or eleven batch work processes at night. One instance - in our case
1-1 - is identified as central instance. It contains the enqueue work process that is
present only once per R/3 system (refer to Section 104.1).
RI3 Instance
Dialog WP: 10 DialogWP: 3

BatchWP: 3 BatchWP: 10
1-1 Posling WP: 3 Posting WP: 3
EnqueueWP: 1 EnqueueWP: I
DialogWP: 10 DialogWP: 2
1·2 Batch WP: 3 BatchWP: 11
PostingWP: 3 Posting WP: 3
EnqueueWP: 0 Enqueue WP: 0
DialogWP: 10 DialogWP: 2
1·3 Balch WP: 3 Balch WP: 11
POSlingWP: 3 Posting WP: 3
Enqueue WP: 0 Enqueue 0
7:00 17:00 7:00 time Of day

day night operation modo
Figure 4.17: Operation modes

168 4 Tools
Logon groups
As explained in Section 1.4.1, several Rl3 application servers (Rl3 instances) can
operate in parallel and access a shared database. The aim during this parallel
operation is to allocate the work load, namely the running dialog and background
processes, as evenly as possible over the Rl3 instances. To ensure that the Rl3
users do not all work with the same instance, there are two measures that can help
provide a good overall performance for the parallel operation of Rl3 instances:
• the automatic assignment of users to Rl3 instances using logon groups, and
• the work-related classification of these logon groups.
Logon groups can be considered as being logical Rl3 instances to which a set of
concrete Rl3 instances are assigned. The user no longer logs on directly using the
SAPGUI to an instance but rather allows the Rl3 system to select the appropriate
instance. To log on to the Rl3 system, an intermediate program (SAPlogon) is
called instead of the SAPGUI. SAPlogon provides the user with a list of logon
groups. Because several Rl3 instances are assigned to one logon group, the Rl3
system searches for the instance that is currently working with the least number of
users or which has the best response time behavior.
The question must now be answered how the logon groups are to be defined or
which Rl3 instances are to be assigned to a logon group. Although it is quite
possible to define just a single logon group from which the server with the least
load is selected for each new logon, SAP recommends to base logon groups on the
application components and their degree of integration with each other. They
recommend, for example, to define logon groups for each of the component
combinations FI/CO and MM/SD. This work-related concentration of the users in
a single logon group means that the cache of the associated instances shows high
hit rates (cache hits) and thus achieves a better overall performance. The buffers
contain often-needed data and programs, which otherwise are stored in the
database, in an intermediate memory of the associated instance and so increase the
access speed for routine tasks.
4.14.3 Release Management
As part of the procedure model (Implementation Roadmap), it was mentioned in

Chapter 3 that an enterprise can adopt various strategies during the planning of the
used Rl3 versions. In general terms, it is possible to differentiate between two
forms of release management
• more risky but functionally advanced, and
• safer but with restricted functionality
SAP offers the users the choice between two different releases, functionality
releases and correction releases. In this way, SAP satisfies the different
4.14 Additional Tools 169
requirements of its customers. Whereas some customers demand to be able to use

functional extensions to the Rl3 systems very early, other customers attach more
value to the used versions meeting higher-quality standards.
Functionality releases are tested by selected SAP customers and can be used
only with approval from SAP. These tests normally discover a number of errors,
which can be corrected with so-called Hot Packages. These packages can be
obtained from OSS or the SAPNet. A correction release is delivered when the
previous functionality release has been tested adequately. Hot Packages are
supplied even during the lifetime of a correction release. These can also be
obtained individually from the Internet or OSS or accumulated as Hot Package
Collection on CD-ROM.
SAP's current time planning concept envisages that functionality releases are
supplied once per year and are supported only for this time period. The
corresponding correction release should be made available within six to eight
months. SAP supports correction releases for approximately three years. A change
to a more recent version is recommended by this time at the latest.
The consideration which versions a company should use should also take into
consideration that a functionality release must first be brought to the level of a
correction release before an upgrade to a new version is possible. Namely, a direct
change between two functionality releases is not possible.
The delivery of both released versions starts with a First Customer Shipment
(FCS). This first version is given to selected customers exclusively to test and
must not be used in the productive operation. Any errors determined during this
phase (four to six weeks) are corrected in a FCS Final Delta Patch. The
corresponding version is subsequently continued as a correction release or as a
functionality release and is released for the productive operation for all or selected
customers.
Special care should be adopted for the release change at Rl3 installations with
industry-specific extensions (Industrial Solutions). SAP provides so-called
Conflict Resolution Transports (CRT) here.
5 Glossary
ABAPI4
ABAP/4 (Advanced Business Application Programming) is a programming
language developed by SAP used to develop the commercial application
components of the Rl3 system. ABAP/4 is a so-called "fourth generation"
(4GL) language.
Activity
a) As part of the implementation ~ roadmap, actIvItIes (ASAP
activities) are understood as being several consecutive tasks that must be
performed during the Rl3 implementation.
b) During the realization of concrete configuration settings in the Rl3
system, the ~customizing transactions are also referred to as activities
(~customizing activities).
Adaptation
The term adaptation is largely used as synonym for ~ customizing.
Application component
The components of a ~business application system are divided into system
and application components. Application components are used to support
business tasks and can be function-related, i.e., tailored to a concrete business
tasks of the enterprise, or inter-functional, i.e., useful for several business
tasks.
ALE is a technology that the SAP offers to establish and operate distributed
applications (e.g., Rl3, Rl2 and non-SAP systems). ALE provides a business
controlled message exchange with consistent data storage using loosely
coupled SAP systems.
Application software product
An application software product is an ~application component that can be
used independently, i.e., without requiring additional application components.
A concrete installation of an application software product on one or more
computers is called an ~application system.
Application system, business
A business application system is an installed application software product used
to support business tasks such as administration, disposition and controlling.
Glossary 171
Business Application Programming Interface (BAPI)

The BAPI technology provides programming interfaces that permit the
standardized access from other application systems to data and functions of the
R13 system.
Business blueprint (document)
A business blueprint is either the second phase in the ~Implementation
Roadmap or can also be understood as being the result of this phase, the
business blueprint document.
Business Framework Architecture
The Business Framework Architecture is an open architecture used to convert
the functionality of the R13 system into an integrated package of modularized
components. The components can be extended whether amongst themselves or
with compatible, i.e., matching components from other manufacturers.
Fundamental SAP technologies to implement this architecture are the
~Business Application Programming Interface (BAPI) and the ~Application
Link Enabling (ALE).
Business object/Business object type
Business objects are objects that in the daily business practice represent things
or facts and have a fundamental role i.e., to provide service, in the
communication between and within businesses. Orders, suppliers and
customers are examples of business objects. Business objects that have similar
properties can be grouped as business object types. Attributes and methods
describe common properties and common capabilities, respectively. In the R13
system, business object types are defined using the tables and function
modules of this system.
Business object model
A business object model describes a set of ~business object types and their
relationships with each other. A differentiation can be made here between the
main part-of and abstraction relationships.
Business process
A business process is defined to be a sequence of interactions between several
objects (persons, machines, application systems) that serve a business goal.
During the realization of the (inter-)actions, additional objects are consumed
(input), produced (output) and transformed (input and output). These objects
can be materials, products, information, and general services. In the context of
the ~R/3 reference model, low-level business processes are also considered to
be generalizations of the transactions used for a commercial task.
Business process model
A business process model is the description of a set of similar ~business
processes. These can be either business processes from the past or those
planned for the future. Business process models are often represented using
graphical diagram languages (e.g., the ~event-driven process chain, EPC).
172 Glossary
Business Process Procedure (document)

A Business Process Procedure (BPP) is considered to be an R/3 transaction. A
Business Process Procedure Document is a standardized description
(completed form in MS Word) of an R/3 transaction. It can be used as model
for the development of concrete end-user procedure descriptions and for
business and test events.
Client
A client is self-contained closed unit with regard to trading, organization and
data within an R/3 system whose data are largely separated from the master,
transaction and customizing data of the other clients.
Configuration
see ~parameterization.
Consistency
Consistency is the logical correctness of the data of a database with regard to
specified conditions (consistency conditions).
Customizing
Customizing is the process of the adaptation (parameterization, configuration,
extension) of a standardized business application system to the concrete
requirements of an enterprise. The enterprise is the customer of the
manufacturer of the ~application system (more exactly, of a ~application
software product). In the restricted sense, customizing is often understood to
be the configuration.
Customizing activity
A customizing activity is an element of the ~ implementation guide and
consists primarily of the ~customizing transaction to be performed and
additional documentation, as well as status and comment functions, that are
used for the project monitoring and documentation.
Customizing data
see ~Transaction data.
Customizing transaction
A customizing transaction is a ~transaction on a ~database that is used for
the adaptation of a ~business application systems to the concrete
requirements of a company. The customizing transaction sets ~customizing
data.
Database
A database is a closed, ~persistent and multi-user "data container" that a
~database management system administers and in which the data for one or
more application systems are stored in a structured form.
Database management system
A database management system is program with a storage and administration
component for the definition and the operation of ~databases. Whereas the
Glossary 173
storage component permits all data and their relationships to be stored, the
administration component provides functions and mechanisms for update and
administration of the data.
Database system
A database system includes a ~database management system with at least one
of the ~databases administered by the system.
Definition-time (of an application system)
The definition-time is time interval within which an application system is
developed or configured (~customizing). In contrast, the ~run-time that
follows the definition-time serves the real use of the application system.
Development System (DEV)
The SAP recommends the installation of three different Rl3 systems for the
Rl3 implementation: for the development, the quality assurance, and the
productive operation. The development system is used to perform the
configuration and the development of system extensions.
Dynpro
A dynpro (dynamic program) is a special ABAP/4 development object that
determines the presentation of the Rl3 system on pages of the ~SAPGUI and
the processing sequence of the screen masks.
Entity / entity type
An entity is a global term that represents all (abstract or concrete) items of our
world of comprehension, irrespective of whether things or actions are
concerned. In the context of ~business application systems, only those entities
referenced from the system are considered. To be generally able to reference
similar entities of an application area, entities with comparable properties are
grouped as entity types. In ~application systems or in their basis ~databases,
the entity types are normally defined in relations/tables with these properties
specified as attributes. The increasingly used object / object type term-pair,
which is often used as synonym to the entity / entity type, emphasizes the
association with object-oriented software technologies.
Event-driven Process Chain (EPC)
The EPC is a language used to graphically describe (diagram language)
~business processes. The EPC language constructs include functions and
events. Functions describe those tasks to be processed as part of the business
processes. Events indicate in which situations these tasks are processed. Events
and functions continually interchange in an EPC diagram. This means that
situations result in the processing of tasks, the results of which produce new
situations, which in tum produce new tasks, etc.
Framework
A framework is a standardized software architecture that uses standardized
interface technology (e.g., CORBA, DCOM) and their predefined interfaces
(e.g., Hot Spots) to build larger applications.
174 Glossary
Help desk
The help desk is (normally) a central access point in an organization
(company, department) which provides employees of the organization with
solutions to their problems or questions concerned with computers, application
systems, network accesses and other technical questions. The employees
inform the help desk their wishes over telephone, e-mail or fax with and then
receive their answers with the same media. If the deficits cannot be rectified
immediately, the help desk ensures a timely response and the later correction,
if necessary from a third-party.
Implementation Guide
The Implementation Guide (IMG) is a hierarchical navigation structure used to
assign all ~customizing activities of the Rl3 system according to logical and
business characteristics. From the IMG, ~customizing transactions can be
started, project documentation written, and project status information updated.
The selection of customizing activities on project-specific guides (project
IMGs) can restrict the Implementation Guide.
Implementation Roadmap
The Implementation Roadmap is ~procedure model recommended by SAP
for the implementation of an Rl3 system. It consists of the phases: project
preparation, ~business blueprint, realization, production preparation, go live,
and support.
Information system, business
A business information system is the complete information processing
subsystem of an enterprise. Because a business information system consists of
both employees of the enterprise and also the ~business application systems,
it is a social-technical system.
International Demonstration and Education System (IDES)
IDES is an Rl3 system for presentation and training purposes. It contains
sample companies with various default settings (customizing data) and also in
which sample master and transaction data have been entered. These data can
be used to perform typical business processes as occur in a ~productive
system.
Master data
see ~transaction data.
Matchcode
A matchcode is specified as an attribute combination of one or more ~entity
types for the values, value sets or intervals of values in order to find the
~primary key of one or more data records of these types on the database.
Milestone
A milestone is an important time during an implementation or development
project that separates two ~phases from each other. The milestone consists of
a date and a set of results (software products, documents, etc.) that must be
Glossary 175
available at this time.

Parameterization
Parameterization is the most important task for the ~customizing of standard
software. Here, before use of the application system, parameters must be set to
selected values at ~definition-time, which then determine the behavior of the
software at ~run-time.
Persistency
Persistency is defined as being the property that manages objects permanently
in a ~database, i.e., at the end of the run-time of an ~application system.
Phase
To be better able to organize the tasks of the ~Implementation Roadmap that
need to be mastered as part of the R/3 implementation, they are grouped into
phases. Phases themselves are built from work packages.
Primary key
A primary key is an attribute or a combination of attributes that uniquely
identifies a tuple / data record of a relation/table.
Procedure model
A procedure model describes, generally applicable if possible, the tasks that
must be performed for the development (or implementation) of an
~application system, and the sequence and dependencies for the realization of
these tasks.
Process hierarchy
The process hierarchy is an assignment scheme that is used at various places in
the R/3 system or in supplementary systems for the structuring of the business
processes that can be processed with the R/3 system.
Productive system
The SAP recommends the installation of three different R/3 systems for the
R/3 implementation: for the development, the quality assurance, and the
productive operation. The productive system is used for the daily productive
operation in the enterprise.
Project plan
A project plan describes the planned procedure (frequently oriented on a ~
procedure model) for a concrete project. In the more restricted sense, a project
plan is understood to be only those tasks with time estimated for the realization
- SAP then designates this as a work plan. In the broader sense, the project
plan also includes the budget and resource planning.
Project scope
The project scope (of an implementation project) is determined by the tasks
and ~business processes that should be supported by the ~application system
that is to be implemented.
176 Glossary
Quality assurance system (QAS)

The SAP recommends the installation of three different R13 systems for the
R13 implementation: for the development, the quality assurance, and the
productive operation. The quality assurance system is used to validate (test)
the results (settings and supplementary developments) of the development. The
settings and the development objects can be passed to the production system
only when this validation has completed successfully.
Run-time (of an application system)
The run-time of an application system is the time interval in which the system
is used in the true sense. In contrast, the ~definition-time is defined as being
the time interval for the development of an application system.
R/3 instance
An R13 system can be built from a number of application servers operating in
parallel. These operate in parallel on independent computers. These application
servers are called R13 instances in the SAP world. Thus, an R13 system
consists of one or more R13 instances. An instance is designated as a central
instance when it provides those services that are required only once per R13
system.
R/3 reference model
The R13 reference model is a catalog of the ~business object types of the R13
system and also typical ~business processes that can be processed with the
R13 system. The business processes are represented graphically as ~event
driven process chains.
SAPGUI
The SAPGUI is the user interface (Graphical User Interface, GUI) of the R13
system. It is installed locally on the presentation computers.
Software reference model
A software reference model is generally the graphical description of an
~application software product that consists of submodels, which in turn
describe sub aspects of the product. The business process or business object
models belong to the sub models of the R/3 reference model.
Transaction
A transaction is a sequence of elementary operations that is atomic, consistent,
isolated and durable (ACID properties). This sequence of operations is either
closed completely or in terminated as a whole and reset. Customizing and
application transactions can differ in a business application system such as R13
system. ~Customizing transactions are used to configure the system (at
~definition-time) and application transactions of the actual use of the system
in the application area (at ~run-time). A transaction code uniquely identifies
transactions in the R13 system. This code was used in earlier R13 versions for
the direct invocation of a transaction. Nowadays, it is normally required only
for the designation during the development or the customizing.
Glossary 177
Transaction data
The data of a ~business (standard) application system can be subdivided into
three types of data: customizing, master and transaction. Customizing data
(control data) are the data items entered as part of the ~adaptation and which
determine the structure and the behavior of a concrete ~application system.
Because a configuration must normally exist before a system can be used,
these data must be entered first. Master data represent the data that typically
change only long-term (one or more years). These include data about the
business partners (e.g., customers, suppliers) and product data. Transaction
data are data that result during the daily business operations and have a
relatively short period of usage (normally not longer than one year). These data
include customer contracts, orders and account entries.
Transaction code
see ~transaction.
Web browser
Web browsers are application systems with graphical user interfaces that
permit the navigation in the W orId Wide Web (WWW) with a click of the
mouse. The user interface consists of extended hypertext pages based on the
HTML language. Web browsers can also be used locally on a computer, e.g.,
as a help system.
Work package
Work packages are technically related activities that the ~Implementation
Roadmap recommends to be performed as part of an Rl3 implementation.
6 Abbreviations
4GL Fourth Generation Language

ABAP/4 Advanced Business Application
Programming/4th Generation
ACID Atomicity, Consistency, Isolation, Durability
ALE Application Link Enabling
ARIS Architecture Integrated Information Systems
ASAP AcceleratedSAP
BAPI Business Application Programming Interface
BOR Business Object Repository
BPML Business Process Master List
BPP Business Process Procedure
BW Business Information Warehouse
CAD Computer Aided Design
CASE Computer Aided Software Engineering
CATT Computer Aided Testtool
CCC Customer Competence Center
CCMS Computing Center Management System
CORBA Common Object Request Broker Architecture
CTO Change and Transport Organizer
DBMS Database Management System
DC OM Distributed Common Object Model
DIN Deutsches Institut fUr Normung (German standards institute)
EDI Electronic Data Interchange
EDIFACT EDI for Administration, Commerce and Transport
EPC Event-driven Process Chain
FCS First Customer Shipment
GUI Graphical User Interface
HTML Hypertext Markup Language
lAC Internet Application Components
IDES International Demonstration and Education System
IDoc Intermediate Document
IMG Implementation Guide
ISDN Integrated Services Digital Network
ISO International Standards Organization
ISV Independent Software Vendors
ITS Internet Transaction Server
LAN Local Area Network
ODBC Open Database Connectivity

Glossary 179
OLAP On-Line Analytical Processing

OLE Object Linking and Embedding
OLTP On-Line Transactional Processing
OSS Online Service System
Q&Adb Question & Answer Database
RFC Remote Function Call
SAPGUI SAP Graphical User Interface
SERM Structured Entity Relationship Model
SQL Structured Query Language
STEP International Standard for the Computer-Interpretable
Representation and Exchange of Product Data
UML Unified Modeling Language
EPA Enterprise Process Area
WAN Wide Area Network
WWW World Wide Web
XML Extensible Markup Language
7 References
Abinava, S., Buch, A, Cattior, E., Chilant, M., El-Rafei, S., Krause, A, Miiller, W. and
Zulian, F. (1998): San Francisco Concepts & Facilities (DOCNUM SG24-2157-
00). IBM (ed.), Redbook. IBM, Rochester.
Brand, H. (1999): SAP Rl3 Implementation With ASAP: The Official SAP Guide. Sybex,
Alameda et al.
Buck-Emden, R. and Galimow, J. (1996): SAP Rl3 System: A Client/Server Technology.
Addison-Wesley-Longmann, Harlow et al.
Buxmann, P. and Konig, W. (2000): Inter-Organizational Cooperation with SAP-Systems -
Perspectives on Logistics and Service Management. P. Mertens and P. Zencke
(eds), SAP Excellence. Springer-Verlag, Berlin et al.
Ferstl, o. K. and Sinz, E. 1. (1998): Grundlagen der Wirtschaftsinformatik. Vol. 1 of 2.
Oldenbourg Verlag, Wien.
Hufgard, A (1994): Betriebswirtschaftliche Softwarebibliotheken und Adaption. Vahlen,
Miinchen.
Knolmayer, G., Mertens, P. and Zeier, A (2000): Supply Chain Management Based on
SAP-Systems. Order Processing in Manufacturing Companies. P. Mertens and P.
Zencke (eds), SAP Excellence. Springer-Verlag, Berlin et al.
Meier, A (1998): Relationale Datenbanken. Springer-Verlag, Berlin et al.
Mertens, P. (1997): Integrierte Informationsverarbeitung, Band 1: Administrations- und
Dispositionssysteme in der Industrie. 11. Edition. Gabler, Wiesbaden.
SAP (1998): The Rl3 System Landscape. SAP Technology, Inc.
SAP (1999a): AcceleratedSAP FOR 4.0B. Release 4.0B (CD). SAP AG.
SAP (1999b): BAPI Programming Guide. SAP AG.
Scheer, A-W. (1999a): ARIS - Business Process Frameworks. Third Edition. Springer,
Berlin et al.
Scheer, A-W. (1999b): ARIS - Business Process Modeling. Second Edition. Springer,
Berlin et al.
Simplification Group (1998a): Rl3-System: Fundamentals of Reporting. SAP Labs, Inc.
Simplification Group (1998b): Rl3-System: Initial Data Transfer Made Easy. SAP Labs,
Inc.
Glossary 181
Simplification Group (1998c): SAP Rl3 Authorization Made Easy. SAP Labs, Inc.
Thome, R. and Hufgard, A. (1996): Continous System Engineering. Entdeckung der
Standardsoftware als Organisator. Vogel-Verlag, Wiirzburg.
W6he, G. (1996): Einfohrung in die Allgemeine Betriebswirtschajtslehre. Vahlen,
Miinchen.
8 Index
of the ITS 31
A
software 12
ABAP/4 20, 170 three-layer 16
Development Workbench 40,78, Architecture of Integrated
102, 142, 154 Information Systems (ARIS) 7
Dictionary 42,143,151,158 ARIS Toolset 137
Editor 42 archiving 106
function module 29 attribute 18, 150
Query of an object type definition 29
report 158 authorization 87, 143
Repository 41 concept 104
ABAP/4 Query field 143
system administration 158 object 143
AcceleratedSAP (ASAP) 64, 74, 76 organizational structure for 146
CD-ROM 69, 76, 113, 116 profile 144
Global 65 system 142, 153
Accelerator 165 validation 143
ACID property 15,19, 154
B
activity 64, 76, 104, 135, 145, 170
group 105, 143, 145 backup strategy 87, 110
adaptation 57, 170 baseline scope 92
analysis 52, 54, 65, 83 behavior 21
application blueprint form 90, 124
area 14 Business Application Programming
component 6, 170 Interface (BAPI) 28,91,154,171
hierarchy 41 business application system 170
server 14 business area 44
software product 1, 170 business blueprint 171 refer to
system interface 148 phase
system, business 1 business blueprint (document) 92,
Application Link Enabling (ALE) 171
26,38,149,170 Business Framework Architecture
architecture 12 refer to Framework
client/server 12 Business Information Warehouse
client/server of the R13 system 23 (BW) 156
enterprise 2 Business Navigator 130
four-layer 16 business object 28, 171
object-oriented framework 21 model 49,130,171
Index 183
type 48,49,130,149,171 company code 44

Business Object Repository (BOR) component 6
28, 155 cross-function 37
business process 2, 6, 171 function-related 33
definition 90 hierarchy 132
model 2, 124, 17l of the R/3 system 32
modeling 78, 135 system 38
owner 75 componentization 32
questions 90 components
team 72 hierarchy 33
team lead 74 Computer Aided Design (CAD) 37
tools for the modeling 135 Computer Aided Software
Business Process Master List Engineering (CASE) 65
(BPML) 97, 107, 125,127 Computer Aided Testtool (CATT)
Business Process Procedure (BPP) 38
97,172 Computing Center Management
Business Process Procedure System (CCMS) 88, 166
Document 94, 107, 172 Concept Check Tool 66, 94, 129
configuration 57, 172
C
baseline 96
case 97 final 96
CCC program refer to Customer in the narrow sense 97
Competence Center connector refer to logical operator
Change and Transport Organizer consistency 172
(CTO) 41,138,141 consulting services 160
change management 85 controlling area 45
change management team 76 Conversion Services 160
change request 142 Cross Application Components
chart of accounts 44 (CA) 37
client 43, 80, 172 Customer Competence Center
customizing/development (CCC) 96
(CUST) 80 customer project manager 74
customizing-master (MAST) 81 customizing 4,10,28,55,138,172
development (DEVT) 80 activity 58, 172
EarlyWatchService (SAPE) 80 data 28, 172
independence 141 request 142
productive (PROD) 81 transaction 40, 172
quality assurance (QTST) 81 cut-over 95, 111
reference (SAPR) 80 planning 110
sample (SAPS) 80
D
sandbox (SAND) 80
test (TEST) 81 Data Browser 42
training (TRNG) 81 data conversion program 10 1
Common Object Request Broker data model 18
Architecture (CORBA) 21 Data Modeler 42, 134
company 26,44, 129 data transfer 92, 148
184 Index
program 149 entity relationship model, structured

workbench 149,150 (SAP-SERM) 42
data warehouse 156 entity type 9, 42, 49, 173
database 14, 17, 172 euro service 161
logical 158 event 8
database management system linkage 9
(DBMS) 172 Extensible Markup Language
database scheme 18, 42, 49 (XML) 16
database server 14
F
database system 17,25, 173
database system (DBMS) 2, 17 feasibility study 54
relational 17, 38, 39 final preparation refer to phase
database table First Customer Shipment (FCS) 169
display 42 FCS Final Delta Patch 169
definition-time 57,119,128,173 flow logic 41,43
design 52 project refer to project flow logic
development 52 foreign key 19
class 41 form 104
system (DEV) 55 framework 22, 173
Development System (DEV) 173 Framework
DIN (German Standards Institute) Business 28, 171
90 front-end network 17
Distributed Common Object Model function 8
(DC OM) 21 Function Builder 43
distribution channel 46 function linkage 9
division 45 function module refer to ABAP/4
documentation 107 function module
developer 75 function variant 48
dynamic program 25, 173
G
dynpro refer to dynamic program
go live and support refer to Phase
E
going-live check 161
EarlyWatch Services 160 graphical user interface (GU!) 14
electronic commerce 5
H
Electronic Data Interchange (EDI)
4,16,28 help desk 95, 174
Electronic Data Interchange for employee 75
Administration, Commerce and Hot Package 169
Transport (EDIFACT) 4 Collection 169
end-user procedure documentation Hypertext Markup Language
107 (HTML) 30
enterprise plan 2
enterprise process area (EPA) 72, I
121, 123, 131 Implementation Assistant 64, 114
document 79, 92 Implementation Guide (IMG) 40,
entity 173 88,138,174
Index 185
company 135, 139 Menu Painter 43

company IMG 88 milestone 56,60,83,92,174
project 127, 135, 138, 139 module 6
project IMG 84, 88 MS Project 116
project-IMG
views 139
o
SAP Reference 139 Object Linking and Embedding
Implementation Roadmap 64, 69, (OLE) 153, 154
174 On-Line Analytical Processing
Independent Software Vendor (ISV) (OLAP) 103
22 Online Service System (OSS) 163,
Industry Solution 33 164
information processing, integrated 4 On-Line Transactional Processing
information system, business 1, 52, (OLTP) 103
101,135,137,174 Open Database Connectivity
Integrated Services Digital Network (ODBC) 153
(ISDN) 83 operation 52
Interface Adviser 149 operation mode 24
interface program 101 operation mode 167
Intermediate Document (IDoc) 28 organization structure 88
International Demonstration and project refer to project
Education System (IDES) 92, organization
162, 174 organization unit 2,9,43,92, 129,
International Standards Organization 130, 145, 146
(ISO) 4 organization unit type 9,43,92, 129
Internet organizational structure 2, 23, 79,
application component 31 88,89
Transaction Server (ITS) 30 organizational structure of the R/3
Issues Database 78, 95, 115, 126 system 43
OSIDB migration service 161
L
p
load balancing 13
logon 25 parameterization 4,28,57,65, 129,
local area networks (LAN) 17 175
logical operator 8 persistence 21
logon group 25,168 persistence layer 14
persistency 175
M
persistent 14
Made Easy Guidebook 105, 165, phase 53, 64, 175
166 business blueprint 69,83
mapping 10 final preparation 69, 108
master data 28,90, 174 go live and support 69, 111
matchcode 174 project preparation 69,70
media fragmentation 101 realization 69, 94
member of the business process phase model 60
team 75 extended 62
186 Index
the Rl3-implementation 63 in the final preparation 108

planned concept 47,54,66 in the realization 95
plant 45 management system 67, 116
power user 75 organizational structure 72
presentation client 14 plan 56, 116, 175
primary key 19,175 adaptation 118
procedure create 71
evolutionary 62 template for 64
incremental 62, 79, 96 preparation refer to phase
iterative 62 procedures refer to project
participative 62 standards
sequential 79 process structure 57, 67
procedure model 60, 175 project organization 52
for the application system resource plan 77
development 51 review 161
process 48 standards 77
chain, event-driven (EPC) 7 team 72
EPC diagram 46, 91 work plan 76
scenario-EPC 131 project scope 175
chain, event-driven (EPC) 173 project sponsor 73
group 48, 131 purchasing organization 45
guide 48
hierarchy 121,130,175 Q
path 9 quality
structure 146 assurance system (QAS) 55, 86,
structure 58 100, 176
structure documentation of 135 auditor 74
symbol 48 check 111
variant 48 check 83
processing logic 41 quality check 94, 108
productive system (PRO) 55, 175 Question and Answer Database
profile generator 144 (Q&Adb) 78,119
project Quick Sizing Service 163
plan
for the Rl3 implementation R
117 Rl3 GoingLive Customer Care
budget plan 77 Service 163
charter 71 Rl3 instance 23, 176
documentation in the IMG 140 central 24
employee role in 73, 117 Rl3 New Customer Care Service
end 112 163
flow logic 52, 57 Rl3 process model 48
kickoff 82 Rl3 reference model 10, 40, 46, 78,
management 91,130,176
in the business blueprint phase navigation in the 130
84 realization 52 refer to phase
Index 187
redlining 10 SAP Labs 165

refer to Question and Answer SAP project manager 74
Database 78 SAP Services 160
relation 18 SAPNet 163,165
release scenario process refer to process
correction 168 chain, event-driven (EPC)
functionality 168 Screen Painter 42
management 168 selection criterion 157
Remote Archiving Service 161 server network 17
remote consulting 162 service 160
Remote Function Call (RFC) 29, logical 24
153 service, logical
asynchronous RFC 154 background 24
synchronous RFC 153 dialog 24
transactional RFC 154 enqueue 24
Remote Upgrade Service 161 update 24
report 91 Simplification Group 165
development 103 software development process refer
generation 156 to procedure model
list 27,91 software reference model 10, 46,
report variant 157 66, 176
selection, general 157 standard
standard 91, 103 de facto 4
standard report 157 de jure 4
Web Reporting 32 Standard for the Computer-
Report Painter 157 Interpretable Representation and
Report Writer 157 Exchange of Product Data (STEP)
reporting refe r to report 4
reporting system 35,89,91, 103 standard software product 3
repository 68 development process 51
browser 41 state 8
Infosystem 41 steering committee 72
requirement storage location 45
requirements definition 54 Structure Modeler 90, 128
technical 82 Structured Query Language (SQL)
run-time 41,43,57,128,143,176 18
summary questions for the company
S
120
sales area 46 support
sales organization 46 in productive operation 112
SAP application consultant 74 planning 110
SAP consulting manager 74 support services 162
SAP consulting manager for system administration 87, 100, 110
technology 74 system enhancements 102
SAP Graphical User Interface system environment
(SAPGUI) 25, 176 develop 85
188 Index
system landscape 80, 129 u

system management 108, 109
Unified Modeling Language (UML)
T 65
update 56,59, 78, 79
table 18, 153
upgrade 56,59,64,79
internal 41
user master record 143
reference 29
user's manual 100
task 64
task flow 79 v
team member 72
valuation area 45
technical team lead 75
value chain 48
test 52,97
value range 18, 143
integration 106
view
tool 113
business-process-oriented 12
analysis 65
control 7
business process modeling 135
data 7
cross-function 67
function 7
design 66
functional 12
function-related 65
organization 7
implementation 67
physical 12
R/3 implementation 113
process 7
training
service 8
of the project team 85, 96
software design 12
service for the project team 162
system process 12
service for user 162
user 108 w
training material 107
Web browser 16, 177
transaction 19, 176
wide area networks (WAN) 17
transaction code 177
work package 64, 177
transaction data 28, 94, 111, 177
work process 24
transfer file 151
workbench request 142
transport 81
workflow description 94
tuple 18
World Wide Web (WWW) 177

(SAP Excellence) Professor Dr. Hans-Jürgen Appelrath, Dipl.-Inform. Jörg Ritter (Auth.) - SAP R - 3 Implementation - Methods and Tools-Springer-Verlag Berlin Heidelberg (2000)

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

(SAP Excellence) Professor Dr. Hans-Jürgen Appelrath, Dipl.-Inform. Jörg Ritter (Auth.) - SAP R - 3 Implementation - Methods and Tools-Springer-Verlag Berlin Heidelberg (2000)

Загружено:

Авторское право:

Доступные форматы

SAP Excellence

Prof. Dr. Dr. h.c. Peter Mertens,

Dr. Peter Zen eke,

SAP R/3 Implementation

Dipl.-Inform. Jorg Ritter

Manufacturers of standard business software products, such as SAP AG, promise

accompanying literature for lectures at universities and polytechnics, in particular

Entwicklungsinstitut fUr Inforrnatik-Werkzeuge und -Systeme). They all provided

Prof. Dr. Hans-Jiirgen Appelrath Dipl.-Inforrn. Jorg Ritter

1 BUSINESS APPLICATION SYSTEMS ..................................................... 1

2.3.2 Additional Roadmaps..................................................................... 65

4.2 IMPLEMENTATION ASSISTANT .............................................................. 114

4.14.3 Release Management ................................................................... 168

6 ABBREVIATIONS ................................................................................... 178

7 REFERENCES .......................................................................................... 180

8 INDEX ........................................................................................................ 182

In this section we assume the "enterprise global system", assign business

Task Ullimate Unit Of Responsibility Task

Business Clerk, Controlling System

Figure 1.1: Company subsystems (Ferstl and Sinz 1998,4)

1.1.1 Enterprise Architecture

Nowadays, business application systems represent a central and strategically

15\ Model Level

2nd Model Level

3rd Model Level

Figure 1.2: Enterprise architecture (Ferstl and Sinz 1998, 177)

1.1.2 Standard Software

Software products can be classified into low-level (e.g., operating systems,

1.1.3 Integration of Software

automatic update of permanently aggregated and derived data. Because the

1.2 Tasks and Business Processes

• Monitoring systems help department and management staff recognize

To keep complex application systems understandable despite their increasing

We group the standard software components into

Each function-related and cross-function component supports a number of

Type/tusk Production Pu rc hasi ng/wal e- Sales Personnel

1.2.2 Business Processes

Figure 1,3: Schematic view of the ARIS architecture

Figure 1.4: Descriptive elements of the EPC model

Software reference models

Because the volume of all business processes supported by an application software

Figure 1.5: EPC example

1.3.1 Multi-level Client/Server Architectures

1 : Query 4: Respo nse

Figure 1.6: Client/server model

The assignment of client and server processes to computer systems can be

Client Computer 1 Client Computer 2

lClient Process J [Client process] Client process)

Figure 1.7: Assignment of CIS processes to computer systems

Figure 1.8: Three-layer architectures

In accordance with the third variant, department motivated, horizontally

The integration of application systems for several companies provides another

Figure 1.9: EDI coupling of application systems

Figure 1.10: Four-layer architecture

Because software systems are generally installed distributed over various

1.3.2 Relational Database Systems

• backup capabilities are provided for the data

The application-independence and the consistency of the databases is ensured,

Table: Department Table: Employee

The DBMS monitors whether the database is always in a consistent state,

1.3.3 Object-oriented Architectures

In this section we briefly describe new object-oriented software technologies for

In particular, the integration of structure and behavior permits objects to be