See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/240295903

Implementing SAP from end-to-end business process scenarios

Article  in  International Journal of Management and Enterprise Development · January 2006

DOI: 10.1504/IJMED.2006.009568

CITATIONS READS

19 4,607

6 authors, including:

Thomas R. Gulledge
George Mason University
123 PUBLICATIONS   1,107 CITATIONS   

SEE PROFILE

All content following this page was uploaded by Thomas R. Gulledge on 16 August 2017.

The user has requested enhancement of the downloaded file.

Int. J. Management and Enterprise Development, Vol. 3, No. 5, 2006 419

Implementing SAP from end-to-end business

process scenarios

Oldrich Bubak*, Robin Lee Farley,

Carsten Goebels, Pier Gonzalez,
Thomas R. Gulledge and Robert Russell
George Mason University
Mail Stop 2E4, Fairfax
Virginia 22030 – 4444, USA
E-mail: obubak@gmu.edu
E-mail: rfarley1@gmu.edu
E-mail: cgoebels@gmu.edu
E-mail: pgonzal2@gmu.edu
E-mail: gulledge@gmu.edu
E-mail: rrssll61@cs.com
*Corresponding author

Abstract: Business processes extend across functional and organisational

boundaries. In this ‘real world’, supporting information systems must be
implemented using an end-to-end 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 modelling 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.

Reference to this paper should be made as follows: Bubak, O., Farley, R.L.,
Goebels, C., Gonzalez, P., Gulledge, T.R. and Russell, R. (2006)
‘Implementing SAP from end-to-end business process scenarios’, Int. J.
Management and Enterprise Development, Vol. 3, No. 5, pp.419–437.

Biographical notes: Oldrich Bubak serves as a Software Engineer on a major

federal contract where he uses his ingenuity and creativity to implement
solutions to complex tasks. Mr. Bubak holds a MS in Systems Engineering with
specialisation in Computer Based Systems from George Mason University.
Among his interests are system architectures, enterprise integration, and
process improvement.

Copyright © 2006 Inderscience Enterprises Ltd.

420 O. Bubak et al.

Robin Lee Farley is a Research Fellow at LMI specialising in budgeting and

accounting systems and processes. He holds a BA in Political Science from UC
Berkeley, a Masters in Public Policy from Harvard University and is enrolled in
the PhD programme at George Mason University’s School of Public Policy.

Carsten Goebels is an IT Auditor. Mr. Goebels holds a BS in Computer Science

from Mary Washington College and is completing his MS in Enterprise
Engineering and Policy at George Mason University.

Pier Gonzalez is a Systems Engineer with Raytheon’s Intelligence and

Information Systems business unit. She holds a BS in Computer Information
Systems and is completing her MS in Enterprise Engineering at George Mason
University.

Thomas Gulledge is Professor of Public Policy and Engineering at George

Mason University and Director of the Policy Analysis Center within the School
of Public Policy. The Policy Analysis Center is working on issues related to the
economic, social, and technical aspects of Advanced Enteprrise Technologies,
Enterprise Integration, and Extended Enterprise Integration. The Policy
Analysis Center supports an extensive research program Extended Enterprise
Integration, with a special emphasis on Back-Office Integration and Supply
Chain Integration and Management.

Robert Russell is an Army Officer on Liaison with the US HQ Army Materiel

Command. He holds an EMBA and is completing his MS in Enterprise
Engineering at George Mason University.

1 Introduction

Traditional enterprise system vendor demonstrations assume that all organisational

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
idealised organisation are completely enabled by the mySAP software suite. While these
demonstrations are effective, they do not represent the ‘real world’, where organisational
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
vendor’s software solution) where End-to-End (E2E) business processes flow across an
enterprise and span many organisational 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 organisation’s 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
 Implementing SAP from end-to-end business process scenarios 421

composite applications that span the enterprise. This paper provides our version of such a
methodology. Our main contribution is the 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.

2 Background

Historically, organisations 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 organisation’s 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 organisational 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 materialised
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 characterise an organisation. In the
centre of these interfaced systems stands a complex and expensive enterprise application,
which has become the centre of corporate activity (see Figure 1). With its predefined 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 organisation. In
short, the competitive advantage of ERP is often compromised because organisations do
not implement the solution as it was intended to be implemented. As opposed to being
implemented as an enterprise-wide solution, ERP is implemented as a subcomponent of
the enterprise, and in some cases, even within an organisational stovepipe.
As noted, frequently enterprise system implementations produce a state of affairs
where the ERP solution becomes the ‘centre 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 ‘centre of the universe’
paradigm is being replaced by new enterprise solutions that support an end-to-end
composite application framework.
422 O. Bubak et al.

Figure 1 The ‘centre of the universe’ consequence of non-enterprise implementations

Sub-enterprise Scoping Diminishes

ERP Value Proposition
BCS3
JC2 FBCB2
J-CALS FCS

TLDD
BSM

TMDE DFAS
GCSS-
TC-AIMS II Army OSMIS

LMP
AALPS DIMHRS

IETM
LIDB

Legend TAV
OTHERS
Joint System All
ARMY System MC4 MTS Services
DoD System

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 end-to-end viewpoint
(see Figure 2) that flows unimpeded across the constraints imposed by information
system. Hence, where Okrent and Vokurka (2004) focus on those processes that fall
within system boundaries, we focus on those that flow inside and 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 ‘centre of the universe’ model
where all business processes are constrained by the interfaces across system components
as in Figure 1.
In the ‘real world’ scenario of Figure 2, there are also very real constraints. It was
previously stated that many organisations 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 organisations 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 organisation implement an end-to-end process across a complex heterogeneous
IT landscape?
 Implementing SAP from end-to-end business process scenarios 423

Figure 2 An end-to-end viewpoint required for true enterprise integration. In this approach, IT
supports the E2E business process

End-to-End Business Process Scenario

Create Accept Create Write Check
quotation order shipping list invoice payment

Sales Customer Clerk Group Clerk

staff management leader

Process
Flow Process
sequence

Shipping Payment Time

Inquiry Quotation Order Invoice
list received

Service Service Wrapper

CRM ERP Legacy

Legacy

3 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 components.3 Table 1 presents the general steps
that define the methodology.
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 provider’s 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 services.4
424 O. Bubak et al.

Table 1 Steps in a reference model approach to implementing composite applications

Step Description
1 Develop a business architecture.
2 Develop or procure a generic E2E reference scenario.
3 Align the reference scenario with the target organisation, 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 commercial
approach, such as ARIS.1
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 by
the system may be instantiated as an enterprise service.2
7 Synchronise 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.3
9 Test the E2E composite application.
1
Notes: 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/.
2
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.
3
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/).

4 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.

4.1 Reference models

When it comes to successful Business Process Management (BPM), it is important to
understand and be aware of three main items:
1 the business processes that are to be managed
2 how these processes compare against best practices
3 how these processes can be implemented in supporting IT systems that are available
to the organisation.
 Implementing SAP from end-to-end business process scenarios 425

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 model.5
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
organisations, 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 organisation. It may or may not be applicable to other
organisations, largely due to potential differences in the IT environment.6 Both can,
however, present a starting point against which an organisation’s 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
organisations and will easily allow an organisation 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 organisation’s 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 organisation 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 visualises a supply chain as different areas of
intra and intercompany 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
modelled 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’ UDDI7 reference
repository that identifies all the required objects that are available to assist in
implementing the new SAP paradigm.
426 O. Bubak et al.

Figure 3 A generic reference model for E2E order execution using the SCOR model for
organising the business objects

Suppliers Generic Order Execution Model – SCOR Backdrop Customers

Short term planning Mid term planning Long term planning

Production
Delivery Scheduling Transport Warehousing Distribution Marketing Strategy
Schedule planning

Demand
Load Workflow Route Factory Inspections Product Financial
layout forecasting planning
planning

Budgeting Detailed capacity Detailed materials Process

customer
requirements requirements requirements
order

Source Make Deliver

Manage Conduct
order release
relations Control costs
control

Manage Transport Manage Provide

Manage accounting
channels supplies inventory Load Manage
configuration support
product fleet

Manage Conduct
Establish Collect and Manage EHS
supplies product Pack Control
agreements analyze data
engineering product transport

Control
Source Procure Assemble Distribute Warehouse Deliver
Customize production
Supplies supplies order product product product product
activities

Measure
Return source Return deliver
performance

Provide
business
analytics

Provide
Return Return
customer
parts product
support

Product
accounting

Enable

Sales Collaboration R&D Marketing Human Relations

Manage
Regulatory Operations Information
ECommerce
compliance systems

4.2 Business process execution language

When creating a business process reference model in a software-based modelling
environment, a language known as Business Process Execution Language (BPEL) can be
used. BPEL is designed to serve as a structured modelling 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 synchronise and sequence transactions
between business systems to support a wider, integrated end-to-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 recognised 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 organisations have merged resulting in
BPEL’s 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.
 Implementing SAP from end-to-end business process scenarios 427

4.3 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. Web-based 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 (Hyper-Text 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.

4.4 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,
SOAP,8 WDSL9 and UDDI, can be used to allow disparate systems to communicate.
Utilising 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 organisation 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 et al., 2001). Identifying these key components will
facilitate the integrated solution needed to support web service activities. These web
services are orchestrated in accordance with a service-oriented architecture.

4.5 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 organisation 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
428 O. Bubak et al.

minimised. 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 realised 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 et al., 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.

4.6 Composite applications

In today’s 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, organisations 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).
Figure 4 represents an organisation, 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 customer’s order into the system for execution.

4.7 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, 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
 Implementing SAP from end-to-end business process scenarios 429

disparate system components. However, the challenge has been how to plan, build,
maintain, and utilise application server integration for real business cases. By ‘real
business cases’ we mean those that cut across an organisation’s internal and
external boundaries. Realising 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, SAP’s 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 summarised by
van de Loo (2005).

Figure 4 Example of a ‘place-order’ composite application

C OMP O SI TE
P lac e order AP PLI CA TION S

Proc es s c ust omer AS SE MB LY A ND

order ORC HE S TR ATI ON

B US IN ES S
S ER VI CE S

Chec k c us tom er Verif y c us tomer Look up c us tomer Determine produc t C alc ulat e s hipping
addres s c redit disc ount av ailabilit y c harges

EX IS T IN G
SY S TE MS

Custom er Data
M arketing S ystem s Sales System s Servi ce S ystem s Tr ad i ng Partner s
W arehouse

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

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.
430 O. Bubak et al.

5 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 customised 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 organisation, 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:
• What its processes are.
• How the processes can be integrated and improved.
• How new processes can be created to address changing business demands.
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
high-level architecture. Included in this architecture are the different views of the
company (i.e., systems, organisation, processes, etc.). The business process map of the
enterprise describes the company’s 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-to-end 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 conceptualisation of a
basic E2E scenario from which a company specific model can be developed.
 Implementing SAP from end-to-end business process scenarios 431

Technology can support this modelling 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 modelling toolset such as ARIS.10 ARIS can be employed as a stand-alone
product, and through a bidirectional interface, an E2E scenario can be synchronised with
the SAP Solution Manager11 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 predesigned models describe a business process, and can be customised for use,
and imported into ARIS. It is important to note here that sophisticated modelling tools
will assist in developing, configuring, and implementing the E2E process. The complete
process is presented in Figure 5.

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

E2E Scenarios in SAP NetWeaver

Customer Customer SAP Configuration
Business Process Business Process supported by Model
SAP components (and others) Solution Manager
Carries out & Supports Carries out & Supports

GCSS-A PLM+ LMP BSM GFEBS

Scenarios
GCSS-A PLM+ LMP BSM GFEBS

Requirement Requi rement

Identified Identified

Processes
Requirement Requirement
Identified Identified

Cr eate / Create and

Create and Create and Pr ocess Stock Send MRO
Send MRO Send MRO Transport

Process Steps
Order i...

Process
Reservation
Receive
MRO

Release Release
Stock
On- hand
Stock Not
On-hand Purchase Purchase
Pr ocess copied fr om LMP
Valid
On-hand
Not valid
On-hand
(System) ( System)
-> needs to be confir med Requisition Requisition
Proc ess copied from LMP
Syste... Syste...
-> needs to be confirmed
Send IDoc
Pick Item (Refusal
Notification)
Send Refusal
Pic k Item
Notifi cation Release Release
Purchase Purchase
Requisition Requisition

Item is Item is
Physically Physically
On Hand Not On Hand
Item i s
Item i s Physically
Physically Not On Hand Send IDoc
On Hand Post Goods
(Denial
Issue
Notification)
Send
Denial
Release Notifi cation
Item Item
Released

SAP Execution Exchange Infrastructure

Item
Print Physical Receive IDoc Receive
Released Inventor y (Refusal/Deni Refusal/
Document al) Denia...
Rec eive Receive
Block Stock Refusal/ Refusal/
Denia... Denia... Enter Count
Block Stock
Results

inc ludes all reasons

for physic al i nventory
Initiate
Inventory

Post
Inventory
Block Stock

Decide if
Backorder or
Block Stock

Decide if
Backorder or
Post
Inventory
Differences

Decide if
Backorder or
Decide if
Backorder or
Model
Results New Source New Source New Source New Source

Send

BPEL
Unblock Backorder Backorder Backorder Backorder
Inventory New Source New Source New Source New Source
Stock Proc essing Processing Processing Processing
Results

Resource Resourc e Send IDoc Resour ce Resource

Stock Proc ess Process Process Process
from from (Inventory from fr om
Unblocked Backorder Bac korder Backorder Bac korder
New Source New Source Results) New Source New Source

Send Status
to Customer
Send Status
to Customer
Send IDoc
(Status)
Send Status
to Customer
XI Execution
Receive
Status
Delete
Model
Reservation
Customer
Received
Status Customer
Received
Status

Rec eive Receive

Inventory Inventory
Rec eive IDoc Receive
Results Results
( Inventory Inventory
Results) Results

Unblock Unblock
Stock Stock Unblock
Stock

Adjust Adjust
Inventory Inventory Adjust Adjust
Balance Balance Inventory Inventory
Balance Balance

Update
General Update
Ledger Gener al
Ledger

General
Ledger Gener al
Updated Ledger
Updated

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 interrelate, and the
associated complexities of their interaction should also be noted. For example, how and
432 O. Bubak et al.

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 organisation 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 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, modelling 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 organisation, 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
 Implementing SAP from end-to-end business process scenarios 433

connected systems. A key component in the server is the adapter framework that enables
different applications outside of XI to communicate. Adapters (recall our 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 organisation 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
company’s 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.
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 re-use. 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.
434 O. Bubak et al.

Figure 6 Object sharing across the enterprise is accommodated by the SAP business
process platform

Models are a Key Element of the Platform

Business Suite

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

Enterprise ƒServices ƒObject models

Services
Repository ƒEvents ƒRoles
ƒProcess snippets ƒUI patterns

SAP OEM
Legacy/
Partner Legacy/ ISV
non-platform platform
Services 3rd Party components components 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

6 Conclusion

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 company’s understanding and capacity
to design integrated E2E business solutions using new technologies. The E2E solution
extends the functionality of an organisation’s 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 modelled, automated, implemented, and executed
to achieve competitive advantage.
 Implementing SAP from end-to-end business process scenarios 435

References
Clemmons, S. and Simon, S.J. (2001) ‘Control and coordination in global ERP configuration’,
Business Process Management Journal, Vol. 7, No. 3, pp.205–215.
Gulledge, T. and Simon, G. (2005) ‘The evolution of SAP implementation environments: a case
study from a complex public sector organization’, Industrial Management and Data Systems,
Vol. 105, No. 6, pp.714–736.
Gulledge, T.R., Sommer, R.A. and Vincent, J.P. (2005) ‘An introduction to basic enterprise
resource planning concepts’, International Journal of Management and Enterprise
Development, Vol. 2, No. 2, pp.204–218.
Ho, C.F., Wu, W.H. and Tai, Y.M. (2004) ‘Strategies for the adaptation of ERP systems’,
Industrial Management and Data Systems, Vol. 104, No. 3, pp.234–251.
Hofreiter, B. and Huemer, C. (2004) ‘Transforming UMM business collaboration models to
BPEL’, Lecture Notes in Computer Science, Vol. 3292, pp.507–519.
Hurwitz, J. (2003) Composite Applications: Leveraging Assets for New Business Models, CIO
Online, http://www2.cio.com/analyst/report1726.html (retrieved April 2005).
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, No. 1,
pp.2–15.
Okrent, M. and Vokurka, R. (2004) ‘Process mapping in successful ERP implementations’,
Industrial Management and Data Systems, Vol. 104, No. 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,
http://www.seebeyond.com/resource/index.asp (retrieved April 2005).
van de Loo, K. (2005) ‘The SAP business process platform’, Presentation at the Burton Group
Catalyst Conference, San Diego, California, 13 July.
Waloszek, G. (2005) Crossing Boundaries with Composite Applications, SAP Design Guild
Online, http://www.sapdesignguild.org/editions/edition7/intro_article.asp (retrieved April
2005).

Bibliography
Author Unknown (2001) mySAP Technology for Open eBusiness Integration, SAP White Paper,
http://www.sap.com/solutions/netweaver/pdf/overview.pdf/ (retrieved April 2005).
Author Unknown (2004) SAP XI 3.0 Adapter Framework, SAP AG,
https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/com.sap.km.cm.docs/library/xi/3.0/SAP
%20Exchange%20Infrastructure%203.0%20-%20Adapter%20Framework%20Overview_0
_.pdf (retrieved April 2005).
Author Unknown (2005) ARIS for SAP NetWeaver: The Business Process Design Solution for SAP
NetWeaver, IDS Scheer AG, http://www.ids-scheer.com/international/english/products/aris
_implementation_platform/31291 (retrieved April 2005).
Author Unknown (2005) iWay Universal Adapter Framework for SAP NetWeaver, iWay Software,
http://www.iwaysoftware.com/pdf/tech_brief/TechBrief_SAPNETweaver.pdf (retrieved
April 2005).
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.
436 O. Bubak et al.

Eisenberg, R. (2004) Open for Business, http://www.intelligententerprise.com/showArticle

.jhtml?articleID=19502159/ (retrieved April 2005).
Enterprise Services Architecture – An Introduction (2004) Walldorf, Germany: SAP AG.
Fotis, R. (2003) SAP Exchange Infrastructure: An Overview of SAP Integration Technology,
SAP AG, http://www.sap.co.il/ppts/Rico%C2%B4s%20XI%20Overview.pdf (retrieved April
2005).
Gulledge, T. (2006) ‘What is integration?’, Industrial Management and Data Systems, Vol. 106,
No. 1, forthcoming.
Hofreiter, B. and Huemer, C. (2004) Lecture Notes in Computer Science, Vol. 3292, pp.507–519.
Jorns, C. (2005) Fit for SAP NetWeaver? Use the Potentials of Integrated and Innovative Processes
in the Best Way, IDS Scheer AG, http://www.ids-scheer.com (retrieved April 2005).
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) The VLDB Journal The International Journal on Very Large
Data Bases, Vol. 10, pp.2–15.
Medaille, P. (2004) Using SAP XI to Integrate Heterogeneous Landscapes, SAP Labs,
https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/com.sap.km.cm.docs/library/xi/Use%20
SAP%20XI%20to%20Integrate%20Heterogeneous%20Landscapes.pdf (retrieved April 2005).
Schmitz, D., Lakemeyer, G., Gans, G. and Jarke, M. (2004) Lecture Notes in Computer Science,
Vol. 3292, pp.520–532.
Volmering, T. and Scholz, T. (2004) A Shared Language for Business and IT, SAP AG,
http://www.sap.info/index.php4?ACTION=noframe&url=http://www.sap.info/public/en/categ
ory.php4/Category-28943c61b1e60d84b/page/7/article/Article-1304740f658013176e/en/
articleStatistic/ (retrieved April 2005).
Volmering, T., et al. (2004) BPM in Practice: Modeling Business Processes, SAP AG,
https:/.../documents/a1-8-4/BPM251%20-%20BPM%20in%20Practice%20Modelling
%20Business%20Processes.pdf (retrieved April 2005).
Woods, D. and Word, J. (2004) SAP NetWeaver for Dummies, Wiley Publishing Inc.

Notes
1 See Gulledge et al. (2005) for background information on the basic concepts of ERP.
2 Integration is a word that means different things to different people. Gulledge (2006) describes
the usage context for ERP systems. In this case, the authors are referring to ‘Big I’ in the
classification scheme proposed by Gulledge.
3 See Woods (2004) for the definition of a Composite Application within the context of SAP
and non-SAP components.
4 Woods (2004) provides a management overview of enterprise services.
5 In general, a reference model could apply to any view of an architecture, such as data,
organisation, function, etc. We focus on the business process view, since that is the most
important for implementing ERP solutions.
6 A discussion of some of the organisational 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).
7 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/.
 Implementing SAP from end-to-end business process scenarios 437

8 The Simple Object Access Protocol (SOAP) is a lightweight protocol for exchanging
information in a decentralised and distributed environment. This XML-based protocol is
typically used with HTTP. SOAP is a key component for accessing and invoking a web
service.
9 Web Services Description Language (WSDL) is a specification for describing web services as
a set of end points operating on messages.
10 ARIS stands for Architecture of Integrated Information Systems. Additional information about
ARIS may be found at http://www.ids-scheer.com/.
11 For those not familiar with the SAP Solution Manager, see Gulledge and Simon (2005).

View publication stats