sap_r3_primer_white_paper-1[1].0.pdf

SAP R/3: The Basics

What a Systems Engineer Needs to Know About SAP

R/3

White Paper

Systems Engineering, Architecture and Test (SEAT)

Application Management Services

IBM Global Services

This paper provides an elementary

overview of SAP R/3. The knowledge in this

paper should allow the System Engineer to

be able to ask the intelligent questions and

identify gaps and issues in requirements,

interfaces and operational aspects of the

project.

Published: September 2007 – Rel. 1.0

Contacts:

Sergey Kucherov/Chicago/IBM +1(630) 689-4194

Ayman Nassar/Baltimore/IBM +1(443) 393-1075

SAP R/3 for System Engineers

White paper 2

Executive Summary

Often Systems Engineers are staffed on projects which comprise of technologies and products

they are not familiar with. Basic background knowledge about the various technologies and

business practices and processes related to a project could add tremendous value to the

systems engineering service delivery.

This paper introduces SAP R/3 to the system engineer. A discussion about the architecture of

the product is provided as well as the various configuration options. The reader is then

introduced to key areas when dealing with projects involving SAP R/3. An overview of SAP R/3

interfaces and areas to focus on when developing requirements. A few examples of business

and system requirements are discussed and how using the knowledge in this primer they

could be further enhanced to provide a higher systems engineering value-proposition.

A discussion of SAP R/3 operations is included in the paper to give the systems engineer the

feel for the operational model of a system comprising of SAP R/3.

The purpose of this white paper is not to train systems engineers in SAP, rather the purpose is

to provide basic foundational information on SAP. The system engineer shall be able to

understand SAP’s behavior, operations and architecture as a system, and its interaction with

other systems.


White paper 3

Table of Contents

Executive Summary ...................................................................................................... 2

Background.................................................................................................................. 5

SAP R/3 Function .......................................................................................................... 5 Functional System Context ......................................................................................... 7 R/3 Customization..................................................................................................... 8

SAP R/3 Architecture ..................................................................................................... 9 Application Architecture ............................................................................................. 9 Integration Architecture ........................................................................................... 12 Interfaces .............................................................................................................. 13

SAP R/3 Operations..................................................................................................... 15 Configuration and Implementation ............................................................................ 15 Data Flows Model .................................................................................................... 16

SAP R/3 Projects and System Engineering...................................................................... 16 Overview ............................................................................................................... 16 SAP R/3 Requirements and Design ............................................................................ 17 SAP R/3 Testing and Deployment .............................................................................. 18

Acronyms and Glossary ............................................................................................... 19

Bibliography and References ........................................................................................ 21

About Systems Engineering, Architecture and Test.......................................................... 22 Contact the Authors................................................................................................. 22 Contact the Systems Engineering and Architecture Group ............................................ 22

Appendix A: SAP Modules ............................................................................................ 23


White paper 4

List of Figures Figure 1 SAP R/3 system functional diagram ·················································································· 7 Figure 2: SAP R/3 Architecture ······································································································ 10 Figure 3 R/3 database layer interface [6]. ······················································································ 12 Figure 4: Typical Enterprise Architecture with SAP R/3 ································································· 12 Figure 5: SAP R/3 Outbound Interfaces························································································· 14 Figure 6: SAP R/3 Inbound Interfaces ··························································································· 14


White paper 5

IBM Global Services

Application Services

SAP R/3: A Primer for Systems Engineers

Function, Architecture and Operations

Background

R/3 is an enterprise resource planning (ERP) product developed by SAP. SAP is a German software developer and the world’s largest ERP solution provider.

The name SAP is composed by initials of German title “Systeme, Andwendungen, and Produkte in Der Datenverarbeitung”, which translates into English as “Systems, Applications, Products in Data Processing”. Company SAP AG was established in Germany in 1972.

With the advent of distributed client-server computing SAP AG brought out a client-server version of SAP R/3 that was manageable on multiple platforms and operating systems, such as Windows and UNIX since 1999.

SAP and Oracle are the World’s top ERP product providers. Oracle has become a tough competitor to SAP especially after the acquisition of PeopleSoft which acquired JD Edwards.

IBM has a strategic alliance with SAP and sells SAP’s products as a component of IBM’s delivery solutions [1, 8]. IBM also uses SAP internally in various business functions across IBM.

SAP R/3 Function

SAP R/3 provides companies with diverse out-of-box business solutions. R/3 provides clients with highly automated business processes optimized for a particular industry. Its flexible functional architecture allows clients to customize those processes. Many customers overuse this ability by implementing heavily-customized custom business solutions based on SAP R/3 functional platform.

SAP R/3 applications are grouped by modules. Each module handles specific business tasks on its own, but is linked to the others where applicable. For instance, an


White paper 6

invoice from the Billing transaction of Sales & Distribution will pass through to accounting, where it will appear in accounts receivable and cost of goods sold. The main modules are:

Financials

� FI – Financial Accounting

� CO – Controlling

� AM – Asset Management

� PS – Project Systems

Common Systems

� WF – Workflow

� IS – Industry Solutions

Logistics

� PM – Plant Maintenance

� QM – Quality Management

� PP – Production Planning

� MM – Materials Management

� SD – Sales and Distribution

HR Human Resources

� HR-PA Personnel Administration

� HR-PD Personnel Development

� HR-RC Recruitment

SAP has typically focused on best practice methodologies for driving its software processes, but has more recently expanded into vertical markets. In these situations, SAP produces Industry Specific (IS) specialized modules geared toward a particular market segment, such as utilities or retail.

SAP is based on the concept of integration, achieved through the usage of modules. Each module effectively manages a functional area of the organization.

Using SAP often requires the payment of a considerable license fee, as the customers have effectively outsourced various business software development tasks to SAP.

The SAP Business Framework is a family of SAP and non-SAP products. It is an open, integrated, component-based enterprise business application solution for companies of any size in any industry. Business Framework provides flexibility in setting up enterprise-critical distributed IT systems using independent components. The R/3 System is an evolving family of application components that can be combined into an integrated, continuously maintainable network solution regardless of the release of the components. Business Framework is an open design, allowing integration of components from third-party vendors.


White paper 7

Functional System Context

The Figure 1 shows functional system context of SAP R/3. Users access R/3 applications through numerous transaction codes. Each transaction associated with a sequence of screens (dynpros) linked by business and data processing logic.

SAP R/3 interfaces and flow control enables many automated processes initiated by receiving document from the upstream. Both manually and automatically initiated transactions results in updating internal data and/or submitting downstream documents.

Figure 1 SAP R/3 system functional diagram

The importance of the functional context derives from the fact that many SAP experts operate in this environment rather than on a lower software level. To understand connection between functional and physical architecture see next chapter.


White paper 8

R/3 Customization

System Configuration

R/3 functional architecture provides clients with variety of ways to configure the system in order to satisfy specific client requirements. The configuration of each module requires deep expertise in the both R/3 functionality and the business area.

All configuration changes can be made through SAP modules and transactions. Actual changes will be created as data in configuration and master data tables.

Programming

There are several ways to extend R/3 functionality using custom development. Client may create custom reports. Reports are the ways to present existing R/3 data on screen and printer. Report development is the simplest type of customization.

Another type of development is associated with interfaces. Inbound and outbound data may contain special processing instructions that cannot be processed by standard R/3 modules. Such changes can be implemented in variety of ways including “user exit”.

User exits are reserved function calls developed by SAP and embedded to R/3 modules. The call is usually made to an empty routine that can be modified by R/3 client. User exit can pre-process or post-process data for individual SAP transaction.

Finally, client may decide to develop completely new set of transactions or even whole new module. This is most expensive type of development.

Change management

Usual SAP R/3 landscape includes at least three systems – production, testing, and development. Only the last one has developer access turned on to avoid any change of making changes directly to testing or production system.

Any change to SAP R/3 system is associated with a Transport Request. It includes not only changes in source code or screen design, but also changes to configuration data. Once developer finished making changes and tested it in the development environment, one can “release” the Transport Request. The released request is exported to transport directory and became available for administrator to transport it to staging system.

Once released, a transport cannot be added to or changed. Some transports must be imported in sequence: second and subsequent requests depend on their predecessors.

Transport requests contain information about the changes associated with the request. Only authorized personnel can move transport request from one system to another. He may do it immediately, or wait for the next scheduled release time frame.


White paper 9

One SAP R/3 System can be logically separated by clients. In SAP terms “client” is a logical area that separates data in SAP system. Most of R/3 tables have client code as a first key field. This allows the usage of the same tables to store data related to several clients. There are two types of changes: client dependent and client independent. Changes to client-independent data will affect all clients on the system. All changes to SAP programs are client-independent.

If changes to an SAP landscape are not managed carefully, a real risk exists that the production system may be damaged. There is no mechanism in SAP that relates these technical transport requests to a particular business requirement. Keeping track of all the approvals required, and given, for all transports becomes very challenging. Inadequate audit trails make it difficult to discover, after the event, how and why a particular problem occurred.

SAP R/3 Architecture

Application Architecture

R/3 is a typical example of classic three-tier architecture (see Figure 2). Three layers called presentation, application and database.

Presentation layer

The presentation layer is a Windows application called SAP GUI. It interacts with SAP server in a way similar to a mainframe terminal. Modern SAP GUI support 20 different languages and provides user with advanced features like off-line code editing and integration with Microsoft Office. Users can also access R/3 using thin or web client through the internet layer.


White paper 10

Figure 2: SAP R/3 Architecture

The SAP Internet Transaction Server (ITS) converts R/3 screens into HTML format making it possible to access SAP applications using web client. ITS is a part of the application layer, but it usually hosted on a separate server.

Application layer

An application layer houses SAP applications that provide business logic for R/3 modules, development and administrative functions. Additionally, the application layer provides background processing, printing and process request management. All applications are developed in Advanced Business Application Programming (ABAP) – a Cobol-like language with embedded database and security features. The core of the application layer is a high-performance ABAP interpreter that executes thousands lines of code per second to provide SAP users with a unique ERP experience.

The application layer comprises of SAP modules, a session manager, database connector and an interpreter of ABAP. Application layer does not have data storage. Every piece of data including screen layout and ABAP code is stored in the database layer. Application layer maintains work processes, in addition to background processing, printing and process request management.

When a request from Presentation Server first comes to the Application Server, it directs the request to the dispatcher. The dispatcher, which is the Central process of


White paper 11

the SAP Web Application Server, manages the resources for the applications written in ABAP in coordination with the respective operating system. The main tasks of the ABAP dispatcher include the distribution of the transaction load to work processes, the integration of the presentation layer and the organization of communication transaction. The requests are first saved in the queue by the dispatcher and then processed according to the principle of “first-in, first-out.” The dispatcher distributed the request one after another to the available work processes. A work process handles one request at a time. Data is actually processed in the work process, although the user who created the request using the SAP GUI is not always assigned the same work process [4].

The application servers can run on Windows NT systems, major UNIX operating systems, and AS/400 systems. A number of different application servers can be connected in a network, distributed geographically.

SAP BASIS

SAP uses a middleware known as BASIS. BASIS stands for a Business Application Software Integrated Solution. Simply, BASIS is the administration of the SAP R/3 system. It includes a RDBMS, GUI, and client server architecture. Beyond the interface aspect of BASIS, it also includes such components as a data dictionary and user and system administration, and allows the application to run on different hardware and software systems.

Database layer

The heart of SAP R/3 is formed by approximately 15,000 database tables that hold transactional and configuration data, screens, reports, and source code. SAP license does not allow direct access to R/3 databases. All data modifications should be done by ABAP application from application layer. Database layer provides ABAP program with virtual database access that automatically handles locks, transactions, indexing and backup. Also all SAP tables include special fields that provide R/3 applications with additional logical virtualization (see section TBD). The database layer is illustrated in further detail in Figure 3.

R/3 applications have ability to access SAP database directly without using internal data dictionary and work processes. This mechanism called Native-SQL access and is implemented by ABAP routine EXEC SQL and provides certain advantages. Using Native-SQL access the database system-specific properties and services can be utilized and additional overhead by SAP R/3 is avoided. However, using the Native SQL interface incurs some drawbacks such as: (1) Limits portability due to the system-specific services, (2) Limits access to encapsulated relations due to circumventing the SAP-internal data dictionary, (3) Non-robust native SQL reports as SQL directly reads database relations, potentially leading to business process overlooking, an issue that would normally be avoided by SAP R/3’s application programs; that is, bypassing SAP R/3’s data dictionary requires expert knowledge about the rules and dependencies of the system [6].

A database layer records and stores all the information about the system, including transactional and configuration data. SAP supports relational databases such as DB2,


White paper 12

SQL server, Oracle and Informix. Database servers can be on different servers from the application servers, and can include mainframes, Windows NT, UNIX or AS/400.

Figure 3 R/3 database layer interface [6].

Integration Architecture

The Figure 4 shows typical enterprise architecture with SAP R/3 as a main ERP system. There are many different ways to integrate R/3 with other enterprise applications. By using middleware integration hub architect simplifies integration logic and move it outside of R/3 package.

Figure 4: Typical Enterprise Architecture with SAP R/3


White paper 13

R/3 architecture allows to use common hardware pool for its servers but you cannot integrate its database with other applications. You have to use standard R/3 interfaces to move data in and out of SAP R/3.

Interfaces

The R/3 System offers standard interfaces to enable integration of R/3 with the processes and data of business applications from other vendors. Among these interfaces are object-oriented interfaces are called Business Application Programming Interfaces (BAPIs). BAPIs are compatible with Microsoft’s Distributed Component Object Model (COM/DCOM) specifications and the Object Management Group’s Common Object Request Broker Agent (CORBA) specifications.

SAP also supports the IP protocol stack and can allow access via a web browser. As mentioned earlier SAP supports Basis which is the middleware that allows SAP to run on different hardware and software platforms.

R/3 Basis supports the following communication methods,

� Remote Function Calls (RFC)

� Common Program Interface Communications (CPI-C)

� Electronic Data Interchange (EDI)

� Object Linking and Embedding (OLE)

� Application Link Enabling (ALE)

� Intermediate Document Interface (IDOC)

RFCs allow the programming of communication processes between SAP and other systems; this allows other systems to call R/3 functions. It is used mostly for communication control, parameter passing and error handling. RFCs are usually written in SAP ABAP language and operate by calling a program.

CPI-C is a program interface communication type. Its main function is to ensure a common and standard communication between two programs. CPI-C as a communication protocol defines session setup, session control, communication and session ending. CPI-C allows program to program communications and exchange.

OLE is used to integrate PC applications with the R/3 system. OLE connects presentation layer SAPGUI to R/3 as RFCs. OLE allows Microsoft Office, Corel Office, Star Office and Lotus Smart Suite to integrate with R/3. SAP can export data and reports into Excel; it can also import letters from word processors.

EDI, ALE and IDoc

ALE is the creation and operation of distributed applications. ALE is closely related to SAP Work flow. It is used to manage widely distributed, loosely coupled systems, based on an exchange of messages controlled by business processes. Individual companies in a corporation can distribute their transaction workloads where data are distributed, while a common service is offered throughout the network. Individual tasks can be distributed across locations. The systems involved can be different R/3


White paper 14

systems or non R/3 systems. With ALE, applications are integrated using asynchronous communications, and not using a central database.

ALE and EDI are similar protocols. The only difference between them is that ALE uses internal R/3 document format – IDoc, while EDI is an industry-standard format.

IDoc is used to exchange business data between SAP and external systems. IDoc can provide data to or from external sources and can be used to create transactions on SAP for automated processing. IDoc defines the structure, format and content of the document, and the IDoc interface also includes a definition of the processing logic for the data. A status code is maintained in the IDoc to identify where it is in the process flow as it moves from “created” to “posted” in SAP or the target system [5].

SAP EDI subsystem converts EDI to IDoc and back providing R/3 with unified way to handle inbound and outbound documents. The Figure 5 shows high-level view of outbound EDI and ALE transaction:

Figure 5: SAP R/3 Outbound Interfaces

Inbound ALE and EDI documents initiate R/3 workflow that can be configured to satisfy client-specific requirements. The Figure 6 shows high-level view of inbound EDI or ALE transaction:

Figure 6: SAP R/3 Inbound Interfaces

Three types of data are transmitted through ALE. The first type is referred to as control and customization data, such as user profiles, company codes and business data. The second type is master data, such as employee and vendor records which as


White paper 15

organizational unit data. The third type of data transmitted using ALE are records of transactions in the system, such as sales orders, shipments and inventory changes.

SAP R/3 Operations

Configuration and Implementation

The most difficult part of SAP R/3 is its implementation, mainly due to the fact that SAP R/3 is customized for each enterprise. For instance, IBM can have a different implementation of SAP R/3 from its competitors. SAP allows for customization using two main approaches [7]:

Customization configuration - Within R/3, there are tens of thousands of database tables that are used and may be customized to control how the application behaves. On example is the "Chart of Accounts". Each company code could have a different chart of accounts. In general, the behavior and usability of each screen and transaction is controlled by configuration tables.

Extensions, Bolt-Ons – SAP also allows the development of interface programs to communicate with other systems and applications. This generally involves developing ABAP/4 code, and systems engineering and integration effort to determine system interface requirements should be.

SAP includes a tool called the SAP Implementation Guide (IMG) [3]. IMG is used to assist the SAP administrator in the configuration of the SAP system. It is a tree structure that lists all actions required for implementing SAP.

IMG supports various views to view the tasks to be completed for a particular SAP implementation. This paper discusses three major common views.

SAP Reference IMG

SAP Reference IMG contains documentation on all SAP business application components supplied by SAP and serves as a single source for all configurations.

SAP Enterprise IMG

SAP Enterprise IMG is a subset of the SAP Reference IMG and contains documentation for only SAP components being implemented.

SAP Project IMG

SAP Project IMG is a subset of the SAP Enterprise IMG and contains documentation for only SAP enterprise components being implemented in a particular custom project. For example if an implementation of only the financial module is considered, but it has been divided into two projects – one for accounts receivable and one for invoices – we can set them up as two separate projects.


White paper 16

When SAP is used to implement an ERP system for different enterprises, an enterprise code will be used to differentiate between the different enterprises. This is useful is a large organization has several subsidiaries each in a different location with different business rules. For example an organization such as IBM could have a manufacturing implementation of SAP for its various plants world-wide. Each location could have its own enterprise structure using a different enterprise code.

Data Flows Model

SAP transactions comprise of several dialog steps called logical unit of work (LUW). A SAP transaction concludes with an update to the SAP database. Examples of SAP transactions are processing a sales order, a list of customers, an inventory report and a program execution.

To process a request it might be necessary to read data from the ABAP schema of the database or to write to it. Hence work processes are connected directly to the ABAP schema of the database [4].

Upon completion of the process results are sent back to the SAP presentation layer (SAP GUI) via the dispatcher.

Data that is often read but seldom changed – such as company codes, currencies, programs and customized client data – are kept as a copy of the database content in the shared memory of the application server. This improves performance and scalability.

SAP R/3 Projects and System Engineering

Overview

Classical SAP implementation assumes that SAP R/3 is replacing all or most of client’s home-grown applications that are called legacy systems. Your client would pay for consulting services in assisting with R/3 installation, configuration, data conversion, and training. Depending on level of customization SAP R/3 implementation project may last from six months to several years and cost from several to several hundred millions of dollars.

The days of such projects are almost over. Now SAP R/3 is just an addition to the portfolio of many Enterprise systems tightly integrated with business partners and customers.

Traditional SAP implementation methodologies (ASAP, Ascendant, etc.) cannot always provide optimal process for such hybrid projects. They are focused on configuring SAP R/3 as a central ERP system and treat all other systems as legacy or second-class members of enterprise architecture. One of the goals of System Engineer is to adopt these methodologies to the client needs.


White paper 17

In this paper we discuss several areas where System Engineers want to focus their attention on an SAP R/3 project.

SAP R/3 Requirements and Design

Business Requirements

No matter how many business requirements your client has, it is important to reconcile them with the biggest constrain – SAP R/3. The best way to do that is to document it as the very first requirement: client has decided to use SAP R/3 to implement selected areas of business operations.

This decision may impact many other business requirements in the following areas:

� Business processes – R/3 provides variety of customizable business processes that was designed considering best practices and optimized for many industries. However, if your client prefers to do business in a very unique ways, then it would require very expensive modifications.

� Performance – R/3 heavily depends on its database layer that may require significant investment to hardware side of the solution.

� Usability – R/3 provide own user interface and dictate certain working style. Your client should be ready to accept some limitations in this area.

� SOA – the latest versions of R/3 along with other SAP products provides more flexible way to control process flow, implement and consume web services. However, the architecture of R/3 is still very solid. It may be not as flexible as some other systems with native SOA under the hood.

SAP R/3 business requirements should contain list of high-level customizations. To produce such list SAP experts execute process called gap analysis. This process allows stakeholders to walk through standard R/3 processes and to recognize areas where such processes cannot be adjusted by simple configuration.

Systems Requirement

When systems engineers gather requirements for SAP based implementations the level of detail of the system requirement will vary according to the requirement context. Interface requirements to other applications most probably will be detailed.

On the other hand system requirements for SAP functionality will be less detailed as these functions are included and standardized in the SAP ERP application module. The level of details of these requirement is sufficient for the ERP, because many aspects already predefined by package. R/3 has large integration infrastructure. Hence a requirement might state "system shall connect to the Bank” instead of “system module FI shall support FTP to support connectivity to the bank”.

In most cases SAP R/3 system requirements will contain specifications for EDI and B2B interfaces.


White paper 18

Component Requirements

Every modification to SAP system is a change to the system. Therefore it should be done through the SAP Change Management Process that is implemented on the R/3 system level. Any change in code, table structure, screen, report, or even master data must be attached to a change record. Change record will be transferred to staging system and then, if testing was successful, to production.

It makes very good sense to organize component requirements for SAP R/3 as a set of SAP change requests.

SAP R/3 Testing and Deployment

Unit Testing

R/3 unit testing usually related to one transaction or report and it is associated with one change request. SAP R/3 comes with an internal tool known as Computer Aided Test Tool (CATT) that is used to automate and test business scenarios in R/3. SAP 6.20 includes eCATT application that also covers the automatic testing in SAPGUI for Windows and SAP GUI for Java. CATT is free but it does have some limitations which impel many companies to procure other test tools.

There are many vendors offering commercial automated test tools and test management tools for testing SAP. Manual unit testing is too expensive and it is not recommended for moderns projects.

Integration Testing

SAP R/3 Integration testing involves running end-to-end transactions that involve inbound or outbound documents.

User Acceptance Testing and Training

SAP R/3 is not an ordinary application; in many cases it completely changes way people do business. Therefore, training and change management are very important parts of any SAP R/3 project.


White paper 19

Acronyms and Glossary

Term

Description

ABAP Advanced Business Application Programming

ALE Application Link Enabling

B2B Business to Business

BASIS Business Application Software Integrated Solution

Batch Input Interface to facilitate the transfer of large amounts of either old data or

external data to an SAP system.

Batch

Processing

The procedure to process large volumes of data at once. The processing

cannot be modified once processing has begun.

CATT Computer Aided Test Tool

Client A self-contained unit with separate master records and its own set of

tables. Typically a Corporation.

Company code A company code is the smallest organizational unit for which has a

complete self-contained set of accounts.

CPI-C Common Program Interface Communications

EDI Electronic Data Interchange

ERP Enterprise Resource Planning

GUI Grpahical User Interface

IDoc Intermediate Document. Data container for data exchange between SAP

systems or between a SAP system and a Non-SAP system.

IMG Implentation Guide

Instance An administrative unit that groups together components of an SAP R/3

system or simply an Application server which has its own set of work

process.

IS Industry Specific

ITS Internet Transaction Server

Matchcode A tool for finding specific record Mainly used to find possible entries for an

input field

OLE Object Linking and Embedding

Plant A plant is an organizational unit within a company that produces materials

to make goods and renders services

RDBMS Relational Database Management System

RFC Remote Function Call. Allows to call and process predefined

procedures/functions in a remote SAP system.

SAP Script SAP-own word processing system. The text editor supplied with the R/3

System for creating and editing documentation.

SQL Structured Query Language


White paper 20

Term

Description

Sys ID A set of three letters or number that identify a system. Some sets are not

allowed because they are used by SAP. They are informed when the system

is installed.

Transaction A series of business-related, logically consistent dialog steps. The

transaction uses a program that conducts a dialog with the user.


White paper 21

Bibliography and References

[1]

IBM, “IBM and SAP”, http://www-03.ibm.com/solutions/sap/index.jsp?pword=sap&tactic=6N2D6W01&cc=us&re=google

[2] http://www.ryerson.ca/~ppille/sap/Resources/EnterpriseResourcePlanningSAP2.htm#SAPR3Architecture

[3] Danielle Larocca, “Teach Yourself SAP R/3 in 24 hours”, Sams Publishing, 1999.

[4] Arindam Ghosh, “SAP R/3 System Architecture”, http://aspalliance.com/1128_SAP_R3_System_Architecture, Feb 2007.

[5] IBM, “Monitoring Inbound and Outbound IDocs”, Rel. SOL 1.0b, Oct 2003.

[6] J. Doppelhammer, T. Hoppler, A. Kemper and D. Kossman, “Database Performance in the Real World: TPC-D and SAP R/3”, available at http://www.db.fmi.uni-passau.de

[7] “SAP R/3”, http://en.wikipedia.org/wiki/SAP_R/3

[8] IBM, “SAP: Tech Lite”, http://w3-03.ibm.com/hr/taag.nsf/Content/85256F0E%3A0069AFED


White paper 22

About Systems Engineering, Architecture and Test

The SE community of practitioners mission is to implement industry-proven systems engineering principles and practices on programs to reduce risk, reduce cycle time and improve the quality of the solution; and to globally deliver our expertise to other communities in the areas of enterprise IT strategies, centers of excellence and standards.

Contact the Authors

Sergey Kucherov/Chicago/IBM

Sergey is a System Engineer in the IBM Global Business Services. He has 18 years of experience in system engineering and business transformation. Before joining IBM he was a Project Manager and a Senior Consultant for PricewaterhouseCoopers (PwC). Sergey holds Masters Degree in Physics from the Moscow State University and is IBM certified IT Architect.

Ayman Nassar/Baltimore/IBM

Ayman joined IBM in 2006 as Systems Engineer and Architect. He has 17 years of experience in systems engineering and architecture, new product development and project management in telecommunication and IT operations and infrastructure systems. He holds a Masters degree in Electrical Engineering from Cairo University and is PMP certified by the Project Management Institute (PMI).

Contact the Systems Engineering and Architecture Group

For more information, visit our web site:

SEAT Competency: http://d27db001.rchland.ibm.com/s_dir/seatcomp.nsf/ContentDocsByTitle/SEAT+Competency+-+Home

Global Systems Engineers: https://w3.webahead.ibm.com/w3ki/display/SystemsEngineers/Home


White paper 23

Appendix A: SAP Modules

A list of common SAP modules is enclosed below.

EH&S Environmental Health & Safety

Designed for the management of environmental regulatory information, particularly product safety data as required for Material Safety Data Sheets. EH&S has sub-modules of Product Safety, Dangerous Goods, Waste, Industrial Hygiene, and Occupational Health.

FI: Financial Accounting

FI provides external reporting of general ledger, accounts receivable, accounts payable and other sub-ledger accounts with a chart of accounts. As entries are made relating to sales production and payments journal entries are automatically posted. Submodules of the FI modules are,

FI-GL General Ledger Accounting

FI-LC Consolidation

FI-AP Accounts Payable

FI-AR Accounts Receivable

FI-BL Bank Accounting

FI-AA Asset Accounting

FI-SL Special Purpose Ledger

FI-FM Funds Management

CO: Controlling

Represents the company's flow of cost and revenue. It is a management instrument for organizational decisions. It too is automatically updated as events occur. The CO module has following sub modules,

CO-OM Overhead Costing

CO-PA Profitability Analysis

CO-PC Product Cost Controlling

AM Asset Management


White paper 24

Designed to manage and supervise individual aspects of fixed assets including purchase and sale of assets, depreciation and investment management.

PS Project System

Designed to support the planning, control and monitoring of long-term, highly complex projects with defined goals.

FS Insurance

An integral part of mySAP ERP, SAP for Insurance enables insurance companies to handle customer and market requirements and simultaneously control profitability and economic viability. SAP for Insurance includes the following components,

FS-CD Collections and disbursements

FS-CM Claims management

FS-CS Commissions management

FS-PM Policy management

FS-RI Reinsurance management

IS: Industry Solutions

Combines the SAP application modules and additional industry-specific functionality. Special techniques have been developed for industries such as banking, oil and gas, pharmaceuticals, etc. Industry Specific Solutions supported by SAP are,

IS-A Automotive

IS-ADEC Aerospace and Defense

IS-AFS Apparel and Footwear

IS-B Banking

IS-BEV Beverage

IS-CWM Catch Weight Management

IS-DFS Defense and Security

IS-H Hospital

IS-HER Higher Education

IS-HSS Hospitality Management

IS-HT High tech


White paper 25

IS-M Media

IS-MIN Mining

IS-MP Milling (or IS-MILL)

IS-OIL Oil

IS-PS Public Sector

IS-R Retail

IS-REA Recycling Admin

IS-SP Service Provider

IS-T Telecommunications

IS-U Utilities

HR: Human Resources

SAP HR is an integrated system providing the functions to support the planning and control of personnel activities.

HR-PA Personnel Administration

HR-PD Personnel Development

HR-RC Recruitment

PM: Plant Maintenance

Equipment servicing and rebuilding. These tasks affect the production plans.

MM: Materials Management

Supports the procurement and inventory functions occurring in day-to-day business operations such as purchasing, inventory management, reorder point processing, etc.

QM: Quality Management

QM provides quality control and quality planning and inspection for manufacturing and procurement.

PP: Production Planning

PP plans and controls the manufacturing activities of a company. PP includes; bills of material, routings, work centers, sales and operations planning, master production scheduling, material requirements planning, shop floor control, production orders, product costing, etc.


White paper 26

SD: Sales and Distribution

SD supports the tasks and activities carried out in sales, delivery and billing. Key elements are: pre-sales support, inquiry processing, quotation processing, sales order processing, delivery processing, billing and sales information system.

SCM: Supply Chain Management

SCM allows the synchronization and integration of SCM functions across an organization.

SEM: Strategic Enterprise Management

SEM allows the support of strategic management functions and comprises of several components which are,

SEM-BCS Business Consolidation

SEM-BPS Business Planning and Simulation

SEM-CPM Corporate Performance Monitor

SEM-BIC Business Information Collection

SEM-SRM Stakeholder Relationship Management

WM: Warehouse Management

WM allows the subdivision of the MM module "Storage Location" to define inventory values by location, into "Storage Types" and into "Storage Bins".

WM-HUM Handling Unit Management, HUM provides a unique ID for each pallet of stock held in the warehouse.

2007 IBM Ltd. All rights reserved.

All trademarks or service marks are trademarks of their respective owners.

sap_r3_primer_white_paper-1[1].0.pdf

Documents