WHITE PAPER:

IMPLEMENTING SAP FROM END-TO-END

BUSINESS PROCESS SCENARIOS

Table of Contents
ABSTRACT ...................................................................................................................... 3
INTRODUCTION............................................................................................................. 3
BACKGROUND...............................................................................................................4
METHODOLOGY ............................................................................................................ 7
COMPONENTS OF THE REFERENCE MODEL APPROACH TO IMPLEMENTING
COMPOSITE APPLICATIONS ...........................................................................8
THE REFERENCE MODEL APPROACH ................................................................... 14
CONCLUSIONS............................................................................................................ 20
RELATED PAPERS...................................................................................................... 20
REFERENCES ............................................................................................................... 21
END NOTES ..................................................................................................................22

Table of Figures
Figure 1: The center of the universe consequence of non-enterprise implementations............. 5
Figure 2: An end-to-end viewpoint required for true enterprise integration. In this approach,
IT supports the E2E business process. ........................................................................................ 6
Figure 3: A generic reference model for E2E order execution using the SCOR model for
organizing the business objects................................................................................................... 10
Figure 4: Example of a Place-Order Composite Application...............................................................13
Figure 5: Transitioning an E2E scenario from the ARIS Toolset into SAP NetWeaver for
execution ...............................................................................................................................................16
Figure 6: Object sharing across the enterprise is accommodated by the SAP Business
Process Platform.................................................................................................................................19

IMPLEMENTING SAP FROM END-TO-END BUSINESS

PROCESS SCENARIOS

ABSTRACT
Business processes extend across functional and organizational boundaries. In this
real world, supporting information systems must be implemented using an end-toend viewpoint to ensure a true business process orientation. Recent technology
developments now enable solution implementations that are aligned with business
processes. This paper presents a methodology for implementing composite solutions
that span the enterprise. Given a heterogeneous IT landscape composed of both SAP
and non-SAP components, a generic order execution scenario is used to derive a
company-specific reference model. The model is documented in the IT architecture
where business objects are mapped into a composite solution. Commercial products
that are used to illustrate the methodology include SAP NetWeaver and ARIS
Process Performance Manager and modeling tools. An overview of the key
components that are critical to the understanding of reference model approach is
given.
Keywords: Business Process, End-to-End (E2E) Scenarios, Composite Applications, Enterprise Services Architecture,
Web Services, SAP, ARIS.

INTRODUCTION
Traditional enterprise system vendor demonstrations assume that all organizational
processes are contained within the integration domain of their product. For example,
SAP has a hypothetical company that is called the IDES, where the business
processes of this idealized organization are completely enabled by the mySAP
software suite. While these demonstrations are effective, they do not represent the
real world, where organizational processes are seldom bounded by the solutions of
a single vendor. A more realistic scenario is a heterogeneous system landscape (i.e.,
not completely enabled by a single vendors software solution) where end-to-end
(E2E) business processes flow across an enterprise and span many organizational
and system boundaries.
Of course, enterprise managers have understood this distinction for years, but
technology had not sufficiently evolved to enable E2E scenarios. Typically,
approaches require the interfacing of existing or new families of systems to achieve
an implied process flow. With this approach, one is bound by the inflexibility of the
implied processes that could otherwise be enabled by the interfaced systems.
However, developments in commercial enterprise software packages have recently
opened new possibilities for implementing solutions that are aligned with E2E
business processes. These composite solutions extend the functionality of an
organizations systems and remain true to the real world business process. At this
time, it is uncertain how the next generation systems of the major vendors (SAP,
Oracle, etc.) will evolve, but there are emerging trends that permit the elucidation of
a methodology for implementing composite applications that span the enterprise.
This paper provides our version of such a methodology. Our main contribution is the
Copyright 2008 Enterprise Integration, Inc. All Rights Reserved.

IMPLEMENTING SAP FROM END-TO-END BUSINESS

PROCESS SCENARIOS

bounding of the composite process with a reference process that is first presented in
generic terms, and then translated (through object mappings or interface service
presentations) into a composite application that can be implemented across a
heterogeneous system landscape.

BACKGROUND
Historically, organizations have evolved as circumstances have permitted. Product
demand, available resources, competition, partners and alliances, and management
style among a host of many other factors have influenced enterprise development.
These factors have similarly influenced the growth of the organizations information
systems that it has either developed or procured. For the most part, these systems
comprise a mix of applications that address particular requirements that are specific
to a functional area (i.e. sales, customer support, etc). In effect, they have become
islands of automation. Enterprise Resource Planning (ERP) applications1 raised the
hope that an integrated solution2 would address and resolve the integrity problems
that result from these disparate information systems. However, early generation ERP
implementations were limited constructs, and did not achieve the single source of
truth that managers sought. Indeed, the solutions offered within these enterprise
packages have in many cases been implemented in stove pipes; and have been
limited to supporting only specific and individual organizational functions that are
bound to the vertical solution. In the end, they increase, as opposed to reduce the
complexity of the information technology (IT) landscape; the promise made by the
business development teams.
Neither has the perceived promise of these large and complex systems materialized
with the evolution of Enterprise Application Integration (EAI) solutions. Interoperable
systems have only enabled the passage of data, and little more, with the business
processes remaining trapped in the stovepipes. As such, a vast and heterogeneous
landscape of information systems has often come to characterize an organization. In
the center of theses interfaced systems stands a complex and expensive enterprise
application, which has become the center of corporate activity (see figure 1). With its
pre-defined and scripted business processes, the ERP system and its satellites enable
enterprise business processes. Processes within this domain are driven by the scope
of the ERP system, and they are typically not true end-to-end business processes.
Also, they are usually not fully integrated, nor do they enable an agile and innovative
process-centric organization. In short, the competitive advantage of ERP is often
compromised because organizations do not implement the solution as it was
intended to be implemented. As opposed to being implemented as an enterprise1

See Gulledge, et al (2005) for background information on the basic concepts of ERP.

Integration is a word that means different things to different people. Gulledge (2005) describes the usage context
for ERP systems. In this case, the authors are referring to Big I in the classification scheme proposed by Gulledge.

Copyright 2008 Enterprise Integration, Inc. All Rights Reserved.

IMPLEMENTING SAP FROM END-TO-END BUSINESS

PROCESS SCENARIOS

wide solution, ERP is implemented as a sub-component of the enterprise, and in

some cases, even within an organizational stovepipe.

Sub-enterprise Scoping Diminishes

ERP Value Proposition
JC2

BCS3
FBCB2
FCS

J-CALS
TLDD

BSM

DFAS

GCSSArmy

TMDE

TC-AIMS II

OSMIS

LMP

AALPS

DIMHRS

IETM
Legend

Joint System
ARMY System
DoD System

LIDB
TAV

OTHERS

MC4

MTS

All
Services

Figure 1: The center of the universe consequence of non-enterprise implementations

As noted above, frequently enterprise system implementations produce a state of

affairs where the ERP solution becomes the center of the universe. When ERP is
implemented in this way, it is just another system that must be managed across a
complex technology landscape; and business processes that depend on this system
are bounded by its stovepiped scope. This is a common problem. Fortunately, the
Center of the Universe paradigm is being replaced by new enterprise solutions that
support an end-to-end composite application framework.
The business environment has become increasingly competitive, and will no longer
tolerate those enterprises that do not posses the inherent agility within their business
processes to respond to the demands of the environment. Enterprises have extended
and networked across functional and/or geographical boundaries, and in doing so,
have sought competitive advantage in areas regardless of where these value-added
activities may be found. A true enterprise management approach demands an endto-end viewpoint (see figure 2) that flows unimpeded across the constraints imposed
by information system. Hence, where Okrent and Vokura (2004) focus on those
processes that fall within system boundaries, we focus on those that flow inside and

Copyright 2008 Enterprise Integration, Inc. All Rights Reserved.

IMPLEMENTING SAP FROM END-TO-END BUSINESS

PROCESS SCENARIOS

outside. End-to-end business process management is the viewpoint that provides

transparency to identify cost reductions, efficacies, opportunities, new practices, and
other related benefits. In this model, IT supports a corporate strategy and embedded
business processes, it does not dictate them. This result is in direct opposition to the
Center of the Universe model where all business processes are constrained by the
interfaces across system components as in Figure 1.

End-to-End Business Process Scenario

Create
quotation

Accept
order

Create
shipping list

Write
invoice

Check
payment

Sales
staff

Customer
management

Clerk

Group
leader

Clerk

Process
Flow

Inquiry

Process
sequence
Quotation

Service

CRM

Order

Shipping
list

Service

ERP

Invoice

Payment
received

Time

Wrapper

Legacy

Figure 2: An end-to-end viewpoint required for true enterprise integration.

In this approach, IT supports the E2E business process.

In the real world scenario of figure 2, there are also very real constraints. It was
previously stated that many organizations already depend on a universe of disparate
systems, and they already have deeply ingrained corporate practices that are tied to
their existing systems. Improving upon these business processes may appear to be a
daunting, if not impossible, task. Many organizations have already gone down this
path before, and many only achieved a limited return on their investment. Further,
end-to-end processes themselves can be vast and extraordinarily complex.
Identifying, let alone enabling an accurate end-to-end business process, is difficult.
The question is then, how does an organization implement an end-to-end process
across a complex heterogeneous IT landscape?

Copyright 2008 Enterprise Integration, Inc. All Rights Reserved.

IMPLEMENTING SAP FROM END-TO-END BUSINESS

PROCESS SCENARIOS

METHODOLOGY
We demonstrate an E2E implementation approach using a reference scenario - E2E
Order Execution - a critical business process for most enterprises. This process
begins with the receipt of an order that triggers an order execution process and
terminates with an output that is delivered to the customer. We show how our
general reference model evolves into a customer specific reference model, is
aligned with application solutions, is enabled by data, tested, and executed. There
are many possibilities for demonstrating the concept, so we focus on one type of
composite application, a process that is comprised of both SAP and non-SAP
components3. Table 1 presents the general steps that define the methodology.

Step

Description

1.

Develop a business architecture.

2.

Develop or procure a generic E2E reference scenario.

3.

Align the reference scenario with the target organization, creating a customer-specific
reference model.

4.

Determine which segments of the process will be scoped within SAP, and which
segments will reside in other applications. This is accomplished using a known
4
commercial approach, such as ARIS .

5.

For the SAP segments, map (or replace) the company-specific objects with objects
from SAP using NetWeaver.

6.

For the non-SAP components, wrap the interfaces so that the functionality provided
5
by the system may be instantiated as an enterprise service .

7.

Synchronize the complete customer specific model with SAP Solution Manager.

8.

Bind the data to the services using the capabilities of the SAP Web Application Server .

9.

Test the E2E composite application.

Table 1: Steps in a Reference Model Approach to Implementing Composite Applications

3

See Wood (2004) for the definition of a Composite Application within the context of SAP and non-SAP
components.
4

This approach is quite complicated, and is comprised of a complete architecture-driven methodology. Information
on the approach can be found at http://www.ids-scheer.de/.
5

It is also possible to evolve this step through traditional Enterprise Application Integration (EAI) techniques, but we
focus on the service-oriented approach for this baseline example.

While we have not explored all possibilities, it should be possible to execute some sequence of these steps by
alternative means, with the orchestration falling in third party non-SAP products, such as those from Digital Harbor
(http://www.digitalharbor.com/)

Copyright 2008 Enterprise Integration, Inc. All Rights Reserved.

IMPLEMENTING SAP FROM END-TO-END BUSINESS

PROCESS SCENARIOS

Table 1 describes a new paradigm for implementing enterprise solutions. Notice that
the focus is not on the configuration of ERP modules, but on business processes.
Also note that there is no requirement that all business processes fall inside the
enterprise integration domain; i.e., inside of a single enterprise solution providers
product offering. In fact, we specifically consider in our example the case where
some components are external to SAP. The main point is that the reference scenario
and the company-specific reference model, which ensures a true business process
orientation (as opposed to an interfaced family of systems) drives the
implementation. Throughout, we focus on SAP and non-SAP composite applications,
but a similar approach would be used with Oracle, or the product of any vendor that
permits the orchestration of business processes from enterprise services7.

COMPONENTS OF THE REFERENCE MODEL APPROACH TO

IMPLEMENTING COMPOSITE APPLICATIONS
We acknowledge that we use terms that may not be familiar to readers who are
unaware of the new enterprise system paradigm. The following sections provide an
overview of the key components that are critical to the understanding of the
reference model approach to orchestrating enterprise services.

Reference Models
When it comes to successful Business Process Management (BPM), it is important to
understand and be aware of three main items: (i) the business processes that are to
be managed; (ii) how these processes compare against best practices, and (iii) how
these processes can be implemented in supporting IT systems that are available to
the organization. Gaining an understanding of these items is where reference models
can assist. In the scope of this paper, the term reference model is used to refer to any
model that represents an overview of a particular business process regardless of
the level of detail of the model8.
Generally, reference models will either focus on a business process, or how it can be
implemented in a specific IT environment. The former will typically be based on
research into existing implementations. Here, a generic process will be applicable to
most organizations, regardless of the particular IT environment. The latter is typically
based on an existing and proven implementation of a business process within a
specific IT environment for a specific organization. It may or may not be applicable to

Wood (2004) provides a management overview of enterprise services.

In general, a reference model could apply to any view of an architecture, such as data, organization, function, etc.
We focus on the business process view, since that is the most important for implementing ERP solutions.

Copyright 2008 Enterprise Integration, Inc. All Rights Reserved.

IMPLEMENTING SAP FROM END-TO-END BUSINESS

PROCESS SCENARIOS

other organizations, largely due to potential differences in the IT environment9. Both

can however present a starting point against which an organizations existing
processes can be compared and built upon to arrive at a to-be model of a new
process.
The benefit of a generic reference model is that it will be applicable to many
organizations and will easily allow an organization to compare its own processes
against the model. As these generic reference models are not based on a particular
IT implementation, they should be considered with caution. What may look good in a
generic reference model may not be able to be implemented in the organizations IT
environment, or it may be costly to implement. Apart from not necessarily being
based on best practices, non-generic reference models also need to be considered
with caution for a similar reason: they pre-suppose a particular IT environment. What
may appear to be slight changes in the IT environment can result in costly changes
to the actual implementation of the business process.
A generic business process (reference) model illustrates the business entities and
their relationships. It is not tied to the technologies or standards of the IT landscape;
rather it depicts the general method of executing a business process. The detail that
is specific to the needs of an organization will be added as required so that it can be
used to implement a targeted business concept. Even in establishing a generic
model, it is often useful to use a frame of reference to assist in the overall
development of the business flow, the various business activities and their
relationships. To that end, a blueprint, or an architecture that helps to guide the
layout of the generic process is also recommended. Any such appropriate
overarching mechanism will be adequate. For example, the Supply Chain Council has
released a reference model that visualizes a supply chain as different areas of intra
and inter-company activities. This Supply Chain Operations Reference Model (SCOR)
has served as a useful mechanism in building our generic order execution model (see
figure 3). For the reference model using the new SAP implementation paradigm, SAP
will provide Business Process Snippets, or short business processes that may be
modeled as components of larger aggregated business processes that are
documented in the SAP Business Process Platform. These process snippets are
referenced for usage in the Enterprise Services Repository (ESR), which is a type of
super UDDI10 reference repository that identifies all the required objects that are
available to assist in implementing the new SAP paradigm.

A discussion of some of the organizational and management issues associated with these types of misalignments is
provided by Clemmons and Simon (2001). Additional misalignment issues are presented by Ho, et al. (2004).

10

Universal Description, Discovery, and Integration (UDDI) is an industry initiative to create a platform-independent,
open framework for describing Web services, discovering businesses, and integrating business services using the
Internet. More information about UDDI may be found at http://www.uddi.org/.

Copyright 2008 Enterprise Integration, Inc. All Rights Reserved.

IMPLEMENTING SAP FROM END-TO-END BUSINESS

PROCESS SCENARIOS

Generic Order Execution Model SCOR Backdrop

Suppliers

Short term planning

Mid term planning

Production
Delivery
Schedule

Scheduling

Transport

Load

Workflow

Route

Warehousing

Distribution

Demand

Factory
layout

Budgeting

Detailed capacity

Detailed materials

requirements

requirements

requirements

Customers

Long term planning

Marketing

Strategy

planning

Financial

Product
planning

Inspections

forecasting

planning

Process
customer
order
Make

Source

Manage

Conduct
order release

relations

Deliver

Control costs

control

Manage

Transport

Manage

channels

supplies

inventory

Manage
Establish
agreements

Manage
configuration

Conduct
product

supplies

Collect and
analyze data

Provide
accounting
support

Load

Manage

product

fleet

Manage EHS

Pack

Control

product

engineering

Source

Procure

Supplies

supplies

Assemble

Customize
order

product

Control
production

transport

Distribute

Warehouse

Deliver

product

product

product

activities
Measure
Return source

Return deliver

performance

Provide
business
analytics

Return
parts

Provide
customer

Return
product

support
Product
accounting
Enable

Sales

ECommerce

Collaboration

R&D

Regulatory
compliance

Marketing

Human Relations

Operations

Manage
Information
systems

Figure 3: A generic reference model for E2E order execution using

the SCOR model for organizing the business objects

Business Process Execution Language

When creating a business process reference model in a software-based modeling
environment, a language known as Business Process Execution Language (BPEL) can
be used. BPEL is designed to serve as a structured modeling language to help
developers map business processes into an end-to-end solution. BPEL seeks to
overcome the challenge of orchestrating flows between Web-based transactions,
and ensures a single seamless business process. The language can synchronize and
sequence transactions between business systems to support a wider, integrated endto-end business process (Hofreiter and Huemer, 2004). Because individual
transactions are not usually embedded in a single application, having a language
designed specifically to make calls to disparate Web-based applications is very
important. Schmitz, et al (2004) explain that BPEL claims to be sufficiently detailed
so that an engine able to execute the BPEL process description can provide the
described services as a new combined service. Currently, the Organization for the
Advancement of Structured Information Standards (OASIS) is evaluating the
suitability of BPEL as an internationally recognized information standard (Schmitz et
al., 2004). Two standards for Business Process Modeling have evolved over the
years, with the Business Process Modeling Language (BPML) standard in competition
with BPEL. Recently the standards organizations have merged resulting in BPELs

Copyright 2008 Enterprise Integration, Inc. All Rights Reserved.

10

IMPLEMENTING SAP FROM END-TO-END BUSINESS

PROCESS SCENARIOS

absorption of BPML. As of this date, BPML is the standard that is supported by all of
the major enterprise systems vendors, including Oracle and SAP.

Service Wrappers
One of the principal challenges typically encountered when building an enterprise
application is accommodating pre-existing (also referred to as legacy) systems and
their associated data. Because it is usually infeasible to implement an entire E2E
enterprise application due to cost and time constraints, enterprise implementations
are usually blends of new and existing systems. Wrappers (also referred to as
adapters) serve as a bridge between different applications and enable the
construction of an enterprise architecture composed of different systems. Webbased wrappers are software tools that interpret information delivered from an
external business application (on the Web) and translate it into a structure which is
compatible with the master application (Mecella and Pernici, 2001). In practice, a
service wrapper would collect data presented on a Web page through HTML (HyperText Markup Language) and translate it into the more structured XML, (eXtensible
Markup Language). Once translated into XML, the information can be presented to
other applications that can parse the particular XML flavor in which the data was
stored. In this way, customer data from one business application can be
automatically passed to another application.

Web Services
There is a growing array of software methods, standards, and tools being developed
to enable the development of blended enterprise applications. A key element of
these tools is their adherence to industry-wide standards. Web-based protocols, such
as XML, SOAP11, WDSL12 and UDDI, can be used to allow disparate systems to
communicate. Utilizing such protocols and standards, Web services allow different
applications to interact with each other (without human interaction and regardless of
the applications development platform).
An E2E solution links internal and external business applications, systems, and staff
so that they can respond to dynamic business conditions. In the enterprise systems
literature, such linking is known as a composite application (see below). To
effectively support end-to-end processes, an organization must identify how Web
services are used to choreograph activities within a business process, how business
processes are represented as Web services, and also which business partners
perform what parts of the actual business process (Leymann, 2001). Identifying these
key components will facilitate the integrated solution needed to support Web service
11

The Simple Object Access Protocol (SOAP) is a lightweight protocol for exchanging information in a decentralized
and distributed environment. This XML-based protocol is typically used with HTTP. SOAP is a key component for
accessing and invoking a Web service.
12

Web Services Description Language (WSDL) is a specification for describing Web services as a set of end points
operating on messages.

Copyright 2008 Enterprise Integration, Inc. All Rights Reserved.

11

IMPLEMENTING SAP FROM END-TO-END BUSINESS

PROCESS SCENARIOS

activities. These Web services are orchestrated in accordance with a service-oriented

architecture.

Service Oriented Architecture

In order for composite applications to work in concert, enterprises must implement a
Service-Oriented Architecture (SOA). A service-oriented architecture is a modular
architectural framework that enables Web services and legacy components to
interact seamlessly. When an organization needs to create a new business process to
facilitate interaction with suppliers, customers, subsidiaries, or partners, the SOA
allows quick adjustment of components and creation of new virtual applications.
Business requirements can thus be met more easily and programming efforts and
costs are minimized. Mergers and acquisitions, strategic alliances, portfolio
management, new product rollouts, or supply chain management can be eased using
service-oriented architectures. (Hurwitz, 2003)
With a SOA, a business process involving two or more business partners can be
realized by composing Web services offered by the individual business partners
while taking into account the constraints and requirements defined for each
participating Web service in a hierarchical scenario (Leymann, 2001). The top-level
process in a hierarchical scenario does not have to be owned by an individual
business partner because the standard-based rules are defined in a "virtual
enterprise." Though Web services have held out great promise for integrating
business partners, their true potential remains to be tapped. That is clearly the plan
for next generation enterprise system implementations.

Composite Applications
In todays rapidly evolving business world, companies must be able to quickly adapt
and change their business practices (and in turn their underlying business processes)
to retain competitive advantage. However, organizations typically possess a host of
complex interfaced applications, many of which are from different vendors.
Consequently, even minor changes to a business process may require timely and
costly modifications to the IT environment. Replacing any or all of these systems may
not be possible as significant investments have already been made in these existing
solutions.
Composite applications provide a means to address this challenge. The goal of
composite applications is to preserve the existing software infrastructure by reusing
existing business services, or defining new services around existing functions
(Waloszek, 2005).

Copyright 2008 Enterprise Integration, Inc. All Rights Reserved.

12

IMPLEMENTING SAP FROM END-TO-END BUSINESS

PROCESS SCENARIOS

Taken from Seebeyond.com. (2005). Composite Applications and Service-Oriented Architectures.

Figure 4: Example of a Place-Order Composite Application

Figure 4 represents an organization, which employs existing systems to create a

composite application called Place Order. Four layers are shown: the existing
systems, business services, assembly and orchestration, and composite applications
layers. The existing systems layer contains several heterogeneous systems found in
different parts of the enterprise. Objects must be selected, transformed into common
object models, and then integrated into one or more business services. Services like
Create customer or Determine product availability are defined in the business
services layer. These services are part of a service-oriented architecture and are
reusable across the enterprise. The business process is defined and executed in the
assembly and orchestration layer, also called the process layer. The composite
application is now ready for presentation to the user, who is in turn ready to enter
customers order into the system for execution.

Enterprise Services Architecture

This section provides the foundation for bringing all of the previous concepts into a
framework for supporting an enterprise solution. Earlier solutions based on EAI
typically used interfaces to enable communication among disparate systems. Today,
leading businesses are in the early stages of implementing service-oriented
application servers the technology of choice to connect disparate systems. The
application server manages the services that are orchestrated as business processes,
Copyright 2008 Enterprise Integration, Inc. All Rights Reserved.

13

IMPLEMENTING SAP FROM END-TO-END BUSINESS

PROCESS SCENARIOS

and binds the data from relational or object-relations sources to the services.
Therefore, it provides the ability to create and maintain the integration logic in a
flexible and efficient manner, sharing objects across disparate system components.
However, the challenge has been how to plan, build, maintain, and utilize application
server integration for real business cases. By "real business cases" we mean those
that cut across an organization's internal and external boundaries. Realizing the need
for E2E real business scenarios, SAP has defined a Business Process Platform as a
core enabler of its Enterprise Services Architecture (ESA). The ESA, SAPs response
to the SOA, takes Web services standards and services-oriented architecture
principles and extends them to meet the business solution needs of the extended
enterprise. The concepts are summarized by van de Loo (2005).
With the Enterprise Services Architecture, a composite application can use
enterprise services to automate the flow of information from application to
application. This orchestration is accomplished using a new concept from SAP that is
known as the Composite Application Framework. Enabling the flow of business
processes across internal business units and external customers provides disparate
systems the ability to interact globally and in real time, in order to orchestrate,
oversee and operate complex internal and external business processes such as order
execution.

THE REFERENCE MODEL APPROACH

For purposes of our illustration, we present a medium size manufacturing business
that offers a family of products with variants, as well as customized orders. The
business has a dynamic supply chain and a customer relationship process that
continues to mature. The business environment within which the company operates
is customer oriented, fast paced, and demands attention to achieving competitive
advantage. The company struggles with establishing a broad perspective of its
business processes that span the entire enterprise. Specifically, it cannot fully
articulate what its value added activities are, both internally and externally with its
partners and suppliers. Furthermore, it has had only limited success in capturing
benefits of collaboration and innovation resident in its own employees. Finally, its IT
environment is complex and heterogeneous. It includes components of the mySAP
business suite, but also interfaces with non-SAP applications needed by its internal
organization, partnerships, alliances, and customers.
Given this assumed background, the company needs to become more agile and
responsive to not only rapidly evolving business opportunities, but also to an
increasingly demanding customer base. Therefore, the company cannot be
constrained by its own systems, interfaces, business processes, or by any incapacity
to fully leverage its enterprise wide capabilities. Hence, the company needs to know
(i) what its processes are, (ii) how the processes can be integrated and improved,
and (iii) how new processes can be created to address changing business demands.
Copyright 2008 Enterprise Integration, Inc. All Rights Reserved.

14

IMPLEMENTING SAP FROM END-TO-END BUSINESS

PROCESS SCENARIOS

Please note, that we are referring to business processes that extend from the start to
the end of an enterprise wide activity, rather than processes that are bound in
functional departments or stand-alone information systems.
The first step in this undertaking is establishing an overarching blueprint a highlevel architecture. Included in this architecture are the different views of the
company (i.e. systems, organization, processes, etc). The business process map of
the enterprise describes the companys overarching business process strategy and
will help to illuminate the value added (process) chains in the enterprise. It models
the company view of what business scenarios are desired. In other words, it is the
company reference architecture that allows management to illuminate, and focus on
a business process orientation as opposed to disjointed functional activities driven
by its interfaced family of information systems.
Once the architecture is established, the focus turns to the key business scenarios
that have been illuminated by the business blueprint. We have noted that the order
execution business process is fundamental to this enterprise, and we shall use this
scenario to illustrate its development into a company specific reference process.
After developing the architecture, the company must now layout an entire end-toend product ordering process. Developing an E2E order business process of this
magnitude requires particular attention to detail. To start this process, a generic
reference model greatly facilitates this effort. Although it is not specific to the
company, it assists in revealing the general landscape of the operations. At this point,
it is nothing more than a conceptualization of a basic E2E scenario from which a
company specific model can be developed.
Technology can support this modeling effort. Thus, it is important to note the
requirement for an effective and automated tool that supports the development and
subsequent management of the process. As the order execution business process is
being designed, the final results must be documented and implemented in the
company regardless of complexity. All of these initial steps can be accomplished by
using an automated modeling toolset such as ARIS13. ARIS can be employed as a
stand-alone product, and through a bi-directional interface, an E2E scenario can be
synchronized with the SAP Solution Manager14 that is itself a component of the SAP
NetWeaver. Besides creating models using ARIS, another option is to use reference
models (i.e., process scenarios that exist in the SAP Solution Manager, which is also a
part of NetWeaver). These pre-designed models describe a business process, and
can be customized for use, and imported into ARIS. It is important to note here that
sophisticated modeling tools will assist in developing, configuring, and implementing
the E2E process. The complete process is presented in Figure 5.

13

ARIS stands for Architecture of Integrated Information Systems. Additional information about ARIS may be found
at http://www.ids-scheer.com/.

14

For those not familiar with the SAP Solution Manager, see Gulledge and Simon (2005).

Copyright 2008 Enterprise Integration, Inc. All Rights Reserved.

15

IMPLEMENTING SAP FROM END-TO-END BUSINESS

PROCESS SCENARIOS

E2E Scenarios in SAP NetWeaver

Customer
Business Process supported by
SAP components (and others)

Customer
Business Process
Carries out & Sup p... Carries out & Supports

Organizational element... .

GCSS-A

PLM+

Carries out & Supports

Carries out & Supports

BSM

GFEBS

Requirement
Identified

Requirement
Identified

Create and
Send MRO

Create and
Send MRO

Carries out & Supports

Carries out & Supp... Carries out & Supports

GCSS-A

PLM+

Carries out & Supports

LMP

GFEBS

Not valid
On-hand
Syste...

Pic k Item

Send Refusal
Notifi cation

Release
Item

Unblock
Stock

Stock
On- hand
(System)

Stoc k Not
On-hand
(Sy stem)

Pick Item

Send IDoc
(Refusal
Notification)

Proc ess copied from LMP

-> needs to be confirmed

Requirement
Identified

Create and
Send MRO

Scenarios
Processes
Process Steps

Item i s
Physically
Not On Hand
Send
Denial
Notifi cation

Item is
Physically
On Hand

Item is
Physically
Not On Hand

Post Goods
Issue

Send IDoc
(Denial
Notification)

Print Physical
Inventor y
Document

Rec eive
Refusal/
Denia...

Rec ei ve
Refusal/
Denia...

Initiate
Inventory

Block Stoc k

Block Stock

Post
Inventory
Results

Decide if
Backorder or
New Source

Decide if
Backorder or
New Source

Send
Inventory
Results

Release
Purchase
Requisition

Release
Purchase
Requisition

Item
Released

Block Stock

Stock
Unblocked

Release
Purchase
Requisition

Pr oc ess copied fr om LMP

-> needs to be confir med

Release
Purchase
Requisition

Item
Released

inc ludes all reasons

for physic al inventory

Requir ement
Identified

Cr eate /
Pr ocess Stock
Transpor t
Order i...

Process
Reservation

Receive
MRO

Valid
On-hand
Syste...

Item is
Physically
On Hand

Solution Manager

Carries out & Supports

BSM

LMP

Application system

Carries out & Supports

SAP Configuration
Model

New Source

Backorder
Proc essing

New Source

Backorder
Processing

Resource
from
New Source

Process
Backorder

Resourc e
from
New Source

Process
Bac korder

Send Status
to Customer

Rec eive IDoc

(Refusal/Deni
al)

Enter Count
Results

Receive
Refusal/
Denia...

SAP Execution
Model

Block Stock

Post
Inventory
Differences
Decide if
Backorder or
New Sour ce

Send IDoc
(Inventory
Results)

New Source

Backorder
Processing

New Source

Backorder
Processing

Resour ce
from
New Source

Process
Backorder

Resource
fr om
New Source

Process
Backorder

BPEL
XI Execution
Model

Send Status
to Customer
Send IDoc
(Status)

Exchange Infrastructure

Decide if
Backorder or
New Sourc e

Send Status
to Customer

Receive
Status
Delete
Reservation

Customer
Received
Status

Customer
Received
Status

Rec eive
Inventory
Results

Rec ei ve
Inventory
Results

Unbloc k
Stock

Unblock
Stock

Adjust
Inventory
Balance

Adjust
Inventory
Balance

Receive IDoc
( Inventory
Results)

Receive
Inventor y
Results

Adjust
Inventory
Balance

Adjust
Inventor y
Balance

Unblock
Stock

Update
General
Ledger
General
Ledger
Updated

Update
General
Ledger
General
Ledger
Updated

Figure 5: Transitioning an E2E scenario from the ARIS Toolset into SAP NetWeaver for execution

Regardless of whether a generic model is used from the Solution Manager, procured,
or developed in ARIS or elsewhere, adjustments of the model into company specific
terminology must then be made. The generic model must be reiterated in the context
of the specific company and its environment. Importantly, the process must be
aligned to the overall business process architecture of the company to ensure its
relevancy. In doing so, increased detail is added and specific key performance
requirements and associated metrics can be highlighted as well. With whom and how
basic entities inter-relate, and the associated complexities of their interaction should
also be noted. For example, how and when the company and its customer interact in
relation to an order. Similar to this interaction are those interactions between the
company, its partners and suppliers. The complexities of how a generic product is
processed throughout its lifecycle from concept development to disposal can be
referred to for comparison.
At this point, we have taken a generic execution process, and adjusted it to become
a company specific process. Likely, the process of aligning the generic reference
model to the target organization has revealed the heterogeneous mix of enterprise
applications (SAP and non-SAP) present in the IT landscape. However, this
illumination does not (at this point) enable integrated data and process flow across
the IT landscape. To achieve this, we now need to translate the descriptive model

Copyright 2008 Enterprise Integration, Inc. All Rights Reserved.

16

IMPLEMENTING SAP FROM END-TO-END BUSINESS

PROCESS SCENARIOS

into a solution. To that end, we must communicate the execution process through
the various applications and legacy systems.
As noted earlier, integrated systems are fundamental to passing processes related
information between applications. Although application programming interfaces
(APIs) allow different enterprise applications to communicate with each other, the
business process logic in these applications is never passed between them. In other
words, the data is sent without any understanding of the process. The passing of
relevant and accurate data, let alone the integrity of the process is problematic.
NetWeaver provides a solution to address the data and process integration problem.
We discuss NetWeaver as a solution for implementing our extended order process in
SAP and non-SAP enterprise applications (as well as legacy systems) for those who
wish to pursue these options.
NetWeaver is a SAP compilation of products that are presented as an integrated
technology stack. NetWeaver allows for the development, modeling and
implementation of business processes that retain integrated data bound to
enterprise services, as they are executed across the enterprise. Within NetWeaver is
a component known as the Exchange Infrastructure (XI). XI has a number of
integration components to define, map, configure, describe and store the execution
process, its associated message formats, and how it will interface with other
applications. Once the order execution process is developed in ARIS, and mapped to
the business process objects in the Solution Manager, process execution is managed
through the XI as indicated in Figure 5. The integration builder component of XI is
used to build and map one message format to another for use among the various
application systems. The process is then configured for execution; i.e., this is where
the definitions for the routing of information occur.
Using our order execution example, information received in the customer order may
be relevant to several different parts of the organization, such as accounting,
manufacturing, or delivery. Appropriate routing of this information is stored in the
(XI) directory. This directory also adds additional configuration-specific information
needed for execution. If non-SAP applications are contained within the IT landscape,
SAP NetWeaver has the ability to use other industry-specific standards for
communicating business processes across the enterprise. As an example, different
messages from external customer orders can be mapped to internal SAP message
structures. In this way, when the order is received it is communicated accurately
within SAP components. Descriptions of the various messages and processes (both
by SAP and those from its partners and customers) are kept and drawn from the
integration repository. Through these configuration activities, our model becomes
customer specific.
It is the application server that performs the tasks involved in controlling the
execution process, binding data, and exchanging its XML-based services among
other connected systems. A key component in the server is the adapter framework
that enables different applications outside of XI to communicate. Adapters (recall our
Copyright 2008 Enterprise Integration, Inc. All Rights Reserved.

17

IMPLEMENTING SAP FROM END-TO-END BUSINESS

PROCESS SCENARIOS

discussion of wrappers) are used for applications within SAP, messaging systems
(e.g., SOAP), and other industry standards (e.g., RosettaNet), and non-SAP
applications (e.g., Oracle). So, if a partner in the order execution supply chain uses a
non-XML format, then an adapter (that is built or procured) will enable a connection
to the XI.
How the order execution process is communicated and navigated through SAP and
non-SAP solutions is managed in the SAP Solution Manager (also a part of
NetWeaver), which manages the implementation and provides configuration
management control over those objects that are shared across the enterprise. As the
to-be execution process is configured, the complete development lifecycle is
managed within the SAP Solution Manager. Here, the order execution process
becomes testable and executable.
The SAP Web Application Server (SAP Web AS) is fundamental to both NetWeaver
and the ESA approach to Web services. As the name suggests, SAP Web AS is a
server that communicates through the IP protocol. This is important to the final
development of our solution, which can now be extended as a service. Recall that the
ESA is a new paradigm for implementing enterprise solutions. The focus is not on
modules or applications, but on business processes themselves; and the business
processes need no longer be constrained to a single ERP domain. Rather, the
architecture is what enables an organization to extend its infrastructure on to the
Web and throughout the enterprise.
For example, the execution order may necessitate a special service from one of the
companys external partners (be it financial, manufacturing, or otherwise) this is
possible because NetWeaver runs on the SAP Web AS, and as long as outside
providers follow the standards, external services may be stored for sharing inside the
SAP Enterprise Services Repository. This is critical to our process as it can now
operate end-to-end, and it truly operates across the geographical and functional
boundaries of the extended enterprise. Furthermore, new and composite solutions
can be either developed or created through re-used lower level business processes
and objects. The concept of sharing and reusable components as presented by van
de Loo (2005) is reproduced in Figure 6.

Copyright 2008 Enterprise Integration, Inc. All Rights Reserved.

18

IMPLEMENTING SAP FROM END-TO-END BUSINESS

PROCESS SCENARIOS

Models are a Key Element of the Platform

Business Suite

SAP Composite Apps

(incl. UI & analytics)

Enterprise
Services
Repository

Services

Object

Events

Roles

Process

Legacy/
Partner
Services

Legacy/
3rd Party

ISV
components

ISV / Customer
Composite Apps
(incl. UI & analytics)

SAP
non-platform
components

models

snippets UI patterns
OEM
platform
components

Process
Process Components
Components

The platform contains one consistent set of models

Contributed by any component
Used by any component
Slide taken from Kaj van de Loo, The SAP Business Process Platform, presentation at Burton Group Catalyst, 2005

Figure 6: Object sharing across the enterprise is accommodated

by the SAP Business Process Platform

Although it may not be readily apparent, Figure 6 is key to understanding the value
proposition for the Enterprise Services Architecture and Service Oriented
Architecture as a general concept. The value of service orientation follows from reuse. In this case, the re-use is from the sharing of services across the enterprise.
Hence, if service oriented enterprise solutions are implemented in stovepipes, and
the objects are not shared, the value proposition evaporates, just as it does with
traditional highly interfaced enterprise solutions.

Copyright 2008 Enterprise Integration, Inc. All Rights Reserved.

19

IMPLEMENTING SAP FROM END-TO-END BUSINESS

PROCESS SCENARIOS

CONCLUSIONS
We have shown, using a generic reference scenario and model, how management
can ensure a true business process orientation across a heterogeneous information
system landscape. This is in contrast to current approaches that interface existing or
new families of systems to achieve an implied process flow that is bound by the
nature of the interfaces. We accomplished this by bounding a composite process
with a reference process that is first presented in generic terms. The scenario is then
translated (through object mappings or interface service presentations) into an E2E
solution that can be implemented in a heterogeneous system landscape in the SAP
Solution Manager.
The intent of the methodology is to facilitate a companys understanding and
capacity to design integrated E2E business solutions using new technologies. The
E2E solution extends the functionality of an organizations systems in a complex
enterprise wide IT environment while remaining true to the real world business
processes that must be executed to obtain competitive advantage. The powerful,
new technologies used to develop these processes are rapidly emerging. Against the
backdrop of these new capabilities, novel applications can be modeled, automated,
implemented, and executed to achieve competitive advantage.

RELATED PAPERS
This and White Papers on other related topics can be downloaded from
http://www.eiisolutions.net/

Copyright 2008 Enterprise Integration, Inc. All Rights Reserved.

20

IMPLEMENTING SAP FROM END-TO-END BUSINESS

PROCESS SCENARIOS

REFERENCES
Author Unknown (2001), mySAP Technology for Open eBusiness Integration, SAP White Paper,
Retrieved April, 2005 from [http://www.sap.com/solutions/netweaver/pdf/overview.pdf/]
Author Unknown (2005), iWay Universal Adapter Framework for SAP NetWeaver, iWay Software,
Retrieved April, 2005 from
[http://www.iwaysoftware.com/pdf/tech_brief/TechBrief_SAPNETweaver.pdf].
Author Unknown (2004), SAP XI 3.0 Adapter Framework. SAP AG, Retrieved April, 2005 from
[https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/com.sap.km.cm.docs/library/xi/3.0/SA
P%20Exchange%20Infrastructure%203.0%20%20Adapter%20Framework%20Overview_0_.pdf].
Author Unknown (2005), ARIS for SAP NetWeaver: The Business Process Design Solution for SAP
NetWeaver. IDS Scheer AG. Retrieved April 2005 from [http://www.idsscheer.com/international/english/products/aris_implementation_platform/31291].
Chou, D. et al. (2004), Model-driven Business Process Integration and Management: A Case Study with
the Bank SinoPac Regional Service Platform.
[http://www.research.ibm.com/journal/rd/485/zhu.html]
Clemmons, S. and S.J. Simon (2001), Control and Coordination in Global ERP Configuration, Business
Process Management Journal, 7 (3), pp. 205-215.
Eisenberg, R. (2004), Open for Business, Retrieved April, 2005 from
[http://www.intelligententerprise.com/showArticle.jhtml?articleID=19502159/].
Enterprise Services Architecture - An Introduction (2004), Walldorf, Germany: SAP AG.
Fotis, R. (2003). SAP Exchange Infrastructure: An Overview of SAP Integration Technology, SAP AG,
Retrieved April, 2005 from [http://www.sap.co.il/ppts/Rico%C2%B4s%20XI%20Overview.pdf].
Gulledge, Thomas and Georg Simon (2005), The Evolution of SAP Implementation Environments: A
Case Study from a Complex Public Sector Organization, Industrial Management & Data
Systems, 105 (6), pp. 714-736.
Gulledge, T.R., R.A. Sommer, and J.P. Vincent (2005), An Introduction to Basic Enterprise Resource
Planning Concepts, International Journal of Management & Enterprise Development, 2 (2), pp.
204-218.
Gulledge, Thomas (2005), What is Integration? Forthcoming in Industrial Management & Data
Systems.
Ho, C.F., W.H. Wu, and Y.M. Tai (2004), Strategies for the Adaptation of ERP Systems, Industrial
Management & Data Systems, 104 (3), pp. 234-251.
Hofreiter, B. and Huemer, C. (2004), Transforming UMM Business Collaboration Models to BPEL, Lecture
Notes in Computer Science, 3292, pp. 507-519.
Hurwitz, Judith (2003), Composite Applications: Leveraging Assets for New Business Models. CIO
Online, Retrieved April, 2005 from [http://www2.cio.com/analyst/report1726.html].
Jorns, C. Fit for SAP NetWeaver? Use the Potentials of Integrated and Innovative Processes in the Best
Way, IDS Scheer AG, Retrieved April, 2005 from [http://www.ids-scheer.com]
Leymann, F, Roller, D and Schmidt T. (2001), Web Services and Business Process Management.
[http://www.research.ibm.com/journal/sj/412/leymann.html]
Mecella, M. and Pernici, B. (2001), Designing Wrapper Components for e-services in Integrating
Heterogeneous Systems, The International Journal on Very Large Data Bases, vol. 10 (1), pp 2-15.

Copyright 2008 Enterprise Integration, Inc. All Rights Reserved.

21

IMPLEMENTING SAP FROM END-TO-END BUSINESS

PROCESS SCENARIOS

Medaille, P. (2004), Using SAP XI to Integrate Heterogeneous Landscapes. SAP Labs, Retrieved April,
2005 from
[https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/com.sap.km.cm.docs/library/xi/Use%2
0SAP%20XI%20to%20Integrate%20Heterogeneous%20Landscapes.pdf].
Okrent, M. and R. Vokurka (2004), Process Mapping in Successful ERP Implementations, Industrial
Management & Data Systems, 104 (8), pp. 637-643.
Schmitz, D. Lakemeyer, G. Gans, G. and Jarke, M. (2004), Using BPEL Process Descriptions for Building
Up Strategic Models of Inter-Organizational Networks. Lecture Notes in Computer Science, pp.
520-532.
Seebeyond.com (2005), Composite Applications and Service-Oriented Architectures, Retrieved April,
2005 from [http://www.seebeyond.com/resource/index.asp].
Volmering, T. and Scholz, T. (2004), A Shared Language for Business and IT, SAP AG, Retrieved April,
2005 from
[http://www.sap.info/index.php4?ACTION=noframe&url=http://www.sap.info/public/en/catego
ry.php4/Category-28943c61b1e60d84b/page/7/article/Article1304740f658013176e/en/articleStatistic/].
van de Loo, K. (2005), The SAP Business Process Platform, Presentation at the Burton Group Catalyst
Conference, 13 July, San Diego, California.
Volmering, T. et al. (2004). BPM in Practice: Modeling Business Processes. SAP AG. Retrieved April,
2005 from [https:/.../documents/a1-8-4/ BPM251%20%20BPM%20in%20Practice%20Modelling%20Business%20Processes.pdf].
Waloszek, Gerd. (2005), Crossing Boundaries with Composite Applications, SAP Design Guild Online,
Retrieved April, 2005 from [http://www.sapdesignguild.org/editions/edition7/intro_article.asp].
Woods, D. and Word, J. (2004), SAP NetWeaver for Dummies. Wiley Publishing Inc.

END NOTES
Hofreiter, B. and Huemer, C. (2004) Lecture Notes in Computer Science, 3292, 507-519.
Mecella, M. and Pernici, B. (2001) The VLDB Journal The International Journal on Very Large Data Bases,
10, 2-15.
Schmitz, D., Lakemeyer, G., Gans, G. and Jarke, M. (2004) Lecture Notes in Computer Science, 3292,
520-532.

Copyright 2008 Enterprise Integration, Inc. All Rights Reserved.

22