ERP Integration (U of Warwick)

UNIVERSITY OF WARWICK
ERP Integration
Foreword
Neil Davis
3/25/2010
Using information systems effectively has become a fundamental requirement for most businesses today. Enterprise
Resource Planning (ERP) systems have become the most significant systems by value that many global companies invest in
today so using them effectively has become critically important. This module considers the relationship between ERP
solutions and business processes; how this can confer competitive advantage if done well and the technologies that make
this possible.
CONTENTS
1. Introduction
2. ERP Basics
3. Process Alignment
4. Order Fulfilment
5. Company Structure in SAP
6. Sector and Industry Characteristics
7. Requirements Engineering
8. Business Process Modelling
9. Data Management
10. Master Data 1 (SD & MM)
11. OLTP & OLAP
12. Evaluation I
13. Master Data 2 (PP & CO)
14. Evaluation II
15. Technical Infrastructure
16. Process Integration
17. SAP NetWeaver
18. Business Intelligence
Author: Neil Davis ©University of Warwick (WMG) 2010 Page 1 of 1

ERP Integration
Introduction
Neil Davis
2/18/2010
This chapter introduces ERP systems in terms of their significance to modern business operations
and the role of information to knowledge workers. The size of the ERP market is reviewed and the
share of the business activity devoted to various aspects of ERP support. SAP’s ERP solution is
reviewed along with some conceptual foundations. The chapter finishes with a brief introduction to
workflow before concluding on the importance of understanding and knowledge in planning an ERP
solution.
Contents
1. Introduction .................................................................................................................................... 2
Global Competition............................................................................................................................. 3
Information Revolution....................................................................................................................... 4
Knowledge Workers............................................................................................................................ 7
Every Business is an Information Business ......................................................................................... 8
2. Introduction to SAP ERP.................................................................................................................. 8
Workflow...........................................................................................................................................11
3. Conclusion.....................................................................................................................................13
Key Reading.......................................................................................................................................14
Author: N. Davis ©University of Warwick (WMG) 2010 Page 1 of 14

ERPI Introduction
1. Introduction
Enterprise Resource Planning Systems have become the largest source of revenue in business
computing and information systems. AMR Research estimated in 2006 that global revenues would
expand at a compound annual rate of 11% through to 2011. The global credit crisis in 2008 and 2009
may have reduced this somewhat but nevertheless SAP’s software revenue alone grew from
€3.06Bn to €3.6Bn from 2006 to 2008 (the last year in which figures are available).
Today the ERP market is estimated to account for a total of $47.7Bn. This includes revenues from 5
sources: software licensing, maintenance, implementation, alternate pricing and delivery methods 1
and ‘other’ as shown below.
Of these the largest by far are licensing, maintenance and implementation which accounted for 98%
of all revenue in 2007. With the emergence of more capable means of hosting applications via the
internet, we might now expect the low percentage of 1% to have increased. Implementation costs
are a major issue for those wishing to invest in this technology and are closely related to integration
both as costs and benefits; we will return to this later.
SAP is the largest provider of ERP information systems with over 40% share of the market. Much of
this is provided from major accounts in larger firms, typically with more than 1000 employees. Many
smaller ERP companies exist that tend to serve firms in the small to medium (SME) sector, although
in most cases this will tend to be at the medium end of this sector.
1
For example, on-demand application serving.
Author: N.Davis ©University of Warwick (WMG) 2010 Page 2 of 14

ERPI Introduction
Failure to adequately support the implementation phase can lead to delayed and reduced
investment returns: systems are late and the planned benefits are not fully achieved. Financing the
implementation costs can sometimes mean diverting cash from buying the necessary software
modules with the result that integration benefits are reduced and business opportunities are
missed: there are gaps in the flow of information.
In this course we will seek to address the following questions:
 What is meant by integration in the context of Enterprise Resource Planning?

 Why is this important?
 How is it achieved?
First let us review the context in which Enterprise Resource Planning takes place.
Global Competition
Many of the products and services that we as consumers buy today are provided by organisations
that trade globally. From the computers that we download music to, to the media players and smart-
phones that we play them on; from the cosmetics and personal care products that we use and the
clothes we wear; from the cars we drive to the airport to catch the aircraft that we take on holiday
and the accommodation that we purchase in one country to use in another, these all result from a
complex network of activities that are performed, managed and distributed around the world.
Few organisations these days attempt to perform and manage all the activities in designing, making
and distributing goods and services. Instead, they tend to focus on a subset of activities that they
believe differentiates them either in cost, style, function, place or time. They then procure other
activities necessary and supporting services from suppliers or other partners. Thus, each firm tends
to focus on only a small number of core competences and buys-in or outsources the rest from the
market.
Outsourcing is not the only way companies collaborate; sometimes a firm may choose to re-locate
parts of its business into other countries in order to compete more effectively, this is off-shoring. At
first companies did this in order to gain access to overseas markets that were protected by trade
barriers and high import tariffs; they could only compete by having a physical presence in a foreign
market. Today, with more open markets and global trade agreements e.g. GATT2, off-shoring is seen
2
http://www.wto.org/english/tratop_e/gatt_e/gatt_e.htm

ERPI Introduction
as a way of gaining cost advantages by making exploiting cost advantages (often labour costs but
also transport and taxation costs).
Case Study – Apple Computer Inc/Apple Inc.
Apple Computer started out in business in 1977 making personal computers in California. It designed
and built its computers itself and sold them through specialist resellers. If you wanted an Apple then
you had to search quite hard to find where to buy them. There was no internet and no Google at this
time. As it, grew it established factories in Ireland and in Singapore but retained its reseller
channels, there were no Apple shops either at this time.
Apple Inc. now has a much broader product portfolio. It still makes computers (Macs) but also makes
software (Mac OS and iTunes), media players (iPod) and smart-phones (iPhone). Its revenues have
grown substantially and it is now seen as one of the dominant firms in the market.
Today, Apple doesn’t make anything itself, it concentrates on its core competence which is the
design and integration of leading technology with easy-to-use human interfaces. If you take a look at
the back of an iPod or iPhone it says “Designed by Apple in California. Assembled in China”. They
have also moved away from only using resellers to also having on-line direct sales channels in over
36 countries, shops, and also selling phones through the phone companies’ channels. There is now a
direct link between the end customer and Apple.
Apple has to coordinate a wide range of activities in their own business as well as with suppliers and
distributors. To do this they acquired an SAP enterprise system that helps them integrate design,
manufacturing and sales activities in a global environment. They have gradually evolved their
enterprise systems to incorporate more integrated business processes that rely increasingly on
information exchange, sharing and re-use.
Information Revolution
Information technologies have evolved rapidly during the first part of the Information Age – a period
of technological innovation and application that started in the 1980s and continues today. These
include hardware technologies for communicating and processing data such as digital computers,
cell phones and the internet in combination with software technologies such as operating systems,
software applications, the World Wide Web and Web2.0. The combination of hardware and
software used to achieve some defined aim is termed an information system and will typically also
include human users of such systems.
Information systems come in many forms and are used for many purposes but when they are
applied in the context of a whole firm there are known as Enterprise Information Systems.
Information systems may serve an individual user, a department or a group of people with shared
interests across organisations. When the scope of an information system includes multiple
departments and includes a majority of business transactions within a firm then it can be called an
Enterprise Information System.
Enterprise Resource Planning (ERP) systems are the most common form of Enterprise Information
Systems used in business today. These systems support a diverse range of functional requirements
for capturing, storing and processing enterprise information. Examples range from managing

ERPI Introduction
product information, to ordering materials, planning and executing manufacturing strategies to

managing sales and distributing products to customers. Warwick University uses SAP to manage its
finances and to procure goods and services.
Concepts
Information is data in context. Without a context data is meaningless. What does the following item
of data mean? .... ‘7’. By itself this data is meaningless, it could be 7 days in a week, the number of
letters between ‘A’ and ‘G’ in the alphabet, the number of apples in my bag... anything and nothing.
If I enter a query in an information system, Google perhaps: “How many days in a week” I get a
response 1 week = 7 days. The data ‘7’ now has a meaning and is now information that I could
use to calculate how many days there are in 3 weeks.
The term ‘information system’ can mean different things to different people depending on who they
are and what they are interested in. For some it can refer to any system – whether biological or
man-made in which information exists. For others it may have a more specific meaning for example:
Management Information System, Business Information System, Executive Information Systems …
and for those involved with ERP – Enterprise Information System.
The definition of Information System used here is based on that of Alter1.
DEFINITION: An information system is a type of system that uses information technologies to

capture, transmit, store, retrieve, manipulate, or display information in combination with other
systems or on its own.
The human body has many similar features to an information system. It can
capture information using its senses (sight, touch, hearing etc.), transmit
information via speech and writing, store and manipulate information in the
brain and nervous system and display information via gestures. In addition the
human information system is connected to a mechanism (the body) and
performs physical tasks or actions based on this information.
An Enterprise Information System (EIS) is used to plan and control the actions of one or more
organisations to achieve some business purpose. The primary aim of all commercial businesses is to
make money. In not-for-profit organisations the role is to deliver services at an acceptable cost.
For example, an EIS could be used to manage a factory, a supply chain or a healthcare system.
Information systems in business can be used to support internal and external users who can be
individuals or other systems. As shown below this can include customers and suppliers but also
regulators and shareholders, and can include competitors if the system is not secured.

ERPI Introduction
an Information system in context (based on Laudon).

Laudon)
The information technologies used by information systems have been classified historically
according to a software-hardware
hardware paradigm. Hardware refers to the devices that are used to
capture, transmit, store and display information. Software refers to the instructions that are used to
retrieve and manipulate information. Some software is used to manage the transmission of
information between places where it is stored and where it is manipulated. We often use the term
‘processed’ in place of manipulated.
Information
formation systems also exist at different levels within an enterprise and serve different needs as
shown next.. Executives and senior managers are interested in developing and monitoring strategies
and their impact, their interests are long term and mostly market and finance oriented. Senior and
middle managers are interested in implementing strategies by developing and managing business
units and facilities; their interests are typically medium term and mostly to do with planning
resources and developing tactics.
ctics. Junior managers and supervisors are interested in task execution
such as satisfying customer orders and operating plant and equipment, their interests are mostly on
day-to-day or even real-time
time systems to do with allocating resources and adding valu
value.
The roles of information systems at different levels.

ERPI Introduction
Knowledge Workers
For many organisations, information systems have been seen simply as tools to support individual
functions but people increasingly realise that information itself is the core of business. This should
not be surprising because the basis of commercial buyer-seller relationship always has been related
to knowing the value of something to a customer compared with the cost of acquiring it. Success for
the seller comes from the existence of an asymmetry in information: much of the seller’s
competitive advantage comes from knowing more than their customer and this is linked to the
difficulty the customer has in finding the same information.
Exploiting information to solve problems is the role of knowledge workers. These people are
involved in analysing and synthesising information to create knowledge that can then be used to
identify sales opportunities, improve product designs, reduce operating costs and find new ways of
engaging with customers. In short, knowledge workers drive the future capability and
competitiveness of a business; they do not carry out routine tasks: these are the role of task
workers. With the right access to information, knowledge workers can improve the performance of
all areas of business activity; there are roles for them in all business functions.
The identification of work that is based on generating and using knowledge, and its importance for
firms’ success in the future is relatively recent but many authors regard it as one of the key elements
of innovation to develop and sustain business performance in future years. The emergence of
information systems that can support knowledge work in recent years is leading to the emergence of
more firms that are knowledge businesses. These firms may not produce tangible outputs (in the
form of physical products) but they provide services to those that do. These services could support
internal operations in design and production or could be used to direct outsourcing and off-shoring
activities.
Knowledge workers bring benefits to organizations in a variety of important ways. These include:
 analyzing data to establish relationships  ability to brainstorm, thinking

 assessing input in order to evaluate complex broadly
or conflicting priorities  ability to drill down, creating more
 identifying and understanding trends focus
 making connections  producing a new capability
 understanding cause and effect  creating or modifying a strategy
These knowledge worker contributions are in contrast with activities that they would typically not be
asked to perform, including: transaction processing, routine work and simple allocation tasks.
However, there are also a set of tasks and roles that are seemingly routine but that require deep
technology, product, or customer knowledge to perform well. These include:
 providing technical or customer support

 handling unique customer issues
 addressing open-ended inquiries
Generally, if the knowledge can be retained, knowledge worker contributions will serve to expand
the knowledge assets of a company. While it can be difficult to measure, this increases the overall
value of a firm’s intellectual capital. In cases where the knowledge assets have commercial or

ERPI Introduction
monetary value, companies may exploit them but also need to protect them. In these knowledge-
intensive situations, knowledge workers play a direct, vital role in increasing the financial value of a
company.
Every Business is an Information Business

Although good enterprise information systems are potentially very useful they are of little value if
knowledge workers do not understand how to use them properly.
Many companies lost sight of the role of information technologies as a means of integrating business
function during the first part of the Information Age. Information systems were at first applied to
individual functional problems such as design, scheduling and accounting. There was very little
integration between these functions, partly due to technical limitations but also because of
organisational barriers caused by management structure and internal politics.
Finding ways to implement effective business processes has become the focus of many managers
over the last 10 years. However, many companies still fail to do this well: some start well but cannot
sustain their use of systems, some manage to implement parts of a system but don’t manage to
integrate the various parts together and some fail to do it at all. In addition, established companies
often have legacy information systems to support: they cannot afford to replace all systems at one
time. These often support functional requirements rather than process; this is sometimes referred to
as a ‘silo mentality’: a narrow view that only satisfies local requirements rather than the business as
a whole. The existence of functional information systems often causes problems when trying to
develop a more process-oriented approach. Issues of Process Alignment are discussed in a later
session.
2. Introduction to SAP ERP.

In 2008, SAP AG was the largest provider of ERP systems and services in the World with revenues
exceeding €11Bn and a share of over 32% in the enterprise software market. Its main product is SAP
ERP which is a major product within SAP Business Suite the major solution for large enterprises.
SAP also has an ERP product within its All-in-One solution for small and medium sized enterprises
(SME) but this is not discussed in this course.
The SAP software division includes applications such as SAP ERP, SAP All-in-One and SAP Business
Objects3, and platform technologies such as SAP NetWeaver on which many SAP solutions are built
and which third-party software developers can use.
3
SAP Business Objects solutions support more strategic information management. For example, mass
migration of data and complex analytical reporting .

ERPI Introduction
SAP Product and Service Portfolio (source: SAP Annual Report, 2008).
The SAP ERP solution has its origins when in 1972 a group of former IBM personnel set up their own
software company to market business software. The first solution was called R/1 and was a financial
accounting package. In the 1980s the company expanded to include MRP and MRPII capabilities on a
mainframe-terminal environment called R/2. In the 1990s the company introduced is client-server
product R/3 which was extended to include web technologies through to 2002. In 2003 SAP
introduced mySAP ERP which was based on the NetWeaver technology platform. This evolution of
the ERP product is shown above. The current version is simply called SAP ERP.
SAP ECC is the core of SAP ERP, it comprises the ERP Central Components, the elements that are
needed for a basic ERP capability across all of the functional areas that an ERP system must support.
Additional Components such as Internet Sales and Composite Applications operate on ECC, they
provide different access mechanisms and additional capabilities beyond those needed for basic ERP.
The SAP NetWeaver technology is the foundation and provides a framework for integration and
programming with ECC and external applications to create additional components (as seen in the
box above ECC in the next figure).

ERPI Introduction
The evolution from SAP R/3 to SAP ERP
SAP ERP is the most well know product in SAP Business Suite and forms its core around which other
products are based and can be integrated as shown following:
 PLM Product Life-Cycle Management for managing product information and especially
supporting the Engineering function
 CRM Customer Relationship Management for maximising the engagement with customers
and maintaining long-term relationships
 SCM Supply Chain Management for coordinating the activities with the external logistics
environment
 SRM Supplier Relationship Management for maintaining relationships with immediate
vendors.
SAP Business Solution Suite

ERPI Introduction
As shown above, SAP NetWeaver forms the technical platform on which SAP ERP is built and
integration is made with other Business Suite applications and external products.
An SAP solution map shows the various SAP ERP modules and the business areas or processes they
support. The boxes above and below the coloured area indicate new capabilities introduced since
R/3 Enterprise. For example, the Business Warehouse4 solution provides an information integration
using SAP NetWeaver technology. This enables the extraction of transaction information (e.g. sales
order history) into a business warehouse (a data repository) that can be used by Analytics to support
Strategic Enterprise Management amongst other things.
Fig 7 SAP ERP Solution Map 2004
note: the map is always changing as solutions are modified and added, so always check with SAP for
the latest version.
Workflow
Large enterprises are faced with significant costs and delays in handling information and moving it
between the various people who make things happen; this is less of a problem for small firms where
communication is generally much easier and more immediate. The types of thing that need to
happen could be raising orders, planning production, managing accounts, and many other processes.
There can often be significant delays as paperwork and reports are physically transported around an
organisation; documents can spend days sitting in in-trays; co-ordinating tasks is difficult; sometimes
important tasks could be started but people don’t realise this.
4
Now called Business Intelligence or BI.

ERPI Introduction
IBM example of a workflow scenario
(http://www.ibm.com/developerworks/architecture/library/ar-reqmod/Figure-1.gif)
Workflow refers to the use of information technologies that can automatically route information
around an organisation on the basis of its status and the availability of key workers to perform the
next task in a sequence or process. Contemporary ERP solutions such as SAP provide built-in
workflows that implement best practice processes. This allows them to remove much of the
mundane clerical work in moving information and reporting on it. It allows the people in an
organisation to concentrate more on performing or directly supporting value-adding tasks. It
improves the efficiency of processes and speeds them up.
SAP Workflow allows people using the SAP environment to participate in end-to-end processes
without wasting time trying to start tasks that aren’t in the right state (perhaps because information
is not yet ready), checking before starting that the state is right, waiting to find information from
other time zones, delaying tasks until a supervisor gives an explicit instruction. SAP Workflow is a
cross application tool that is independent of any particular module.
Workflows are initiated by events and respond to these by creating a set of related information
objects that are then passed between various actors (people or programs). The objects include items
of work and information. The sequence in which different actors receive objects depends on the
state of the objects and a set of rules that describe the process logic.
 Workflow Engine automates business processes

 Workflow can be triggered by events
 Each workflow consists of a sequence of steps

ERPI Introduction
 Steps can be activities comprising one or more tasks

 Each task requires a method to do something
 User decisions and other control actions can be specified in Steps
 A work-item is a run-time instance of a step
 Work-items are delivered to specified agents’ in-boxes (virtual workplaces)
 Agent selection can be made dynamically following the logic in a step
Components of a SAP Workflow Step (source: SAP Workflow in Plain English)
3. Conclusion
ERP solutions are often the most significant IT investment that firms make so their planning and
implementation is critical. They can provide significant benefits to firms using them but they need to
be understood and suitably managed for this outcome to happen. This requires skilled and
knowledgeable support from ERP vendors, consulting organisations and the end user customer. It
requires effective project management, a meaningful alignment between the human and system
processes and adequate training. It also requires commitment to working in a disciplined way that
respects the importance of the system to the business and does not regard the system as something
that just gets in the way of doing business.
ERP solutions are integrating tools: they bring people together so that they can collaborate in
performing business processes. These people could represent the interests and responsibilities of
different departments, firms and sometime even the customer. It is claimed that this closer
integration speeds up the execution of processes, reduces operating costs and improves customer
service. It is also true, that it can reduce the number of different information systems and reduce the
occurrence of data errors of various types (duplicate and conflicting data, missing data and data that
is simply wrong either out-of-date or incorrect).

ERPI Introduction
Key Reading
Strategy and the New Economics of Information. Evans P.B. & Wurster T.S., Harvard Business
Review, Sept-Oct 1997, p70-77.
IT Doesn’t Matter. Carr N., Harvard Business Review, 2002.
References
1. Alter, S., Information Systems: A Management Perspective. Addison-Wesley: Reading MA,
1999.

ERP Integration
ERP Basic: SAP Business Functions and
Integration
Philip Ian Foster
3/22/2010
This document will start at the beginnings of and reasons for the development of systems to support
the needs of expanding businesses and understand the evolution and drivers for ERP SYSTEMS. It will
cover the building blocks, purposes advantages, disadvantages and of the ERP and the modules and
discuss their uses by different sectors. A description and typical examples of the business functions
found within the SAP systems family, how they are integrated, where they are used, how and by
whom are they used. Examples of what benefits would be the expected through the successful
implementation of the SAP functions within a company and how these can be further exploited
between their customers and suppliers through successful integration.
Contents
1. Introduction .................................................................................................................................... 2
2. Drivers for change........................................................................................................................... 5
References ........................................................................................................................................10
Author: Philip Foster ©University of Warwick (WMG) 2010 Page 1 of 1

ERP Basics
1. Introduction
The History of ERP has been driven by the demands form industry, and manufacturing especially, it is
hotly debated, often challenged and always open for change.
In the beginning (as far as this document is focused) MRP evolved from the manufacturing sectors in
1960’s need to manage demand and ordering. No account was taken for timing or resources, only
need. MRP II was evolved quite naturally in the 1970’s to bring the demand and time phasing of the
demand into the planning process. At the same time as this evolution/revolution, across the ever
expanding and globalising manufacturing world; accounting management solutions where being
developed to meet these needs. ERP which had developed from the earlier MRP/MRPII systems,
were integrated with these emergent financial applications to provide a complete solution to a
company for managing their inventory, cash and people resources. [1]
Here is a brief time line of the history of ERP: [8]
1960’s
Enterprise Resource Planning (ERP) was first thought to be born in the early 1960s from a joint effort
between J.I. Case, the manufacturer of tractors and other construction machinery, and its prime
partner IBM. Although initially it was Material Requirements Planning or MRP that emerged as the
solution and was thus labelled and then sold onto many other industries across the globe. This
application served as the method for planning and scheduling materials for all complex
manufactured products and provided significant benefits to all key players in that process. [2] &[3] &[6]
1970’s
By the start of the 70’s the initial MRP solutions had become big, difficult to implement and use and
prohibitively expensive for the majority of medium to large enterprises. They required a large highly
trained technical staff to support the mainframe computers on which they run. They required an
extensive and continuous training program of all the user staff across all the key stakeholders in an
organisation and its supply chain to be truly effective. [3] & [6]
In 1972, five ex IBM engineers working in Mannheim Germany saw the opportunity to develop and
all encompassing system and thus begin the company SAP (Systemanalyse und
Programmentwicklung). The purpose in creating SAP was to produce and market standard software
for all integrated business solutions beyond the existing scope of the MRP systems. [4] &[6]
Others soon caught on and could see the potential growth in markets for such a system and in 1977
JD Edwards, and ERP provider was formed. Also in 1997 a company was launched named Software
Development Laboratories (SDL), which eventually became Oracle Corporation in 1982. In 1978 Jan
Baan begins The Baan Corporation to provide financial and administrative consulting services. In
1979 Oracle (then called Relational Software, Inc. RSI) offers the first commercial SQL relational
database management system. [5] & [6]

ERP Basics
1980’s
JD Edwards begins focusing on the IBM System/38 in the early 1980s. MRP (Manufacturing
Resources Planning) evolves into MRP-II as a more accessible extension to shop floor and
distribution management activities. [3] &[6]
1988 PeopleSoft’s Human Resource Management System (HRMS) is developed. [3] & [6]
1990’s
Going from strength to strength Baan software is rolled out to 35 countries through indirect sales
channels. The term ERP (Enterprise Resource Planning) is commonplace in the early and MRP-II is
extended to cover areas like Engineering, Finance, Human Resources, and Project Management. [3]
&[6]
1991 PeopleSoft sets up offices in Canada. This leads the way to their presence in Europe, Asia,
Africa, Central and South America, and the Pacific Rim. [3]&[6]
1995 Baan grows to more than 1,800 customers worldwide and over 1,000 employees. [6]
1999 JD Edwards has more than 4,700 customers with sites in over 100 countries. Oracle has 41,000
customers worldwide (16,000 U.S.). PeopleSoft software is used by more than 50 percent of the
human resources market. SAP is the world’s largest inter-enterprise software company and the
world’s fourth largest independent software supplier overall. SAP employs over 20,500 people in
more than 50 countries. To date, more than 2,800 of Baan’s enterprise systems have been
implemented at approximately 4,800 sites around the world. [6]
2000’s
2000’s – A combination of the Y2K problem and the dot com crash occurs in this period creating a
drop in demand for new ERP systems. [6]
2002 Most ERP systems are enhancing their products to become “Internet Enabled” so that
customers worldwide can have direct access to the supplier’s ERP system. [3]
2004 – Services Oriented Architecture (SOA) becomes a standard that ERP vendors work towards.
This software architecture allows different systems to communicate between one another. [6]
2003-2005 Industry consolidation occurs: [6]

Oracle – E-Business Suite, JD Edwards, Peoplesoft, and Seibel
Microsoft – Navision, Axapta, Great Plains, and Solomon
Infor – Baan, Mapics, and a slew of other products
Sage – Best Software is acquired.
Opened in June 2007, the SAP Co-Innovation Lab in Palo Alto, Calif. provides an efficient work
environment for joint projects with independent software vendors (ISVs), such as Novell, Questra
and Wonderware, system integrators (SIs) and technology partners to work together with SAP
around current and future technologies. Co-founded by Cisco, Hewlett-Packard, Intel and NetApp,

ERP Basics
the lab offers a hands-on environment and real-world performance for Web-enabled and
Internet/intranet-accessible business applications based on Enterprise SOA. [4]
The consolidations continue to occur and the key players (SAP, Oracle, Infor and Microsoft) continue
to build out their products. The next phase of ERP systems will be the merged products, including
Oracle’s Fusion and Microsoft’s project green’s end product. [6]
SAP claims to grow in contrast to its main rival, Oracle, which has been spending US$20 billion since
2004 acquiring 30 smaller competitors. SAP was able to increase its annual profits by 370% since
2002. [4]&[7]
In something of a departure from its usual organic growth, on 7 October 2007, SAP announced that
it would acquire Business Objects, the market leader in business intelligence software, for $6.8B [7]
2010’s
In January 2010 SAP did a U-turn on Enterprise Support and reintroduced its standard support
package for customers, saying the move was “a demonstration of its commitment to customer
satisfaction”. The move to reinstate standard support – at 18 percent of annual license fees, “will
enable all customers to choose the option that best meets their requirements,” the company said.
SAP has also announced that it is freezing prices for existing SAP Enterprise Support contracts at
2009 levels.[7]

ERP Basics
2. Drivers for change

Most businesses manage their affairs by making periodic reviews of various parameters. If we take
the simple example of retail outlets; typical shops examined their sales, stocks and orders on
suppliers every Monday. On any one Monday review they note sales are on the upward trend of a
monthly cycle, they would extrapolated the trend when placing forward orders, often failing to
predict or allow for the possible downturn. At their next review they would expect much higher
sales, but disappointedly had noted the actual lower ones, extrapolated again and forecast an over
over-
pessimistic future. A comparable process then repeats itself at each step back along the supply
chain. The delay inherent in translating the front end demand d fluctuation of 10% precisely to the
generated orders puts the control loop out of phase and converts the feedback from a damping
negative one to an amplifying positive one. The total system is inherently unstable and results in
either excessive stock being
ng held in the chain or periods of shortage when chain members are
unable to respond to the massive upsurges in demand. The figures 1 below demonstrates the issues
created by disconnected and under managed systems.
systems
Figure 1 Forrester effect [8]

ERP Basics
Fig 2 Current thinking based on the Forrester effect [8]
As markets expand and become globally competitive, OEM’s are transferring more and more
responsibility for manufacturing, design, sales and logistics down to the suppliers. These supply
chains are becoming complex and made up of companies from all over the world. The basic
MRP/MRPII systems can no longer cope with the vast amount of information generated from these
process and practices that have evolved to manage these large virtual organisations.
Just looking at the basic groupings of operations management in the different types of production
demonstrates how each product type has a unique requirement for volume and variety which will
always affect the choice of systems used by each organisation for f its major processes; design,
procurement, manufacture/production, sales & marketing, logistics, LCM, CRM etc.
Taking three examples, procurement, logistics and production; each function has its own grouping of
tasks and resource requirements. There are differing people skills, and some common, HR & finance
to name two, there are different equipment and infrastructure needs and there are different
customer and supplier relationships. To be a truly competitive, agile and profitable company it is
essential to be able to manage the use of all of the process, systems, relationships and costs across
the entire organisation. The larger the company is it follows the bigger the challenge is, and paper
based, non integrated systems cannot provide this support.
As can be seen in the Forrester effect,

effect a slight change at the top of a chain can have a significant
affect at the bottom; a deviation of up to 80% is accepted as experienced where there is no
integration. Below are 3 operations of company functions that exist exist in the modern global
organisation.
Purchasing
Most middle to large OEM’s no longer have a purchasing function, they have a procurement
strategy[10] often handled by a separate group of people and as can be seen in the slide
slide, this is made
up of a number of important and specialist roles and responsibilities. Each role or function within
that group relies upon up to date and accurate data to be able to achieve its minimal purpose and
objectives. There are a number of different roles and operations within that hat group, each with a
unique responsibility, purpose and skill that would require
require a fully functioning and integrated system
underpinning their daily operations to manage that effectively.

ERP Basics
Logistics
The same issue can be seen in the logistics operations were we have slide that has represented one
facet, physical distribution. The final tasks for the manufacturing of any item is how and where to
distribute it, and of course relates directly to the type and location of the end customer or purchaser
of that product, and it should be noted here these are two distinct entities. The end customer is the
person(s) who exchange money for goods / services and immediately use them, these would be the
public who by goods and commodities. A purchaser would buy an item, modify or enhance that
product, add some services, pay other 3rd parties to it and then sell the complete service onto the
end customer, these would be airlines, car hire etc. In the case of each the distribution of the
products creates a myriad of issues that would be dealt with in many different ways. Again there are
a number of different roles and operations within that group, each with a unique responsibility,
purpose and skill that would require a fully functioning and integrated system underpinning their
daily operations to manage that effectively.
Machine Throughput
Finally we there is a slide depicting a focused operation, the actual machining time in the
manufacturing process. Whether the product is a chemical, a pair of jeans or a complex aerospace
part the actual machine time for an individual piece of equipment is a small percentage of the
overall manufacturing lead. Every machine has a unique set of parameters depending on the
product being operated on, the material it is made of, any additional material requirements such as
threads, adhesive, fasteners, coolant, machine tools and a unique operation sequence. The majority
of companies strive to reduce the non-value add time of any machining process to ensure maximum
efficiency and minimum operating costs, one technique employed is depicted by the slide set-up
reduction. Again there are a number of different roles and operations within that group, each with a
unique responsibility, purpose and skill that would require a fully functioning and integrated system
underpinning their daily operations to manage that effectively.
The common factor in all of the above examples is information, data, knowledge and skills or a
combination of them all. The challenges all companies strive to overcome are discussed in the
vicious circle slide and require careful planning and effective communication and co-operation
across the entire set of process in the manufacture of any product. Against this backdrop are four
major elements that need to considered, the expectation of the customer and the share holder, a
recognition of where the real costs are and what is the completion doing.
Early MRP systems managed to deliver some of the solution if managing all the issues arising in any
organisation, but at a very focused and limited way. The definition of MRP as defined by the 9th
edition of the APICS dictionary is: A set of techniques that uses bill of material data, inventory data,
and the master production schedule to calculate requirements for materials. It makes
recommendations to release replenishment orders for material. Further, because it is time phased, it
makes recommendations to rescheduled open orders when due dates and need dates are not in
phase. Time phased MRP begins with the items listed on the MPS and determines (1) the quantity of
all components and materials required to fabricate those items and (2) the date the components
and materials are required. Time phased MRP is accomplished by exploding the bill of material,
adjusting for inventory quantities on hand or on order, and offsetting the net requirements by the
appropriate lead times. Therefore MRP only accounted for a small subset of the overall process. [11]

ERP Basics
This led onto the emergence of MRPII, which added additional functions and opened up a whole
new world of management control and optimisation. The definition of MRP II as defined by the 9th
edition of the APICS dictionary is: A method for the effective planning of all resources of a
manufacturing company. Ideally, it addresses operational planning in units, financial planning in
dollars, and has a simulation capability to answer "what if" questions. It is made up of a variety of
functions, each linked together: business planning, sales and operations planning, production
planning, master production scheduling, material requirements planning, capacity requirements
planning, and the execution support systems for capacity and material. Output from these systems is
integrated with financial reports such as the business plan, purchase commitment report, shipping
budget, and inventory projection in dollars. Manufacturing resource planning is a direct outgrowth
and extension of closed loop MRP. [11]
The inevitable evolution of MRP into MRPII and the success of these systems created another set of
challenges and problems which needed to be rectified and overcome. Efficiency in one area
highlighted deficiencies in others. One major headache for many mass production large volume
manufactures was the cost of inventory. Just In Time (JIT) [11] & [12] was already seen as the answer to
many issues plagued by modern manufacturing plants in the western world and was learnt from the
Japanese practices of controlling inventory costs through the use of appropriate and signals
(KanBan) [13]&[14] . Just in time is a ‘pull’ system of production, so actual orders provide a signal for
when a product should be manufactured. Demand-pull enables a firm to produce only what is
required, in the correct quantity and at the correct time.
This means that stock levels of raw materials, components, work in progress and finished goods can
be kept to a minimum. This requires a carefully planned scheduling and flow of resources through
the production process. Modern manufacturing firms use sophisticated production scheduling
software to plan production for each period of time, which includes ordering the correct stock.
Information is exchanged with suppliers and customers through EDI (Electronic Data Interchange) to
help ensure that every detail is correct.
Supplies are delivered right to the production line only when they are needed. For example, a car
manufacturing plant might receive exactly the right number and type of tyres for one day’s
production, and the supplier would be expected to deliver them to the correct loading bay on the
production line within a very narrow time slot.
Advantages of JIT
Lower stock holding means a reduction in storage space which saves rent and insurance costs
As stock is only obtained when it is needed, less working capital is tied up in stock
There is less likelihood of stock perishing, becoming obsolete or out of date
Avoids the build-up of unsold finished product that can occur with sudden changes in demand
Less time is spent on checking and re-working the product of others as the emphasis is on getting
the work right first time
Disadvantages of JIT

ERP Basics
There is little room for mistakes as minimal stock is kept for re-working faulty product
Production is very reliant on suppliers and if stock is not delivered on time, the whole production
schedule can be delayed
There is no spare finished product available to meet unexpected orders, because all products are
made to meet actual orders – however, JIT is still a very responsive method of production
It was inevitable that an ERP system would emerge as any innovative company would always seek a
way to overcome a major issue and many of the early MRP systems identified what was probable
and it too companies like Bann, Oracle and SAP to create the solutions. The modern ERP systems
provide as many solutions as they do problems and that is a separate subject. It is fair to say they do
as much or as little as an organisation is willing to invest the time, resources and money into
configuring, one matter is certain, the more stake holders use an ERP system , the more transparent
the whole chain becomes the greater the rewards are.
The slide depicts what an ERP system is designed to do follow on by a slide reminding us of the
evolution from MRP to modern ERP systems. The next slide describes the modules or functions of a
modern ERP system, which are the key stake holders for each group of functions all accessing a
common set of data, often created by a group or cluster of databases accessed globally when
required.
SAP offer a very comprehensive ERP system that allows companies to take, rather like picking a
selection from a menu, a group of services from a business suite of tools to satisfy their immediate
and individual needs. The services by role slide describe by role what is available followed by a image
of all the business suite segment followed by a map. The SAP solution map enables an organisation
to find a route to the optimum path selecting the most appropriate suite of tools for their needs.
Finally a typical example can be seen describing the fundamental stages required when designing a
solution to a successful implementation.

References
1. L. Wylie, "A Vision of Next Generation MRP II", Scenario S-300-339, Gartner Group, April 12, 1990
2. Anderegg, Travis, MRP/MRPII/ERP/ERM — Confusing Terms and Definitions for a Murkey

Alphabet Soup, http://www.wlug.org.nz/EnterpriseSpeak, retrieved 2007-10-25
3. http://ww2.itweb.co.za/sections/features/erp/feature0703050705.asp
4. http://www.sap.com/about/company/history/index.epx
5. http://www.oracle.com/oramag/profit/07-may/p27anniv_timeline.pdf
6. Journal of Operations Management Volume 25, Issue 2, March 2007, Pages 357-363
Special Issue Evolution of the Field of Operations Management SI/ Special Issue Organisation Theory
and Supply Chain Management
7. http://en.wikipedia.org/wiki/SAP_AG
8. http://www.erpandmore.com/erp-history/
9. Forrester J. (1961) “Industrial Dynamics” MIT, 1961.
10.http://www.plm.automation.siemens.com/en_us/Images/performanceBasedProc_tcm1023-
4862.pdf
11. http://www.wlug.org.nz/EnterpriseSpeak
12. http://tutor2u.net/business/production/just-in-time.html
13. http://www.infoq.com/articles/hiranabe-lean-agile-kanban
14. http://www.swmas.co.uk/transition/index.php/Kanban

ERP Integration
Order Fulfilment Process
davis_n
3/4/2010
This chapter considers one example of a familiar business process, namely the Order Fulfilment
process. It identifies the basic process, the various actors that are involved in its execution and the
role of information systems in supporting it. The chapter finishes with the outline and some screen
shots of how this process is supported by SAP ERP solutions.
Contents
1. Introduction .................................................................................................................................... 2
2. Basic Process for Sell-from-Stock Order Fulfilment........................................................................ 3
3. Information Systems for Basic Order Fulfilment ............................................................................ 5
4. Order Fulfilment in SAP (Demo)...................................................................................................... 8
5. Conclusion.....................................................................................................................................12
References ........................................................................................................................................13

1. Introduction
Order fulfilment is the process by which an incoming customer inquiry is converted into cash. It is
perhaps the most universal process in business because it is the process that completes the final
stage in the sales business transaction, whether it is for the provision of goods or services. This
process also includes the Order-to-Cash process but starts earlier with the receipt of an inquiry. It
can be represented using a process map as shown below.
Receive
Prepare Send Invoice To Receive
Customer Order Send Shipment
Shipment Customer Payment
(SO)
The Order-to-Cash process
As with many processes, the order fulfilment process involves actors from a range of business
functions. The actors can be the people who are employed to perform specific roles such as sales
order personnel or actors can be information systems in the form of applications. These actors
provide, manipulate and record information needed to identify what needs to be done, when it
needs to be done and by whom; what has been done, who says it has been done, how well it has
been done and what was produced.
Order fulfilment is not a single process but exists in different forms depending on the characteristics
of the local business environment, the nature of the firm and its customers and product/market
characteristics. For example, two different strategies exist to fulfil orders: sell-from-stock for
standard products that don’t vary significantly by market and for which demands can be forecast
with some precision; and configure-to-order when forecasting is unlikely to yield accurate results,
inventory holding costs are high and product variety is high (it is impossible in such situations to
stock every variant). In an engineering business these also influence other processes and how these
are configured. For example, if products are sold-from-stock then they are probably either
assembled-to-stock or manufactured-to-stock. Configure-to-order items are either made-to order or
assembled-to-order. In some cases the receipt of a customer order is the trigger to start engineering
work as is the case in civil engineering projects.
A single enterprise may operate more than one order fulfilment process, and will design these to suit
the needs of both customer and enterprise alike. Apple Computers for example operate a sell-to-
order process for products like the iPhone and iPod but a configure-to-order process for their
personal computer Mac products. The iPhone 3GS has only 4 variants across the world; they can be
black or white and have either 16Gb or 32Gb of memory. This level of variety can be easily managed;
warehouses can hold sufficient stock to absorb varying customer demands without carrying large
amounts so much stock and the risk of carrying obsolete stock is much reduced. Mac computers on
the other hand have much more variety in the processor, memory, hard-disk and power-supply
options before considering colour, operating system and pre-installed software choices. It is not
possible to hold enough stock to support the possible demand for each type so instead Apple
operate a configure-to-order process in which customers inquiries via web-pages are checked, prices
are calculated and then orders trigger selection of sub-assemblies and components to suit.

A number of needs must be met in order to complete the order fulfilment process successfully. This
must include not only making a purchase/sale but doing this in a way that both parties find
agreeable. Quality and service must be delivered at the initial contract stage but also in the transfer
and use of goods subsequently. Various ways exist of viewing this but the following steps provide a
reasonable overview1:
 Product search
 Comparison of alternatives
 Product selection
 Negotiation of terms
 Placement of orders
 Payment authorisation
 Receipt of goods
 After-sales support
2. Basic Process for Sell-from-Stock Order Fulfilment.

A sell-from-stock order fulfilment process starts with an inquiry from the customer about the
availability, price and delivery of the item required. The customer does not wish to waste time
placing an order for an item that is not available. If the item is a standard item and can be bought
elsewhere then another supplier could just as well support the customer’s need if the urgency of the
requirement is high and the price is acceptable. If urgency is not very important then the customer
will need to know when a delivery can be expected and this may be the subject of a negotiation. The
seller also needs to know the stock position because accepting an order that cannot be fulfilled often
causes problems later on.
If item delivery and price is acceptable then the customer will probably require some formal
confirmation of this. Likewise, the supplier may need to specify a time-period over which the price
and availability can be guaranteed. This may be important if the item is subject to price variations
and also because they may not wish to miss the opportunity of a sale in the future to another
customer. To satisfy both parties that they understand the terms of a following order the seller (or
vendor) may create a Sales Quotation and send this to the potential customer. Of course, many sales
transactions do not require such formal terms and no formal quotation may be needed.
Nevertheless, sales terms are often stated in sales documents, catalogs and on websites and legally
the buyers are expected to check these. It is only in retail sales that such terms are implicit because
the sale is transacted immediately, in person and payment is made in cash.
If the buyer is satisfied with the quotation (implied or explicit in the form of a quotation) then they
can proceed to place an order. This requires the creation of a purchase order (PO) by the buyer in
their business system. This may gain tangible form by means of printing or writing as a paper
document or remain in electronic form. Whichever is the case the PO will have a unique order
number in the buyer’s format that is used thereafter as a reference between the parties.
On receipt of the buyer’s purchase order, the seller must decide whether or not to accept the order.
The main reason for refusing an order is because the seller is not confident that the buyer will pay.

Unlike retail sales, business payments are usually made after the physical transaction is completed;
therefore the buyer is receiving credit from the vendor and if they don’t pay then it is costly to
recover this credit. Often the seller will need to perform credit checks on the buyer and this will
require the exchange of banking details prior to order acceptance. Buyers who repeatedly default on
payments, who pay late or owe more than an agreed amount, are put on ‘stop’: future orders will
not be accepted.
Assuming the buyer’s credit worthiness is acceptable then the seller can create a Sales Order (SO) in
their own business system. The SO will have a unique reference and will also refer to the buyer’s PO
for which it is raised. The SO will need to identify the internal reference identifier of the item
concerned (this may not be the same as the catalogue or web reference) and will also need to
identify the contact details of both the salesperson and the buyer.
The information on the sales order is used in combination with information from the Warehousing
and Inventory system to create an instruction to pick the stocked item. This needs to identify which
particular warehouse and storage location to pick from, the quantity of parts and any packaging
requirements. The choice of which location to service the demand from may depend on a range of
information including the buyer’s ship-to requirement and be determined by either manual or
computed means.
Staff in the warehouse pick the items listed on the picking instruction and need to record the
quantity and if there are any shortages. Inventory records in the vendor’s material management
system will be updated and may trigger replenishment Works Orders or Purchase Orders on
manufacturing or purchasing departmentsi. It may be necessary to marshal the items before
allocating them to packaging and transport. The final step before any shipment is performed is to
create a shipping document that accompanies the goods and may include customs documents and
care instructions. The fact that a shipment has been made also needs to be communicated to the
finance department for accounting purposes.
At a pre-determined time after shipment the vendor’s finance department will create an invoice
which is the request for payment. Sometimes the invoice will travel with the goods and sometimes it
will travel independently. The invoice will need to refer to the buyer’s PO number and to any
payment terms and discounts that were negotiated at either the quotation or purchase ordering
stage.
After the invoice period has passed, the vendor’s finance department will check that a payment has
been received and the amount that has been paid. If no payment has been made, or it is not what
was agreed, then a process of chasing the buyer starts. It is hoped that eventually this will result in
full payment but if not then legal remedies may be sought and the buyer placed on ‘stop’. The final
step is the transfer of the payment into the vendor’s account and a balancing of the accounting
ledgers (the ‘books’). When the PO was accepted and the shipment made then buyer’s account in
the finance system would be debited and the sales ledger credited, receipt of payment will create
balancing entries in these accounts and be reflected in the company’s balance sheet. This completes
the order fulfilment process: the customer has ownership of the goods and the vendor has payment
for these.
i
These are other business processes.

These steps are depicted in the following diagram which shows the customer interaction at the top
and the vendor across the centre. The bold lines indicate physical flows of information and material
(documents and products). A process map is shown towards the bottom; this includes three events:
The receipt of the potential customer’s sales inquiry, the receipt of the customer’s purchase order
and the archiving of a sales inquiry that does not result in a purchase order.
Customer (purchasing) Goods Receiving Accounts

payable
Accounts
Sales Sales Warehouse receivable
Accounting
Receive Purchase Pick & Prepare Create & send

Create Sales Order Send Shipment Receive Payment
Order shipment invoice
Receive Create & Send

Customer Inquiry Quotation
Archive
Quotation
Manufacturing
3. Information Systems for Basic Order Fulfilment

The opportunities identified here relate to business-to-business (B2B) order fulfilment which
requires a more formal exchange of details and negotiation than the business-to-consumer (B2C)
transactions that you may be familiar with as individuals. It is surprisingly difficult to carry out B2C
style transactions in firms because their processes often include a great deal of checking and
authorisation in order to maintain control of spending and protect organisational boundaries.
In the past, much if not all of the order fulfilment process was carried out using paperwork, often
using multi-part carbon-copy forms; the methods for handling these are slow and require much
administration compared with what information systems can now achieve. However, traditional
means of doing business can provide value that may be difficult to replicate with information
systems. For example, the inter-personal contact between two human beings wherein the seller can
offer advice, re-assurance and help elicit and elaborate true customer needs.

Sell-from-Stock businesses are associated with standard products that can be listed in on-line
product catalogues. Most firms selling standard products provide catalogues from which potential
customers can choose the products they want. One of the earliest uses of corporate websites was
the display of product catalogues in web form; ranging from simple copies of the hard-copy
brochure that can be viewed or downloaded using the web to more dynamic online catalogues that
present a richer and more easily updated source of information.
Online product catalogues provide much of the information needed to establish the terms of a
purchase but often not all. To begin with purchasers need to know the availability of stock and the
standard price and discounts. These can be provided via a web-based product catalogue, although in
some cases stock and price information may rely on periodic transfers of information via ‘batch’
jobsii that by definition give a historical rather than a current view of data. To provide an accurate
stock position particularly in a fast-moving business requires real-time processing of data. Even with
the latest high-throughput systems purchasers may still wish to negotiate prices and delivery and so
a personal communication follows the initial data-gathering phase. Not all businesses allow this
because it adds cost in employing sales order personnel. Amazon, for example, does not negotiate
its prices or delivery; their customers have become used to this but still use Amazon because the
service offered meets most needs (those who wish a personal service must visit a bookshop).
Additional value for the potential customer can be leveraged by the Sales organisation if they have
access to more than simple product catalogue information. In the past such value was added by
sales people exploiting their internal knowledge of company operations, personal relationships with
other members of staff in other departments, past experiences and access to unpublished and
sometimes confidential information. They may also have the ability to alter terms and conditions of
sale, either directly or indirectly through the management hierarchy. These assets and capabilities
are not impossible to deliver via electronic means but they are difficult. The difficulty is not that they
cannot be delivered but that a firm may wish to filter access to such information because it provides
a commercial advantage.
A Sales order quotations provides an opportunity for the seller to maximise the opportunity of a sale
by better understanding the purchasers needs and by matching these to a source of supply that will
meet them. The source of supply may be altered from a default location (a producing factory or
storage location) to an alternate that offers time or cost advantages; a different means of transport
may be chosen in order to achieve a delivery commitment; the sale may be transferred to a different
sales channel or organisation, possibly because the purchaser was initially unaware of their options
or this is the only way of capturing the sale (and this is financially worthwhile). This process is heavily
dependent on finding information quickly. Experienced staff are very valuable but unfortunately not
all are very reliable: they change jobs, sometimes forget and eventually retire. Information systems
provide a foundation for more efficient processes that are less reliant on people and more able to be
automated as computational techniques improve.
A quotation is a formal document that identifies the terms under which a following order will be
handled including the price, delivery, payment terms and the point at which ownership is transferred
ii
A batch job is a scheduled program that runs without user intervention. Corporations use batch jobs to
automate tasks that they need to perform on a regular basis but that would negatively affect the performance
of live systems, so they are executed overnight or during weekends.

to the buyer. Information technologies have been used to make sure quotations are delivered
quickly; at first people used faxes and more recently sent copies of quotation documents as e-mails
or e-mail attachments. In business these are usually followed up with a formal paper document sent
by post. The quotation document is identified with a unique reference code that the purchaser must
refer to when they place a subsequent order for which they wish the agreed terms to apply. In some
cases the quotation does not result in an order – the purchaser decides to select another source – in
which case the quotation becomes expired. Expired quotations will be archived and can be used as a
foundation for re-quoting at a later date.
Integration between purchasers and vendors information systems is limited at present and as a
result the first step in receiving a purchase order is not value adding but checking and translation.
Order details have to be checked against the order quotation if one exists. Systems must be in place
that make this easy, reference identifiers have to be formatted correctly and the original terms
made visible. These details then need to be transferred into the vendor company’s own format and a
Sales Order (SO) created. The prior existence of a quotation information record can significantly
reduce the cost and time associated with doing this, serving as a template for much of the required
information. The SO record standardises the varied format of data coming from external purchasers,
including orders received by telephone, email and fax.
The Sales Order is a key set of related information that triggers downstream order fulfilment
activities and also other related processes in manufacturing and procurement. The Sales Order
number is used to track the status of the order fulfilment process against which dates, times and
other remarks can be recorded for internal reporting and for providing feedback to customers.
Increasingly organisations are making this order tracking information visible to the customers. This
provides an added value to the customer (providing them with reassurance, hopefully) and also
reduces operating costs by removing some of the need for sales order personnel. Even Amazon has
some of these people but their contact number is not immediately accessible.
Successful picking of the Sales Order requirement depends on the accuracy of the Material
Management records and their visibility to the customer and sales team at the time of quotation and
order receipt. Without this, picking lists that are generated from the Sales Order requirements may
not be picked fully. When this happens, either a partly completed order is shipped or the order is
held until it can be completed. In either case the customer is disadvantaged and costs for both
parties increase. Customer and vendor have to engage in additional activities that neither wants,
and damages them both. Partial shipment can result in a significant amount of record processing
downstream in the finance department as multiple invoices, credit notes and possibly damages need
to be processed. The shipping function also need to see the order details of how the product should
be despatched, what transport mode should be used and when the delivery should be made.
Visibility of available stock and the ability of Sales to reserve or allocate this stock, so that it cannot
be sold twice or picked early, is a core requirement for achieving a smooth and cost effective order
fulfilment process. The information flows are bi-directional: stock position, location and shipping
options being fed from Materials Management to Sales and order requirements fed in the other
way.
Various documents are generated as material is moved and many opportunities exist to simplify and
streamline the processes for handling these. Every material movement needs to be recorded if the

firm is to keep accurate records of what is available and where it is located. Every movement can
affect the cost management of the business, the valuation of stock and the balance sheets of the
operating departments and organisational divisions. Information systems provide the means by
which this information can be handled in an efficient manner. This provides the means by which
management can monitor the business and identify where controlling actions need to be taken. This
is not effective unless the information records are accurate and up-to-date.
The final stages of the order fulfilment process take place after goods have been despatched and
have until recently had been mostly carried out using paper-based methods which were slow and
cumbersome. Increasingly firms are using automated bank credits to make payments but these rely
heavily on cross referencing the original purchase order details to the invoices that are sent out; the
origin of the payment must be clear so that the vendor organisation can identify which invoices are
outstanding.
4. Order Fulfilment in SAP (Demo)

Enterprise Information Systems like SAP provide the information handling foundations on which to
build effective business processes. They provide the means for individual organisational units to
record and manipulate the information they need to perform their tasks but as importantly they
provide the means to exchange the information that different actors need to share.
The need to share information between business functions and increasingly between organisations
does not mean that everyone can create and modify the information they choose. In all cases
information must be managed carefully so that its quality and integrity can be ensured. Therefore,
the definition and management of all information has to be allocated to the operating departments
that typically create it. For example, the Sales Organisation are usually expected to ‘own’ the
Customer information and Sales Orders, Materials Management ‘own’ the stock records and
generate the picking lists, Procurement own the vendor records and Finance own the payment
records.
Before any business process can be carried out in SAP, Master Data has to be created. Master Data is
the static information that is referred to when activities such as creating a Sales Order are
performed. For example, we need to know the address details for each customer that we sell to; we
need to know their bank account details and we need to know contact details. In large complex
businesses that serve a diverse range of markets in different territories and with different sales
channels we need to know which part of our organisation is responsible for dealing with each
customer and we need to know where to ‘post’ the accountsiii.
Master Data for a customer company Protec AG in the IDES systemiv is shown below. Customer
master data contains many values, some of which are mandatory (they must have entries) and
some are optional. For example, every customer has a unique Customer number, in this case
iii
When costs are incurred and payments are received we need to allocate them to the correct accounts, this is
known as posting. Posting to the wrong accounts will confuse management and make it difficult to identify the
profitable parts of the business.
iv
IDES is the SAP Education and demonstration Client which contains a predefined set or master data.

T-S66E01, a name (Protec AG) and a location (Hamburg, in Germany). The set of available fields and
the validation of values within these fields are set up by implementation consultants before the
system is handed over to users but default options and industry solutions are provided and one is
shown here. The data fields are organised into tabbed detail panes to aid in navigation and also to fit
them on the screen.
SAP Transaction VD03 – Display Customer
During the course of a accepting an order from Protec AG, the sales organisation staff need to
identify the correct master data so that relevant contractual terms, banking details and sales channel
information can be associated with the order. This data will be used later on in the process to select
transport methods and to invoice the goods supplied at the agreed price and with the agreed
conditions. Of course, the sales order also needs to identify the items on order so that the
appropriate stock records can be checked. Some of this information is shown in the next figure,
which also identifies that this customer master record relates to sales transactions made with IDES
AG. – the Company Code. Remember that master records exist at the Client level but refer to
operating units that are accounted for by company code at the organisational level. If Protec AG.
wants to conduct business with another company in the IDES Corporation then a master record for
this other company code would be needed too and it would have its own unique control and
account management information.

Company Code specific master data for customer T-S66E01 (Protec AG.)
Rec. Account 140000 is a reconciliation account in Financial Accounting (FI) that is used to receive
cash prior to posting it into the accounting ledgers. Before sales can be made there needs to be a
pricing structure for saleable items. In the following figure the Condition record for a motorcycle
(Item Master UCC-MOTORCYCLE-162) is shown with a base price of €3,999 for orders between 1 and
50; €3499 for orders over 50 and less than 500; and €3099 for orders of more than 500.
Pricing conditions for a saleable item in Sales Organisation 1000

It is now possible to create a Sales Order by using the Sales Order creation transaction, specifying
the Sales Organisation (which will be the organisation of the sales person who handles the sales
inquiry); the sold-to-party (in this case DAVIS); the item (UCC-MOTORCYCLE-162) and quantity (51).
These details are used to retrieve the customer master data, the material master data (for example
the weight, 22491 Lbs) and the condition record to obtain the correct pricing (in this case the
previous discount value means a price per item of €3499) and calculating the Net Value of €178449.
Order Detail screenshot for Document 10209
This demo gives a quick run-through of some of the process steps and how they are supported using
SAP ERP; how the information systems retrieves master data to complete a transaction and create a
Sales Order document. Much more data would normally be included and could be used to calculate
taxes and shipping costs for example.
The Sales Order document is then used to create a pick list in the Warehouse system but
unfortunately there is no stock in any storage locations at the moment for this item and therefore
no pick list can be created (there would be no point and the system logic knows this); we can create
a delivery document (Document record 80013660) in the system but its status will remain ‘open’.
Only when there is stock at the shipping point will it be possible to despatch the goods.

Status Overview for Sales Order 10209
5. Conclusion
We have seen how a common business process requires the interaction of a number of actors who
must exchange information in order to negotiate the conditions of sale, authorise orders and fill
these with the necessary information for other actors downstream in the process to do their tasks.
We have discussed the opportunities provided by information systems to support this process and
how the SAP ERP solution makes this possible. During the course of the demonstration a number of
roles have been portrayed in order to explain how master data entered by different groups of
people supports a range of transactions (stages in the process and operations on information in SAP)
needed to complete a very important business process.
Master data from the following modules has been used in this demonstration:

References
1
E-services and their role in B2C e-commerce, Mohini Singh, Managing Service Quality; 2002; 12,6; pg. 434.

ERP Integration
Company Structure in SAP
davis_n
3/1/2010
This chapter discusses the role of management structure in large organisations and the typical form
that this can take, particularly in engineering businesses. It then looks at how company structure can
be implemented in SAP and the particular meaning and structure of Organisational Levels in SAP. We
identify Client, Company Code, Plant/Division, Warehouse and Storage Locations.
Contents
1. Introduction .................................................................................................................................... 2
2. Stages of Business Growth.............................................................................................................. 2
3. Management Structure................................................................................................................... 3
Techno structure................................................................................................................................. 6
4. Organizational Levels in SAP ........................................................................................................... 7
5. Discussion......................................................................................................................................11
Author: N Davis ©University of Warwick (WMG) 2010 Page 1 of 12

1. Introduction
The structure of a business can either be a drain on resources and a drag on performance or can
simplify business processes and free-up innovation; information systems have a role in both of these
scenarios. Large organisations in particular, unless they have a well thought out and managed
structure, are prone to slow-paced decision making and unresponsive processes. In contrast, small
and medium sized organisations are renowned for their entrepreneurial style and flexibility.
Most successful businesses start small and then grow organically by retaining and reinvesting profits.
As they grow businesses typically expand their activities, acquiring more capital assets, and
employing more people. Management structures are created to help the owners control the
business and monitor the flows of expenditures and revenues. At some point the ownership of the
business might be expanded and shares issued (although some businesses may continue to be
dominated by a single owner or family group).
The rate of organic growth is limited by profitability and to increase growth beyond this point a
company may seek to either acquire new business through purchasing them or by merging with
another business. Revenue growth can also be achieved through a process of partnership, for
example a joint venture. The acquisition of new businesses brings benefits such as economies of
scale and access to new markets but it also introduces integration problems. These can be
managerial or technical leading to overlapping processes, confused responsibilities and fragmented
information.
The geographical scope of many businesses also grows alongside its general growth, giving rise to an
international dimension. International activities first in sales and later perhaps other areas such as
manufacturing will inevitably lead to a need to manage more complex accounting processes,
currency transactions and taxation data.
This chapter reviews the typical stages of business growth and different organisational structures
used to manage these. It discusses how failure to match the implementation of an ERP system with
company management and process structures can lead to problems and it then introduces the
approach to representing organisation in SAP.
2. Stages of Business Growth

The conventional management model regards business growth as a sequence of stages starting with
a small start-up company and leading to an established and mature company. In this model
expansion into international markets typically comes after a long period of organic growth.

Increasingly however, companies are exploiting modern internet-based communication technologies

to short-cut this process and move more quickly into international markets.
Most businesses involved in manufacturing start from the introduction of some new concept, a new
product, a new market or a new way of selling. The business creator is usually an entrepreneur
seeking to establish themselves and make an independent and profitable concern. They proceed
through a difficult period of inception, of breaking into the market and getting known. After this they
need to survive as costs typically grow before revenues follow until they reach a more stable
foundation from which they can grow the business and expand their goods or services into new
markets. As they grow they acquire more ‘reach’ through a process of information diffusion (word-
of-mouth and experience). As they become mature they can then consider acquisition or themselves
become a target for acquisition.
3. Management Structure
The ‘classical’ approach to structuring an organisation which has been applied for centuries in
armies, governments and business is the management hierarchy. This is typically superimposed on a
functional organisation so that each functional department has its manager and this manager has
subordinates who may be either managers or workers. For an engineering business the functional
structure will typically include: Engineering (Design), Manufacturing, Purchasing, Sales and Finance
departments.
In large organisations further organisational units called divisions may be introduced above the
functional hierarchy when either the span of control becomes too great or in order to segment the
organisation for accounting purposes, for example. A division may be autonomous to some degree,
even having its own financial accounts, or it may be a purely administrative construct with operating
budgets but no separate financial identity. For example, Siemens AG (a global industrial company)
had 15 Divisions in 20091 operating within 3 main sectors and 2 cross-sector businesses (Financial
Services and IT Solutions & Services). Total revenues for the corporation for 2008 exceeded €77Bn2
and the group of companies employed over 427,000 people world-wide.
1
Siemens Status 2009 http://w1.siemens.com/press/pool/de/homepage/the_company_2009.pdf
2
Consolidated Statements of Income. Annual Report 2008, Siemens AG. www.siemens.com/annual-report

Fig 1. Siemens AG: Sectors and Divisions 20091
At an operational level a pure hierarchical structure can slow down decision making because
information has to be communicated up the ‘chain of command’ for decisions to be made. The need
for this arose initially because of the asymmetric nature of information within businesses: only the
managers had access to information and only the information relevant for their level within the
organisational structure. These structures provide only a limited reach for information; it is not easy
to communicate the rich information needed for effective decision making very far. Many busy
processes cut across functional boundaries so to make a decision about process may require a
‘ripple’ of information flows and decisions up, across (to another functional department) and then
down, then up, across and back before action can be taken. In addition, large hierarchies tend to
become overly bureaucratic with many non value-adding costs associated with administration and
vested interests whose aim is solely to build power and influence – empire builders.
To better support decision making for managing processes that are focussed on adding value for
customers, some companies operate a matrix style of management in which responsibilities are
shared between function and process orientations. For example, in many engineering projects a
designer may have a hierarchical reporting accountability to their functional design manager and a
‘horizontal’ reporting accountability to the project manager. Day-to-day tasks and management of
issues related to the project are managed by the project manager and longer term organisational
issues are managed by the functional lead. Effectively, the designer is sub-contracted to the project
manager for the duration of the project. The benefits of matrix organisations include faster decision
making, better access to resources and information, increased communication all of which it is
hoped lead to better service to customers (internal and external).

Fig 2a. Matrix Organisation at Toyota
(source: The Toyota Product Development System, Morgan & Liker, Productivity Press, 2006)
Fig 2b. Matrix Organisation at Toyota with Development Centres
It is possible to extend decision making in an organisation through better use of information

technologies either within conventional hierarchies or, as has been suggested by some, through
network structures.. Whilst it is possible in a matrix organisation to extend the reach of a richer set
of information
nformation than was previously possible this is achieved by physical means - because people are
collocated and operate in multi--functional
functional teams. In such cases it becomes much easier to share rich
information amongst a wide group of people, reduce the asymmetry
asym metry of information and promote
more effective decision making that is nevertheless based on good information rather than
guesswork.
Information systems provide an opportunity to deconstruct value chains in business by extending

the reach of richer information
mation throughout an organisation without reference to organisational

structures3. This was made possible by internet connectivity and openness, by destroying the
asymmetry of information and reducing transaction costs. It has been argued that this may lea lead to a
fundamental rethink about the way in which businesses are organised and even their identity,
resulting in what has been termed a ‘Hyperarchy’ [Davenport 97]. A hyperarchy is a form of network
structure that is loosely coupled, meaning that it is not a fixed structure but can form and reform in
different ways to suit its needs.
Techno structure
This term is used to describe the planning and control systems used in manufacturing and other
types of organization to capture and share knowledge for decision
decision making which is a significant part
of the role of an ERP system.
Minztberg [Structure
Structure in Fives: designing effective organizations,
organizations, Prentice Hall, 1983 HN5000.M4]
identified six organizational components of which the Technostructure can be seen on th the left in Fig
1. Modern ERP systems didn’t exist when Mintzberg proposed this model and today we might argue
that ERP systems overlap with the operating core.
Fig 1. Mintzberg’s six parts of the organization.
3
Only if the organisation does not impose restrictions on access to the information sources.
In fact, many organisations do impose such constraints because management are conc concerned
about confidentiality or because they feel threatened by the loss of power over knowledge.
“knowledge is power” Sir Francis Bacon,
Bacon Meditationes Sacræ. De Hæresibus. (1597)
English author, courtier, & philosopher (1561 - 1626)

The challenge for integrators of ERP systems is to determine what elements of the portfolio of ERP
modules are required to support the operating core? How well does the existing ideology of the
organization and behaviour of its operating core match the expected behaviour of these modules?
Following on from this the implementers must address the issue of adaption: what elements of the
system will be adapted to the existing core processes and what core processes will be adapted to
suit the system? This is dealt with in the Implementation session later.
4. Organizational Levels in SAP

All information in an SAP ERP system is organised according to a series of levels. These help manage
the master data in a way that helps reduce duplication and helps check its validity. They are also
used to represent the enterprise in terms of its legal and business-related purposes such as
management accounting. For example, an inventory storage location for a particular component
used in the manufacture of a product should be associated with the correct factory; it should not be
possible to record a stock level for the component in the wrong factory.
Fig 2. Organizational Levels
Fig 2 shows an example of organizational levels in a typical manufacturing business and how these
are mapped into SAP. The organizational levels are hierarchical so, for example, a Company Code is
at a lower level than a Client; it cannot contain a Client but a Client can contain a Company Code.
Plant is an organisational level associated with production and is often associated with a factory site.
Plants are the organisational unit associated with production planning and materials management. A
company code can contain one or more plants and plant can contain multiple storage locations. An
individual item of stock, a raw material or a part-finished product can be stored in one or more
storage locations that can exist in one or more plants.

Storage locations in SAP
Various organisational units can be described at the client and subsidiary levels. These are used to
manage and record master data and transactions for management purposes. In this example a Sales
Organization with a number of sub-units is shown mapped into an SAP organization level called Sales
Organization which can have one or more Divisions, this is in the context of Sales and Distribution:
the SD module. Purchasing Organisation is another organisational unit that can be defined, this time
in the context of Materials Management in the MM module.
A Client in SAP is the highest organizational level and it represents the enterprise as a whole.
Therefore, there is only one Client in an SAP ERP implementation for each corporate group or
enterprise. So, for example, Siemens corporate headquarters might be represented as a Client.
NOTE: Client in this context should not be confused with the term Client in hardware systems.
A Company Code is a unit included in the balance sheet of an enterprise and is a legally independent
unit; it is the central organizational element of Financial Accounting in SAP ERP, for example,
Siemens AG. A client can contain one or more company codes, these do not necessarily represent
business units but rather the countries in which business activity takes place. Siemens AG. has
operations located around the world and each of these will be represented by a company code
within SAP.
In multinational companies each country in which operations take place – where costs are incurred
and/or revenues received – is often organised as a company code in SAP. This is not a business
choice but a result of countries legal requirements to report for taxation and regulation. There are
often differences between countries in the way that business activity is reported therefore a single
company code that spans countries is not normal. Even within single markets such as the EU a single
accounting code does not automatically exist although steps have been made towards the adoption
of the IAS standard4. Individual member states still requires independent accounts so that they can
levy appropriate taxes. The company code is the level at which financial accounts are prepared in
the FI module of SAP.
4
IAS – International Accounting Standard now termed IFRS – International Financial Reporting Standards

Most companies need to monitor, account and record business performance for related activities
across countries; In SAP it is possible to create various aggregates to do this. A Controlling area is an
organisational unit for the purpose of cost accounting that can include one or more company codes.
It is possible therefore to perform cost accounting in the CO module of SAP that aggregated activity
in more than one company code and the costs can be rolled up into charts of accounts for financial
reporting in FI.
Organisation Levels in Management Accounting (CO)
SAP also allows the creation of Business Areas that can also span companies and can be used to post
results to for internal business analysis. Examples of business areas might include different business
sectors; in the case of Siemens AG for example these might be Industry, Energy and Healthcare.

Business and Controlling Areas in SAP
In SAP, sales are made through Sales Areas; these define the Sales Organization responsible for the
sale, the distribution channel that makes the sale and the Division (usually product related). In the
context of Siemens AG, within their Industry sector of operations they have divisions for Motors &
Drives, Automation, Building Technologies, Mobility and Lighting (OSRAM).
Sales Areas in SAP
In the Human Capital Management (HCM) module SAP allows the creation of Personnel Areas. These
represent the way in which personnel are administered within a company code and are unique

within a Client. Each Personnel Area can contain one or more Personnel subareas such as
Headquarters, Production and Sales.
Personnel Organisation in HCM of SAP
There are many other ways in which both master data and transaction information is organised
within SAP.
5. Discussion
It may seem that there is a potential conflict between the formal organizational levels present in
most ERP systems –like SAP- and the suggestion of management thinkers and theorists to
deconstruct these and allow more fluid hyperarchies to develop. Formal hierarchies may be suited
to companies that are differentiated from their competitors by their products and services rather
than the way in which these are delivered: the process. For these, a formal organizational
configuration may provide strong support for efficient and controllable delivery mechanisms and
provide management with the level of control that they feel comfortable with. Those organizations
that consider a more flexible approach is needed must consider carefully how they structure their
organizational levels so that these do not inhibit or overcomplicate their more fluid business
activities. They need to choose between a relatively abstract structure that doesn’t require much
maintenance but will also not give much ability to analyse and control, and a more detailed structure
that will require frequent updating to keep up with a changing organisation.
When firms invest in ERP systems like SAP to help manage their business activities, the ultimate
success of such actions depends to a large extent on the way in which the systems are configured.
Companies have two broad choices when implementing ERP systems: they can either seek to tailor
or ‘configure’ the solution to match their current structures and business processes or they can
adapt these to suit a pre-configured solution.

System configuration is a complex subject; SAP ERP has many hundreds of configuration tables and
requires deep knowledge to implement. Most organisations need to hire the services of specialist
firms to do this as they are unlikely to have these skills or be prepared to develop them internally.
This is costly and time consuming.
Adopting a pre-configured solution may seem at first to be a limiting choice but in fact is becoming
the preferred solution for many firms who then only configure small parts of the system where it is
felt that this confers on them a competitive advantage. We will return to these issues in a later
chapter.

ERP Integration
Sector & Industry Characteristics
davis_n
3/10/2010
This chapter identifies how an understanding of the characteristics of a firm can be used to identify
the configuration parameters of an ERP solution. It discusses the concept and role of Industry
Solutions in supporting this and gives a brief overview of SAP’s approach to this at a product level. It
concludes with a summary of the key points.
Contents
1. Introduction .................................................................................................................................... 2
2. Sectors of Application for ERP Systems .......................................................................................... 3
3. Classification Schemes .................................................................................................................... 3
Economic Classification....................................................................................................................... 3
Classification by Product/Market ....................................................................................................... 5
Classification by Ordering and Scheduling.......................................................................................... 6
Classification by Business Size ............................................................................................................ 7
4. SAP Business Solutions.................................................................................................................... 8
5. Conclusion.....................................................................................................................................11
References ........................................................................................................................................12

1. Introduction
Enterprise Resource Planning systems must by definition serve the needs of an enterprise but these
vary according to the nature of the sector in which they operate. Therefore, it is not reasonable to
suggest that a single ERP solution can exist to serve all customers equally. It is also not realistic to
expect a customer to pay for functions that they don’t need and can’t use. However, with very few
exceptions (monopolies, for example) every enterprise or firm operates within one or more sectors
and sectors have common characteristics. By understanding these characteristics it should be
possible to identify the features that any implementation will need to include and then look at
specific requirements that an individual firm may want to suit its unique requirements (ones that
differentiate it from competitors in its sector).
When planning for ERP either in the pre-sales phase, during detailed sales proposal or after contract
-during configuration and implementation-, a selection of required system functions has to be made
from the set of available functions. In SAP ERP and its associated Business Suite solutionsi, the set of
available functions is very large indeed. Licensing costs are directly related to the functions that are
required and these are followed by annual maintenance, training costs and ongoing support costs. If
the set of selected functions exceeds what a customer needs then the investment may be too
expensive. If the set of functions is less than the business needs then the firm may fail to generate
the revenues or other performance benefits that are needed and the firm’s competitive advantage
may be eroded (or not achieved).
In SAP, business functions and processes are supported by combinations of software functions and
application tools that are configured within SAP modules. Examples of such modules include
Materials Management (MM), Financial Accounting (FI), Sales and Distribution (SD) and Asset
Management (AM) to name just a few. Very few if any businesses will acquire all of the modules on
offer as they simply don’t need them all.
Having recognised the need to accurately identify the required functions and the SAP modules that
deliver them it should be recognised that these rarely get funded completely. Most firms that make
investments in ERP don’t have unlimited budgets, in fact they have limited budgets. The final
selection of modules and functions is often made on the basis of what can be afforded rather than
on purely technical or operational considerations. It is important to recognise this limitation and be
pragmatic during the selection phase. It is important to make sure that the final selection delivers a
meaningful solution even if this is of reduced capability. One should not simply cut out an entire
module from the selection because some cost target can be met by doing so if this means that a
fundamental requirement cannot be met.
Understanding the characteristics of a customer through the sector(s) that it operates in is a

fundamental pre-requisite to identifying requirements and configuring a solution.
i
PLM, SCM, CRM and SRM. Also ‘analytics’ such as Business Intelligence

2. Sectors of Application for ERP Systems

ERP systems originated in manufacturing industry but have recently been adopted in service
industries and in public administration, each has different needs.
There are a number of ways of classifying and dividing sectors into increasingly differentiated sets.
The most basic is to differentiate between Service and Manufacturing organisations. Services in fact
dominate economic activity in most developed economies but have less complex needs1. For
example, SAP identify three high level sectors:
 Financial and Public Services

 Manufacturing
 Service
Each of these is subdivided in ways that allow them to group their ERP capabilities in meaningful
ways for different customer groups. Before looking at this in detail we will consider some more
general classifications.
3. Classification Schemes
In addition to high level sector classification there are also low-level divisions that can be useful in
categorising the needs of firms from an information systems perspective.
Economic Classification
Most economies will maintain some kind of classification of economic activity, in the UK these are
known as SIC codes. They are used by various organisations to monitor the level of activity, to
characterise applicants for grants, report on imports and exports and much more. This classification
is not specifically ordered for information systems analysis but is included because it identifies the
major groupings and is recognised in most economies.
SIC codes are used in many countries but can have different meanings and format. There is a move
towards standardisation to which end many economies, the UK included, are beginning to adopt the
UN International Standard Industry Code (ISIC) which has the following high level structureii:
 A - Agriculture, forestry and fishing

 B - Mining and quarrying
 C - Manufacturing
 D - Electricity, gas, steam and air conditioning supply
 E - Water supply; sewerage, waste management and remediation activities
 F - Construction
 G - Wholesale and retail trade; repair of motor vehicles and motorcycles
 H - Transportation and storage
 I - Accommodation and food service activities
 J - Information and communication
 K - Financial and insurance activities
 L - Real estate activities
 M - Professional, scientific and technical activities
 N - Administrative and support service activities
ii
http://unstats.un.org/unsd/cr/registry/regcst.asp?Cl=27&Lg=1&Top=1

 O - Public administration and defence; compulsory social security

 P - Education
 Q - Human health and social work activities
 R - Arts, entertainment and recreation
 S - Other service activities
 T - Activities of households as employers; undifferentiated goods- and services-producing activities of
households for own use
 U - Activities of extraterritorial organizations and bodies
Manufacturing is defined as the physical or chemical transformation of materials, substances, or

components into new products, although this cannot be used as the single universal criterion for
defining manufacturing (see remark on processing of waste below). The materials, substances, or
components transformed are raw materials that are products of agriculture, forestry, fishing, mining
or quarrying as well as products of other manufacturing activities. Substantial alteration, renovation
or reconstruction of goods is generally considered to be manufacturing.
Units engaged in manufacturing are often described as plants, factories or mills and characteristically
use power-driven machines and materials-handling equipment. However, units that transform
materials or substances into new products by hand or in the worker's home and those engaged in
selling to the general public of products made on the same premises from which they are sold, such
as bakeries and custom tailors, are also included in this section. Manufacturing units may process
materials or may contract with other units to process their materials for them. Both types of units
are included in manufacturing.
The output of a manufacturing process may be finished in the sense that it is ready for utilization or
consumption, or it may be semi-finished in the sense that it is to become an input for further
manufacturing. For example, the output of alumina refining is the input used in the primary
production of aluminium; primary aluminium is the input to aluminium wire drawing; and aluminium
wire is the input for the manufacture of fabricated wire products.
Manufacture of specialized components and parts of, and accessories and attachments to,
machinery and equipment is, as a general rule, classified in the same class as the manufacture of the
machinery and equipment for which the parts and accessories are intended. Manufacture of
unspecialized components and parts of machinery and equipment, e.g. engines, pistons, electric
motors, electrical assemblies, valves, gears, roller bearings, is classified in the appropriate class of
manufacturing, without regard to the machinery and equipment in which these items may be
included. However, making specialized components and accessories by moulding or extruding
plastics materials is included in class 2220.
Assembly of the component parts of manufactured products is considered manufacturing. This

includes the assembly of manufactured products from either self-produced or purchased
components.
Within sector C (Manufacturing) the following sub-sectors are identified:

 10 - Manufacture of food products  22 - Manufacture of rubber and plastics

 11 - Manufacture of beverages products
 12 - Manufacture of tobacco products  23 - Manufacture of other non-metallic
 13 - Manufacture of textiles mineral products
 14 - Manufacture of wearing apparel  24 - Manufacture of basic metals
 15 - Manufacture of leather and related  25 - Manufacture of fabricated metal
products products, except machinery and
 16 - Manufacture of wood and of equipment
products of wood and cork, except  26 - Manufacture of computer,
furniture; manufacture of articles of electronic and optical products
straw and plaiting materials  27 - Manufacture of electrical
 17 - Manufacture of paper and paper equipment
products  28 - Manufacture of machinery and
 18 - Printing and reproduction of equipment n.e.c.
recorded media  29 - Manufacture of motor vehicles,
 19 - Manufacture of coke and refined trailers and semi-trailers
petroleum products  30 - Manufacture of other transport
 20 - Manufacture of chemicals and equipment
chemical products  31 - Manufacture of furniture
 21 - Manufacture of basic  32 - Other manufacturing
pharmaceutical products and  33 - Repair and installation of machinery
pharmaceutical preparations and equipment
Table of U.N. ISIC classification for the manufacturing sector.
Within the manufacture of food products sector (C10) there are further divisions as follows. This is
the final level and provides the complete classification. For example, C105 is the manufacture of
dairy products.
 101 - Processing and preserving of meat

 102 - Processing and preserving of fish, crustaceans and molluscs
 103 - Processing and preserving of fruit and vegetables
 104 - Manufacture of vegetable and animal oils and fats
 105 - Manufacture of dairy products
 106 - Manufacture of grain mill products, starches and starch products
 107 - Manufacture of other food products
 108 - Manufacture of prepared animal feeds.
Table of U.N. ISIC classification for the manufacture of dairy products.
This means of classifying firms does not in itself yield a completely meaningful way of characterising
the firm on an operational level. For example, the methods and equipment used in making dairy
products use Process Engineering technologies for the processing of milk as fluids but meat
processing tends to be done in batches using more discrete manufacturing methods. The processing
of fruits and vegetables includes both flow types manufacture and batch manufacture depending on
whether the product is to be preserved or used within a limited shelf life. A more operational way of
classifying firms is needed to help select necessary ERP functions.
Classification by Product/Market
Market classification is a useful way of grouping together companies that are probable competitors
by virtue of the products and services they sell. They are likely to share many operational

characteristics, particularly at the customer interface but also in the internal processes they use.
They are likely to develop similar approaches to the way they do business as they seek to remove
any competitive advantages that arise over time. For example, the market for personal computers
has been revolutionised by the techniques established at Dell Computers. Direct selling via the
internet has been copied by many of Dell’s competitors to such an extent that one would expect that
any sales and distribution software for the PC market should include a direct selling capability.
Market classification can include more than a single dimension because not only the type of product
bust also the level of activity determines the processes that need to be supported.
Classification by Ordering and Scheduling

In the manufacturing sector firms and operations are often classified according the way in which
they respond to customer orders, at which point in the order cycle they carry out design and
engineering and how they organise and schedule their production facilities. The nature of the
manufacturing system will vary from company to company and from industrial sector to sector. It
will depend in part on the volume and variety of products made and the technologies used in the
various transformation processes. It will also depend on the strategies that firms use in order to
compete with one another.
Manufacturing can broadly be split into two main types: Discrete and Process. These are quite
different in nature: discrete refers to products that can be individually identified and handled;
process refers to products that are not discrete, for example fluids, fabrics, chemicals and many
types of raw material. The number of businesses engaged in process manufacturing is quite low
compared to the number of firms engaged in discrete manufacturing. Therefore the focus of this
chapter is devoted to discrete parts manufacturing. Examples include, automotive (cars, trucks and
buses), aerospace (aircraft) and consumer white goods (household appliances) but there are many
more.
Within the discrete manufacturing environment there are a number if different types of system
related to the volume and variety of products made. Mass or Flow production is at one extreme,
often supported by high levels of automation. The system uses dedicated resources that have
limited flexibility. Examples of this are found in car making and household appliances. At the other
extreme are project and job shop manufacturing that operate with low volumes, often only 1-off in
the case of project work. This type of system uses general purpose equipment and can achieve high
levels of flexibility. Between these is batch manufacturing that operates on products intermittently
(in batches) using a mix of general purpose and dedicated equipment depending on the nature of
the contracts (their value and duration). Examples include some defence projects, spares business
and industrial equipment.
The flow of material through a manufacturing system can also be used to distinguish them. As shown
in the figure below, these range between runners: jobs that are in constant flow (typically these are
associated with mass production); repeaters: jobs that are intermittent but repeat (associated with
batch manufacturing); and strangers: jobs that occur once or rarely and cannot be predicted
(associated with project or job-shop manufacturing).

These classifications also map onto different ways in which orders and products are managed and
the manufacturing systems must be designed to suit this. Stranger type business is often managed
on an Engineer-To-Order (ETO) basis: an order is placed first and only then is the product designed
and manufactured. This type of business is often managed on a project basis and might be
associated with capital projects like construction projects and machine or automation system
building. A Make-To-Order (MTO) basis is when the product is already designed but isn’t built until
an order is received. Assemble-To-Order (ATO) businesses may pre-make components and sub-
assemblies but do not assemble these until an order is received. An example might be in industrial
equipment like pumps where the customer specifies the final configuration for their particular need.
Finally, we have Make-To-Stock (MTS) which is the case where me make in advance on the basis of
forecasts and then sell from stock. Note: increasingly MTS is augmented by late-stage configuration
to suit individual customer requirements; this is known as late configuration.
Process Discontinuous
discontinuous
Repetitive
Strangers ETO MTO ATO MTS
unconnected
batch
Repeaters
process/
connected
project Job shop repetitive continuous/
batch
flow
continuous Runners Source: Lean Enterprise Systems, Bell S., Wiley 2006.
Slack’s classification and idea:
Organisation and methods should reflect the pattern of demand
Product
Volume Strangers Repeaters Runners
Source: Operations Management, Slack N., Prentice Hall,2003.
Variety
Adapted from: Lean Enterprise Systems, Bell S., Wiley 2006
ERP solutions for manufacturing businesses reflect these different characteristics. There are
configurations of SAP ERP to suit process industry, batch manufacturing, mass and flow lines. There
are also modules and functions that support MRP-based control using PUSH techniques as well as
Lean techniques using PULL methods.
Classification by Business Size
There are differences between the way large and small firms organise themselves, the resources
that are available to them and their attitudes towards risk and change. These influence both the
ability of a firm to acquire information systems and their ability to absorb technology and use it
effectively. ERP systems for different sizes of business differ in the way they are presented to
potential customers, in the range of functions supported and in their technical foundations.
Large organisations tend to develop sophisticated techno-structures that have the ability to support
a wide variety of information system technologies and functions. These firms often have individuals
dedicated to quite narrowly defined tasks. User training can be focussed and post training practice

can be immediate, with significant opportunity to improve skills through repeated practice. Users
are able to gain familiarity with quite complex tasks and system options because they are specialists:
they can learn a narrow task in depth.
Smaller organisations tend to have simple, flatter management structures and people perform a
wide range of tasks; there aren’t enough employees to permit complete specialisation in all
functional areas. It is difficult for most users to learn a wide variety of system operations in depth
and therefore these firms tend to need simpler systems that are easier to operate. They also need to
be cheap and easy to implement and maintain.
The sophistication of techno-structure influences the ability to absorb and operate information
systems. Smaller organisations often don’t have professional systems administrators and therefore
they need easy to operate and familiar technologies (typically PC and Windows based). These can be
delivered using a combination of vendor developed applications and low-cost, sometimes free,
supporting software such as databases. Current supporting infrastructure often uses Apache web-
servers, MySQL or SQL Server databases and even free operating systems such as Linux.
The E.U. standard for classifying firms by size identifies them using three criteria: headcount
(number of employees and directors), turnover and balance sheet total (major asset value).
Micro Small Medium-sized

enterprise enterprise enterprise
Headcount < 10 < 50 < 250

Turnover ( €million) <=2 <=10 <=50
Balance sheet( €million) <=2 <=2 <=43
E.U. SME Definition 20082
Any firm that exceeds these figures is classified as a large business. In the U.S. there is a slightly
different classification, the terminology is slightly different – they use the term SMB - but the intent
is broadly the same; the thresholds are at 100 and 500 for small and medium businesses
respectively.
Software companies and IT consultancy businesses often apply a different classification using the
SMB terminology. IBM for example use the term ‘mid-size’ to refer to smaller organisations but their
headcount boundaries are much higher at 100, 1,000 and 5,000 employees respectively. Other
major IT companies such as SAP and Oracle apply similar rules.
SAP in common with other information services companies have a differentiated product offering
based on company size. In the mid-size sector SAP have positioned SAP Business One solution and
for large organisations SAP ERP.
4. SAP Business Solutions

In common with other types of large complex systems such as Product Lifecycle Management (PLM)
solutions, SAP ERP can be delivered in a pre-configured form to suit a general business requirement.
In SAP these are referred to as SAP Business Solutions.

SAP also market ERP as a part of their Business Suite of products and highlight four main areas of
application: Financials, Human Asset Management, Operations and Corporate Services. For example,
Warwick University Finance department operates its processes using a configuration that is founded
on SAP Financials. The complete set of modules and a model of how they relate to each other is
provided by the SAP Solution Map that we have discussed before. For memory, here it is again.
SAP Industry/Business Solutions are not defined in a completely coherent way and depending on
where you are and when you look at the information they provide you will find slightly different
emphasis.
At the overall solution level they identify three main segments: Financial and Public Services,
Manufacturing and Services. Within Manufacturing they identify over 10 sub-segments.
The Services segments focus on businesses and organisations that don’t need to provide a tangible
product. In these sectors enterprise information systems are mostly engaged direct customer
contact, the exchange and manipulation of knowledge assets and the management of human and
financial resources. The Manufacturing segment as might be expected focuses on business that need
to manage physical resources as well: materials, part-finished goods, saleable products and the
management of capital assets (plant and equipment).

SAP Segment Industry Solution

 Banking
 Defense & Security
 Healthcare
Financial and Public Services  Higher Education & Research
 Insurance
 Public Sector
 Aerospace & Defense

 Automotive
 Chemicals
 Consumer Products
 Engineering, Construction & Operations
 High Tech
Manufacturing
 Industrial Machinery & Components
 Life Sciences
 Mill Products
 Mining
 Oil & Gas
 Media
 Professional Services
 Retail o
 Telecommunications
Service
 Transportation & Logistics
 Utilities
 Wholesale Distribution
Table of SAP Industry Solutions3
In comparison, INFOR (one of SAP’s competitors) also provides a set of industry solutions for
its ERP customers4, these include: Automotive; Chemicals; Consumer Packaged Goods; Food
& Beverage; High-tech & Electronics; Industrial Equipment & Machinery and Metal
Fabrication.
In some manufacturing industries, the management of physical assets takes a major role in other
cases, material flow and scheduling are most important, in some what matters is the efficiency with
which material can be picked and despatched. In each case, during pre-sales and detailed planning,
consultants and a firm’s own personnel must work together to identify the key business processes
that must be supported and the key information that is needed to run and monitor the business.
This is particularly important when budgets are limited in advance; it is important to avoid specify
functions that aren’t significant for the business.

5. Conclusion
ERP solutions for large organisations, in particular, are complex and powerful but include more
capabilities than most firms need. The solutions for smaller firms are simpler and concentrate on the
main business processes that most firms need in order to operate i.e. they are less likely to include
unnecessary features.
No business wants to pay more than they need to, nor wants to have to administer systems and
applications that aren’t used. When selecting and specifying a large ERP solution like SAP ERP, most
firms will need to identify and configure only those capabilities that they really need.
Configuring a large ERP system from ‘scratch’ i.e. starting with either a wholly generic or with a
completely empty datasetiii, is a very complex, time consuming and expensive task. To reduce the
cost of configuring large ERP solutions and hasten the time to implement them, ERP vendors have
increasingly applied Industry Solutions.
Industry Solutions provide pre-defined datasets and processes that are designed to suit particular
application domains in Manufacturing and Services. The task for ERP sales and implementation
teams is to help identify the most appropriate industry solution for potential customers and work
with them to identify how best to align this with existing and future requirements. This then has a
significant impact on training plans, project costs and ultimately on the performance of the systems.
iii
A dataset is a set of existing master data and configuration tables.

References
1
An Investigation into the use of ERP systems in the service sector, Botta-Genoulaz V., Millet P-A.,
International Journal of Production Economics 99 (2006) 202-221.
2
The New SME Definition: User Guide and Model Declaration, EU Commission 2005
http://ec.europa.eu/enterprise/policies/sme/files/sme_definition/sme_user_guide_en.pdf accessed 11th
March 2010.
3 th
SAP website http://www.sap.com/industries/index.epx accessed 11 March 2010.
4 th
INFOR ERP website http://www.infor.co.uk/solutions/erp/ accessed 11 March 2010,

ERP Integration
Requirements Engineering
davis_n
3/11/2010
This chapter considers the way in which a definition of requirements for ERP can be obtained. It
briefly reviews traditional software development approaches because these may be relevant in
some instances, particularly when developing user-specific add-on capabilities. For the more general
case we review the way in which BPR techniques are applied to identify current and next processes
as a pre-condition for configuring an Industry Solution.
Contents
1. Introduction .................................................................................................................................... 2
2. Software Development Approaches............................................................................................... 2
Requirements Elicitation..................................................................................................................... 4
Requirements Evaluation.................................................................................................................... 5
Requirements Specification and Documentation............................................................................... 5
Software Design and Implementation ................................................................................................ 6
3. Prioritising Information Systems Requirements............................................................................. 6
4. Business Process Reengineering and SAP ERP Requirements ........................................................ 8
5. Matching SAP Modules .................................................................................................................10
6. Conclusion.....................................................................................................................................11
References ........................................................................................................................................12

1. Introduction
Early business information systems were often built from first principles and required the writing of
bespoke code for which various approaches have been developed; this is called software
development. It is also termed systems development when it involves the integration of
independent or partially independent software application or modules, each of which is the result of
a software development process.
The need for detailed systems development is much reduced in today’s enterprise information
systems (EIS) environment in which more attention to configuration rather than coding is needed.
Modern EIS exploit changes in software design that make it easier to assemble new systems and
support new and revised processes by re-using existing code. The issue for systems designers and
implementers is how to configure these assemblies? Designers – possibly external consultants,
vendor and customer representatives- need to identify which functions are to be re-used and in
which order they should appear as part of a workflow.
Nevertheless, many firms decide they need some software support for unique processes and
particular functions that may not exist in the legacy or off-the-shelf systems they have, and this
requires software development. Therefore, in any project to implement a new ERP systems there
will be requirements to identify configuration parameters for existing software and also to specify
original software.
2. Software Development Approaches

Software Development is a multi-facetted problem that can be costly and time-consuming; done
well it can contribute significantly to business performance but done badly it can cause chaos and
damage performance. The different facets (or aspects) of this problem include eliciting knowledge,
project management, analyzing processes and data, designing software, coding and testing, training,
deployment and maintenance1.
Software development is a process that starts with the identification of a project and ends with
maintenance; the process has also been termed the Software Development Life Cycle (SDLC) and is
shown in the following waterfall model.
Classic Waterfall model of systems development1

The classical waterfall approach is a sequential process in which the required tasks must be carried
out in order and only when completed can the next task start. In practice such a sequential process
was probably never fully followed as people will always tend to assess the implications of decisions
at one stage on later actions.
Spiral model of software development1
The spiral model recognises this and sees the sequence of activities being repeated in a series of
iterations in which more and more detail is added, requirements are refined and designs are
improved before final implementation.
There are various approaches to software development that organise the major tasks in different
ways and have differing ways of managing the process. These approaches have developed over the
years in order to improve the speed of the process and ensure that the user requirements are met.
They include
 Waterfall model (sequential)

 Spiral model (evolutionary)
 Rapid application development

 Prototyping (iterative)

Rapid Application Development approach1
Prototyping model of software development1
Other types also exist and are constantly being developed. As a general observation two trends are
emerging: the use of more dynamic and participative approaches such as ‘scrums’ and model-based
design in which codes are generated automatically from a model-based specification. The most
widespread of the latter technologies is provided by the Unified Modelling Language (UML)2 and
tools that implement this such as Altova3.
Requirements Elicitation
Various methods can be used to find out what a business needs from a proposed software
development. Many of these are based on social-interaction models and involve a range of
techniques including interviews of various types, focus groups, questionnaires, observation, scenario
development (stories about instances of process) and more. Some use more direct means to capture
existing documentation of what is done and how it is done and how the business is organised.
Preliminary investigations are needed to gather information about the organisation: its structure,
business objectives, policies and the way it defines and manages roles and responsibilities.
Information is also sought on the business domain: the markets and products/services it operates in,
regulatory frameworks that must be adhered to and the perceived best practices.

Depending on one’s philosophical approach to BPR – whether this should be incremental or

revolutionary – it may also be useful to identify the current processes, actors, roles and systems. This
often involves some process mapping of this ‘AS-IS’ process.
Eliciting requirements is the next critical phase in developing both new software components and in
configuring existing systems like SAP ERP but it is very difficult. Problems exist in identifying what
questions to ask, who to ask them of and how to interpret their responses. People in different roles
will have different perspectives on the problems that exist and the priorities that need to be
addressed. Some will focus on detailed operational issues whilst others may only care about more
abstract management issues like the effect of any change on their freedom to exercise management
decisions or the effect of the system on peoples’ attitudes in general. The analyst must adapt their
methods to suit the people they are talking to and must take care to listen to and interpret the
meaning of their responses.
Requirements Evaluation
There are broadly two streams of information relating to requirements: knowledge about how
things are currently done (AS-IS) and knowledge about how things could or should be done (TO-BE).
Both sources of information need to be analysed to help guide the development of requirements.
The analyst needs to identify existing best-practices because these should not be discarded or re-
designed without good reason, and also constraints that limit freedom to try new things. Some of
the ideas that are elicited about TO-BE process also need to be checked to see if they make sense
within a wider context and within the constraints of existing technology, cost and operational value.
Some emerging requirements may introduce new risks to the business and these need to be
evaluated. System and software developers often focus only on the positive outcomes of
development work; they often fail to consider the likelihood of undesirable effects and the
consequences of failing to implement some function. Some risks can be mitigated by developing
countermeasures some risk can be mitigated by not taking them in the first place. There is a whole
body of techniques for identifying, assessing and control risks that is beyond this course but should
be borne in mind during system specification and implementation.
Requirements Specification and Documentation

In classical waterfall approaches no software can be designed or implemented until a specification
has been completed but in prototyping approaches this can be relaxed. One argument for adopting
the prototyping approach is that only when concepts have been translated into a concrete form (as a
prototype) can users begin to fully appreciate the intent, consequences and opportunities of a
proposed development; only then can a full dialog begin. Sequential methods do not provide the
opportunity to iterate designs. If a requirement is not identified at this stage then it will be difficult,
possibly impossible, to implement it later.
Spiral and prototype approaches may work well for software development but there is evidence to
suggest that they don’t work well for systems development of SAP ERP. Research into the planning
and implementation of SAP R/3 systems4 during the 1990s suggested that some integration issues
had to be identified and tackled early on in the specification and design phase. Since then, there
have been changes in the underlying technologies that have made it easier to modify system
operation and integration later on in the development process5.

Software Design and Implementation

This phase sees the translation of the requirements into executable software and their subsequent
testing and installation. The preference of most teams today is to do this using iterative, prototype-
based methods rather than as a single ‘big bang’. Those readers who are interested in this aspect of
systems development are directed to the extensive literature on this subject. We will return to some
of the technical issues in later chapters on Enterprise Application Integration (EAI), Customisation
and SAP Netweaver.
From the point of view of extending SAP ERP capabilities then developers are referred to SAP’s
programming language (ABAP) and the integration now provided via SAP Netweaver to .Net, Java
and IBM Websphere tools.
SAP NetWeaver components and programming interfaces
3. Prioritising Information Systems Requirements

In many cases a number of possible solutions to information systems needs may be identified; the
issue that follows is to select which of these to adopt. This selection will be based on a number of
criteria, one of which should be the anticipated effect that the selection will have on business
performance. The Strategy Map6 is one approach that attempts to do this and has the added value
that it is based on an already accepted approach to performance management and one that is
implemented with SAP’s Business Intelligence solution.
The Information Capital of a business is the main focus in using the Strategy Map for IS identification
and selection of information systems. Information Capital refers to the databases, information
systems, networks and technology infrastructure of a business. In using the Strategy Map we are
seeking to align information capital (and two other types of intangible assets) with corporate

strategy and then assess the readiness of the business to meet this strategic requirement. By ranking
existing capability the map can be used to identify and prioritise information system investments.
ERP solutions provide support under the learning and growth dimension of the Strategy Map;
supporting information capital and also Human Capital (a module within SAP ERP).
Strategy Map layout (source: Kaplan & Norton, HBR6)
The readiness of a firm to implement strategy using information capital is shown in the following
extract for a hypothetical example based on a retail banking scenario 6. The columns marked with
crosses are causes for particular action. Applications that are assessed with values 4 to 6 require
attention: either development or investment.

Information Capital Readiness for Consumer Bank6
4. Business Process Reengineering and SAP ERP Requirements

As previously stated, SAP as the market leader, has pioneered the alignment of enterprise solutions
with business processes. SAP is not the only ERP vendor to provide modular and process oriented
solutions. Others such as INFOR (through their acquisition of the original Baan ERP solution), Oracle
and PeopleSoft have adopted similar approaches and sometimes led the market in their use of
technology.
The scale and complexity of major ERP solutions means that most are based on pre-existing
functions that can be configured to support particular processes. The vendors put a lot of effort into
analysing the way that successful companies operate and incorporating these ‘best-practices’ in
their solutions.

Typically in SAP functions are grouped according to the organisational departments that are found in
most firms: Finance and Accounting, Materials Management, Sales and Distribution, to name just a
few. For example, the Sales and Distribution module (SD), includes functions for creating a sales
order. This function is supported by one or more windows within the SAP graphical user interface
and allows users to select predefined data values and enter order details.
Business processes often cross-over departmental boundaries and therefore need to use functions
that are supported by different modules. We have already seen this in the previous chapter on order
fulfilment that was illustrated with the following diagram. Sales interact externally with customers
and internally with materials management staff that operate warehouse activities and with finance
that manage accounts receivable.
Customer (purchasing) Goods Receiving Accounts

payable
Accounts
Sales Sales Warehouse receivable
Accounting
Receive Purchase Pick & Prepare Create & send

Create Sales Order Send Shipment Receive Payment
Order shipment invoice
Receive Create & Send

Customer Inquiry Quotation
Archive
Quotation
Manufacturing
The order fulfilment process
In developing a requirements specification at the system level for an ERP solution, a project team
has to identify the functions that processes must perform. In doing this it is identifying the modules
that are required. Each module has a cost associated with it so this process has to be controlled. One
way of managing this is to re-engineer the process, to eliminate some tasks, automate others and re-
allocate some so that they can be performed within a single department.
BPR and process modelling are key tools used to capture and analyse high-level business
requirements. BPR in particular can play an important role in taking the captured AS-IS process map
and using it to develop an improved TO-BE process based on the knowledge of the analyst of the ERP
system’s capabilities, the desirability of reducing the number of discrete tasks and the desire to
streamline processes so that material and information flow smoothly. The analyst needs to work
within a team that includes participation from the customer and from the vendor. The customer’s
representatives help identify current processes, actors, methods, tools and policy; the vendor

provides additional technical knowledge about the solution options, their capabilities and their
implementation.
Many SAP ERP projects start with a BPR exercise to streamline process definitions during pre pre-sales
evaluation and prior to engaging in detailed implementation planning. The extent to which this is
necessary
sary and important has been discussed in the literature. In the past SAP has been criticised for
the way in which the system architecture limits the opportunity for process change after
implementation2. For organisations that rely on their ability to adapt to changing business conditions
by changing the way they do business this can be a serious issue. For other organisations that
operate under a fairly stable environment such as in public administration and healthcare this may
not be such a problem. Fortunately
ately advances in software are reducing earlier inflexibility and making
it easier for all types of organisation to adopt these technologies (if they understand the
capabilities).
5. Matching SAP Modules

Bancroft2, in her review of SAP R/3 implementation during
during the 1990s (admittedly some time ago),
identified an approach to selecting modules that is quite simple. She suggested a consensus based
approach in which all modules are initially placed outside the project scope (drawn as a circle on a
whiteboard) and then one by one compared with desired process requirements through scenario-
based discussions. If a module is needed to support a scenario and its processes then it is included
inside the scope. If a module and its functions is not included then it is left outside the scope. If
existing systems provide support for some processes but it is desired not to implement these in the
SAP solution, then these are noted as possible systems that will need to have interfacing software
developed.. During discussions, it is possible to modify the scope if is getting too large or if some of
the requirements are recognised as nice to have but not critical.
Bancroft’s Whiteboard Module Selection
In the figure above a business scenario requires support for sales order entry and a secondary
requirement has been expressed to use PM (project management) to support and engineering issue.

The SD module is considered and selected because it contains the required functionality as is the PM
module. The FI module was not immediately included but on discussing the sales order requirement
they identified that the chart of accounts would be affected so included the FI module. By this stage
they were getting concerned about the complexity and cost of the proposal and their limited budget.
The project management problem was discussed and it was agreed that this was a temporary
problem and could be managed using other means so they removed the PM module. Their business
process for sales order entry needs to check stock records but they want to retain an existing
(legacy) system that manages this so they will need to develop an interface for this. The MM in this
diagram represents this existing material management application but if it were moved inside the
circle then it would mean that SAP MM is to be included. The project would need to migrate the
data and train users from the legacy system into SAP (as it would have to do with the other replaced
systems).
The increasing use and integration of process mapping tools with ERP systems both for recording
processes and for configuring solutions has provided further opportunities to incorporate a more
detailed evaluation of process requirements during the pre-sales and early project planning phases.
This is accomplished as a side-effect of the discipline and rigour that process mapping can require if
done well. It exposes the objects, actors and relationships between people data and applications and
can show where there are gaps, repetitions and awkward (discontinuous, ambiguous and
unnecessarily complex) processesi.
6. Conclusion
Establishing the requirements for ERP is not the same as the more general case of Requirements
Engineering (RE) for other types of software. Whilst there is a large body of literature, tools and
techniques associated with RE in general this is not the case for ERP. ERP vendors and consultancy
companies do not reveal their methods as these are what allow them to compete. These can be
experienced only when one gets involved in a real project.
Most major ERP products available are not marketed as systems but as solutions to reflect the fact
that they are not a single product but a combination of systems, modules and individual
applications. Solutions also suggest that what is being obtained by the customer is more than a set
of software codes but a mix of these, with changes to business policy, management and processes.
ERP requirements are often stated at a high level of abstraction and result in the identification of a
set of modules either as part of a pre-packaged Industry Solution or as a unique solution for an
individual company. The detailed specification of process-level requirements, changes to
organisational structures and interfaces is carried out during implementation planning.
Companies often find that their ERP options are limited by financial constraints (limited budgets),
their ability to absorb the technical complexity of ERP (not enough qualified staff available at the
required time, and insufficient ability to educate and train users) and the existence of legacy systems
i
Processes often become confused and complicated during their life. They get modified to address short-term
problems and these modifications get embedded in the standard process. More modifications get added and
absorbed over time and few people can remember what the main process is and what the often unnecessary
exceptions are.

(that are deemed too difficult, disruptive and/or expensive to replace). It is important however to
ensure that when compromises are needed these take into account the effect they will have on the
resulting solution’s ability to meet the business need.
References
1
Modern Systems Development and Design, Hoffer et al., Prentice Hall, 2007.
2
The Unified Modeling Language Reference Manual, Rumbaugh et al, Addison-Wesley Object Technology,
2004.
3
Altova Mission Kit, http://www.altova.com/missionkit/software-development-tools.html accessed
10/3/2010.
4
Implementing SAP R/3: How to introduce a large system into a large organisation, Bancroft N.H., Manning
Publications Ltd, 1996.
5
Business Process Automation: ARIS in practice, Scheer A-W et al, Springer-Verlag, 2004.
6
Measuring the Strategic Readiness of Intangible Assets, Kaplan R.S., Norton D.P., Harvard Business Review,
February 2004, pp52-63.

ERP Integration
Business Process Modelling
Neil Davis
3/15/2010
This chapter provides a foundation for understanding the development and application of business
process models. It starts by reviewing the foundation of all process diagrams: the flowchart. It then
contrast simple maps that only show structure with models that also describe objects and data. It
describes two modelling techniques Event-driven Process Chains (EPC) and Business Process
Modelling Notation (BPMN) before identifying the opportunity to translate the information in
process models directly into software codes and what this means for the way we can now start to
view information systems as dynamic components in the competitive business environment.
Contents
1. Introduction .................................................................................................................................... 2
2. The Foundation of Process Models................................................................................................. 2
Flowchart ............................................................................................................................................ 3
3. Process Models & Process Mapping ............................................................................................... 4
Analysis of Process Maps .................................................................................................................... 5
4. Event-driven Process Chain Models (EPC) ...................................................................................... 6
5. Business Process Modelling Notation (BPMN) ............................................................................... 9
6. Executable Process Models...........................................................................................................14
7. Conclusion.....................................................................................................................................14
References ........................................................................................................................................14

1. Introduction
Business Process Modelling is used widely for a range of purposes but primarily as a means to record
and analyse the logic of a business process. This is important because without a process it can be
difficult to obtain consistency in the work that is done. This can make if difficult to predict the time
taken to perform a set of tasks because the number of tasks can vary and the way of performing
each task can vary. Variations in the way a task is performed can also lead to differences in what is
produced as an output: its performance and its quality.
All organisations, whether they are commercial businesses or public sector types operate business
processes but many of these are not recorded in a formal way. The people who execute or perform
business processes often learn these from their colleagues. Some process are taught formally in a
classroom and others are learnt on-the-job by copying someone. This approach to communicating a
process by repeated word-of-mouth can lead to a modification of the process over time. Sometimes
this can lead to improvements in the process and its efficiency but it can also lead to variations that
reduce efficiency and affect the quality of output.
Process modelling attempts to record the details of a process so that it can be communicated
effectively and so that any improvements to a process can also be recorded. Process models identify
tasks that need performing, the resources that are needed to do so and the sequence in which the
tasks should be performed in order to achieve a desired outcome at an acceptable cost and time.
Process models can be used for analysing processes to understand where there may be weaknesses
in an existing process as a preliminary step in re-designing or reengineering a process. The
application and popularity of Business Process Reengineering (BPR) in the 1990s was a major factor
in the development of process modelling tools.
Process models are the foundation of Business Process Management that has become an important
focus for businesses in the early 21st Century as firms struggle to compete in an increasingly
competitive global business environment. Public sector finances are coming under more and more
pressure as more services are demanded but budgets are being cut.
2. The Foundation of Process Models

It is possible to describe processes using natural language but this is inefficient and error-prone;
instead people use diagrams. Natural language descriptions of process require either a spoken or a
textual description. Spoken descriptions require both parties – the speaker and the audience- to be
present. Most humans’ ability to remember spoken instructions is limited to quite short and simple
tasks. The alternative of a written text allows a description to be ‘read’ asynchronously and in
multiple locations but, in common with natural language, can be misinterpreted. Descriptions based
in natural language also pose particular problems in multi-lingual settings.
Diagrams provide a simplified way of describing systems that reduce the opportunities to
misinterpret instructions. A diagram replaces complex natural language constructs with symbolic
representations that are much simpler and can be associated with well-defined meanings. In the
following exposition of process modelling we are limiting ourselves to formal diagramming
techniques because these reduce ambiguity and can be used later to automate processes. Other

types of unstructured diagrams, such as Rich Pictures as shown below, are of limited use in this
context.
An example of an informal Rich Picture diagram
Formal diagrams are also concise because a few symbols can be connected together to represent
quite complex concepts. For this to be achieved, however, the author of a diagram must understand
the formal meaning of the symbols and the syntax of how they can be connected. In adopting a
formal approach, or ‘formalism’, one is in fact learning a new language. Both the author and the
reader need to understand the formalism in order to exchange meaningful knowledge.
Diagrams allow systems and processes of arbitrary complexity to be modelled by allowing them to
be decomposed into more and more detail. Decomposition is often described using the concept of
levels; zero is often used to denote the ‘top’ level that described the system in abstract terms. Each
decomposition can yield more concrete information that defines the specific way in which the
system is organised or a process performed.
Flowchart
Possibly the most familiar type of diagram associated with process modelling is the flowchart. Basic
flowcharts have been available for over 50 years; they can be drawn by hand – either freehand or
with a stencil – or using computer aids. They contain a limited number of symbols which makes
them easy to learn and these symbols represent abstract concepts which take on a specific meaning
within the context of each flowchart.
Various set of symbols have been used for different purposes but they all contain some common
features. For example, start and end symbols, process or task boxes and decision diamonds with
YES/NO outcomes.

Source: BBC
(http://www.bbc.co.uk/schools/gcsebitesize/design/images
/dt_ctip_asc3.gif)
One of the earliest applications for flowcharts was to design the logic of software and the processing
of information in computer systems. This worked well for software that used a functional model of
programming but as developers make more and more use of object-oriented styles of programming
its use has lessened and other diagramming techniques such as UML1 have taken over.
3. Process Models & Process Mapping

Models of business processes are based on the foundation of flowcharts, sometimes with more
expressive features and sometimes with less. Many people refer to these diagrams as Process Maps
because, like a road map, they allow the reader to navigate along the journey that is the process.
Some authors have described process mapping a way of telling the business story2. Process Models
are more than maps; they provide additional meta-information in addition to the sequence oriented
view expressed by flowcharts. A process model will include attribute information about the
resources used, the logic and timing of interactions and messages, the co-ordination between
related processes and the data objects that are accessed and modified. The ultimate aim of process
modelling in this context is to simulate business processes as a means of analysing their
performance and then converting the models in to a specification for an executable information
transaction (some code that operates on data, changes the state of the business environment and
stimulates workflow steps).
The first step in process mapping is process identification: capturing the way in which an existing
process is performed. This is not as easy as it might sound because we must first identify the start
and the end: without these we will not know what to include. It is also complicated by the fact that
processes often cut across organisational structures, geographical locations and enterprises
themselves. It is also made difficult by the fact that different stakeholders exist and may have

different views about the purpose of a process, what constitutes it and what level of detail has to be
examined in order to achieve a useful result.
As the modelling proceeds to map out the logical sequence of tasks involved in a process they must
also be gathering data about the resources that are used, consumed and output at each step. They
must also identify the rules that people use to determine what next step to perform when there is a
choice and when to wait for other tasks to be completed before continuing.
Understanding the logic of how control decisions are made within a process and what information is
needed to do this often involves asking many questions of people who are involved in the process.
This can be an expensive and time consuming process; eliciting knowledge from people is not easy;
formulating the questions to ask and interpreting the responses is hard; often people need to be
revisited to clear up ambiguities and to ask new questions as better process understanding is
achieved. However, at the end of this investigative process, the modeller often knows more about
the process as a whole than anyone else in the organisation and the problem then is how to
communicate this.
The physical process of generating maps is relatively simple now that software applications have
made it easy to arrange the symbols neatly and to add and delete or redraw maps as new
information is added.
Analysis of Process Maps

Process maps are useful for documenting existing processes for purely administrative purposes but
they are of more value if they are then used to improve processes. Purely administrative processes
and documentation is a valid role for process maps and necessary for certain types of accreditation.
The existence of clearly defined business processes – irrespective of whether these are effective or
not – is a requirement for achieving International Quality Standards such as ISO9001 that is often
achieved in part using process mapping.
As the BPR literature identifies, process improvement can require incremental change or
revolutionary change depending on the philosophy of management. Revolutionary change may not
gain much from an analysis of current process because it is often driven by the mantra ‘obliterate
don’t automate’. Incremental change is more likely to be based on identifying weaknesses in current
processes and improving these alone.
The first place to start is with the customer and how the business process relates to satisfying their
needs. This may require a closer examination of the initiation or ‘start’ of the process currently
mapped. Does the current process start at the right point: is it before customer involvement or after
it? Ideally it should be coincident with it. The same is true when we come to the end of the process;
it should not end before the customer’s need has been addressed. It could be after this point if
internal closing-off tasks are needed such as final recording of performance and archiving.
Throughout the mapped process, the analyst should be looking for continuity in the flow of
information and material and whether the process as mapped adequately described the potential
causes of failure and responses to these. This analysis is aiming at fully defining the process so that
gaps and omissions can be identified and closed so that the final map provides a complete definition
of the process (including its decision logic), its actors and the resources they need. A map with these

features then provides the basis for automating the routine parts of a process with information
system support.
NOTE: There are far more process mapping and process modelling tools and techniques than are
shown here. Each has its own strengths and limitations, each will be easier to use and more
expressive for some tasks than others. Few, if any, practicing business analysts are familiar with all
techniques and fewer still would be confident or interested to learn more than they currently know.
Individual companies will often adopt particular techniques in order to standardise and simplify
training and communication.
4. Event-driven Process Chain Models (EPC)

The Event-driven Process Chain approach to modelling was developed by Scheer in the 1990s and is
marketed by IDS Scheer, a global information services company specialising in business process
management.
An EPC is a flowchart that consists of two main symbols: events and functions. Events represent
stimuli or changes to specified state within an information system that may trigger some tasks to be
performed. Functions are symbolic elements in EPC that transform the state of information within a
process. Functions are only performed if their inputs evaluate as a Boolean true value (1= true and
0=false). Information may refer to data directly or may refer to the state of some physical artefact
such as a stock level.
The EPC formalism requires Events to be represented as Hexagons and functions as rounded boxes
as shown above. The EPC is a directed graph in which the nodes (symbols) are connected and the
direction of the connection conveys a meaning. Arrows are used to indicate the direction.

In addition to events and functions certain other supporting concepts can be shown on an EPC
diagram; these help describe how the process interacts with information records, systems and
organisation units. In the diagram below the Check Order Information function is triggered when a n
order is received and results in order confirmation. This final state may in its turn trigger another
EPC or may natural flow into another function on the same diagram.
Order information is checked by actors in the Customer Center who use a CRM system as shown in
the symbol to the left of the function. EPCs do not need to specify this information, and indeed at
the specification stage, the exact systems to use may be unknown. An Order Form is input an input
to the function and an order confirmation document is output from the function. Documents could
be either paper documents or information records in a SAP ERP solution.
An EPC diagram showing additional resources
The final elements in the EPC formalism are condition nodes which come in a variety of forms and
express different types of logic. An event may initiate multiple functions at the same time; similarly,
a function may result in multiple events. To represent these branches and processing loops in an
EPC, a connector (or rule) is used. However, instead of acting simply as graphical connections, the
connectors also define the logical links between objects, such as “and” or “either/or.”
In the EPC the logical relationships between elements in the control flow, that is, events and
functions are described by logical connectors. With the help of logical connectors it is possible to
split the control flow from one flow to two or more flows and to synchronize the control flow from
two or more flows to one flow.
 OR – opening : one or more of the following paths is enabled, the remainder are blocked
 OR- closing: one of the incoming paths must be ‘true’ (enabled) for the following function to
occur.
 XOR – opening: Only one of the following paths is enabled
 XOR – closing: Any one of the input paths needs to be enabled for the following function to
occur.
 AND – opening: each of the following paths is enabled.

 AND –closing: each of the incoming paths must be enabled for the following function to
occur.
Opening conditions result in establishing the state of the process. Closing conditions specify what
needs to be true for a function to trigger. In a given branching process the outermost conditions
must match i.e. an opening XOR must be matched by a closing XOR but within these AND and OR
conditions can exist but must be matched themselves.
Activity
AND
Activity Activity
XOR
Activity Activity
OR
Activity
a) EPC conditions in Visio

b) EPC diagram and conditions in ARIS
Companies use Event-driven Process Chain (EPC) to represent their workflows. Process chains
describe the sequencing and interaction between data, process steps, IT systems, organizational
structure and products. An EPC always starts and ends with events, which define the state or
condition under which a process starts and the state under which it ends.
The ARIS tools are embedded within the SAP NetWeaver framework for defining business processes
within the context of SAP. ARIS supports process representation by EPCs in all products (e.g., ARIS
Business Designer, ARIS Business Architect, ARIS Audit Manager and ARIS for SAP NetWeaver). The
reference models provided by SAP are also defined using EPC methodology.
EPCs offer a variety of ways to analyze processes and identify both quantitative and qualitative
improvement options. For this reason, ARIS Business Simulator and ARIS Business Optimizer also use
EPC diagrams.
EPCs are typically used at the lower levels of the process hierarchy. If technical and business
processes need to be described, other methods, such as BPMN and UML are used instead of EPCs.

5. Business Process Modelling Notation (BPMN)1

The primary goal of BPMN is to provide a notation that is readily understandable by all business
users, from the business analysts that create the initial drafts of the processes, to the technical
developers responsible for implementing the technology that will perform those processes, and
finally, to the business people who will manage and monitor those processes. BPMN can also
support the generation of executable BPEL2 in some cases. Thus, BPMN creates a standardized
bridge for the gap between the business process design and process implementation. BPMN defines
a business process model which is based on a flowcharting technique tailored for creating graphical
models of business process operations. A Business Process Model, then, is a network of graphical
objects, which are activities (i.e., work) and the flow controls that define their order of performance.
BPMN Basics
Like Flowcharts and EPC models a BPMN-based diagram is made up of a set of graphical elements.
These elements enable the easy development of simple diagrams that will look familiar to most
business analysts (e.g., a flowchart). The elements were chosen to be distinguishable from each
other and to utilize shapes that were already familiar to most modellers. For example, activities are
rectangles and decisions are diamonds. It should be emphasized that one of the drivers for the
development of BPMN was to create a simple mechanism for creating business process models,
while at the same time being able to handle the complexity inherent to business processes. The
approach taken to handle these two conflicting requirements was to organize the graphical aspects
of the notation into specific categories. This provided a small set of notation categories so that the
reader of a diagram could easily recognize the basic types of elements and understand the diagram.
Within the basic categories of elements, additional variation and information can be added to
support the requirements for complexity without dramatically changing the basic look-and-feel of
the diagram. The four basic categories of elements are:
• Flow Objects
• Connecting Objects
• Swimlanes
• Artifacts
Flow Objects
Each diagram has a small set of (three) core elements, which are the Flow Objects, so that modellers
do not have to learn and recognize a large number of different shapes. The three Flow Objects are:
1
Based on “Introduction to BPMN”, White S., IBM
http://www.bpmn.org/Documents/Introduction_to_BPMN.pdf edited : N. Davis 2010
2
BPEL – Business Process Execution Language

Event
An Event is represented by a circle and is something that
“happens” during the course of a business process. These Events
affect the flow of the process and usually have a cause (trigger)
or an impact (result). Events are circles with open centres to
allow internal markers to differentiate different triggers or
results. There are three types of Events, based on when they
affect the flow: Start, Intermediate, and End (see the figures to
the right, respectively).
Activity
An Activity is represented by a rounded corner rectangle (see the
figure to the right) and is a generic term for work that company
performs. An Activity can be atomic or non-atomic (compound).
The types of Activities are: Task and Sub-Process. The Sub-
Process is distinguished by a small plus sign in the bottom centre
of the shape.
Gateway
A Gateway is represented by the familiar diamond shape (see
the figure to the right) and is used to control the divergence and
convergence of Sequence Flow. Thus, it will determine
traditional decisions, as well as the forking, merging, and joining
of paths. Internal Markers will indicate the type of behaviour
control.
Core BPMN Flow Objects
Connecting Objects
The Flow Objects are connected together in a diagram to create the basic skeletal structure of a
business process. There are three Connecting Objects that provide this function. These connectors
are:

Sequence Flow
A Sequence Flow is represented by a solid line with a
solid arrowhead (see the figure to the right) and is
used to show the order (the sequence) that activities
will be performed in a Process. Note that the term
“control flow” is generally not used in BPMN.
Message Flow
A Message Flow is represented by a dashed line with an
open arrowhead (see the figure to the right) and is
used to show the flow of messages between two
separate Process Participants (business entities or
business roles) that send and receive them. In BPMN,
two separate Pools in the Diagram will represent the
two Participants.
Association
An Association is represented by a dotted line with a
line arrowhead (see the figure to the right) and is used
to associate data, text, and other artefacts with flow
objects. Associations are used to show the inputs and
outputs of activities.
BPMN Connecting Elements
For modellers who require or desire a low level of precision to create process models for
documentation and communication purposes, the core elements plus the connectors will provide
the ability to easily create understandable diagrams as shown below.
An Example of a Simple Business Process
For modellers who require a higher level of precision to create process models, which will be subject
to detailed analysis or will be managed by Business Process Management System (BPMS), additional
details can be added to the core elements and shown through internal markers.

A Segment of a Process with more Details
Swim-lanes
Many process modelling methodologies utilizes the concept of swim-lanes as a mechanism to
organize activities into separate visual categories in order to illustrate different functional
capabilities or responsibilities. BPMN supports swim-lanes with two main constructs. The two types
of BPD swim-lane objects are Pools and Lanes.
A Pool represents a Participant in a Process. It is also acts as a graphical container for partitioning a
set of activities from other Pools usually in the context of B2B situations.
A Lane is a sub-partition within a Pool and will extend the entire length of the Pool, either vertically
or horizontally (see the figure to the right). Lanes are used to organize and categorize activities.
Artefacts
BPMN was designed to allow modellers and modelling tools some flexibility in extending the basic
notation and in providing the ability to additional context appropriate to a specific modelling
situation, such as for a vertical market (e.g., insurance or banking). Any number of Artefacts can be
added to a diagram as appropriate for the context of the business processes being modelled. The
current version of the BPMN specification pre defines only three types of BPD Artefacts, which are:

Data Object
Data Objects are a mechanism to show how
data is required or produced by activities.
They are connected to activities through
Associations.
Group
A Group is represented by a rounded corner
rectangle drawn with a dashed line (see the
figure to the right). The grouping can be used for
documentation or analysis purposes, but does
not affect the Sequence Flow.
Annotation
Annotations are a mechanism for a modeller to
provide additional text information for the reader
of a BPMN Diagram (see the figure to the right).
BPMN Artefact Elements
Modellers can create their own types of Artefacts, which add more details about how the process is
performed—quite often to show the inputs and outputs of activities in the Process. However, the
basic structure of the process, as determined by the Activities, Gateways, and Sequence Flow, are
not changed with the addition of Artefacts in the diagram.
A process using BPMN including swim-lanes
There are many similarities between BPMN and certain of the modelling techniques that are
specified within the UML specification. It is very likely that BPMN and UML will merge. This is a good
thing if it simplifies the subject area without losing any expressive power.

6. Executable Process Models

A number of research activities in recent years have considered how the information in process
models can be re-used directly when implementing software to enable processes. The thinking is
clear: process models, identifies the sequence of tasks that must be performed, identifies the
resources (artefacts in BPMN) that each task needs and produces and identifies the decision logic to
route process control. These are all the things that basic flowcharts aimed to do when they were
first used in software development. The difference is that now software engineering uses object-
oriented concepts that allow a diagram concept and its associated data (resources, attributes,
artefacts etc.) to be mapped directly into a computer data-structure and its methods (behaviours).
The Business Process Execution Language (BPEL) is one example of these concepts in action that has
been implemented by a number of IS companies (Oracle and IBM, for example). It is possible to
generate BPEL programs directly from a BPMN model thus saving considerably on the costs of
software development and the time delays involved in generating the codes. There is still much to
do in improving the interoperability and quality of code that is automatically generated in this way
but there are many development teams that are working towards this goal.
7. Conclusion
Process Modelling has become a central activity in contemporary information systems design and
implementation. No longer is the development of new information systems capability the sole
domain of computer scientists or people in a firm’s IT department. Increasingly, the people who
really understand what is needed, who know what is possible and have the means to make things
happen: the operation management team (and people working for them), can have a direct
involvement in the specification of information systems.
The recognition of process as a critical component in adding value to the firm and the availability of
tools and techniques that make this relatively simple and visible, are leading to major changes in the
way the information systems are viewed. Whereas once they were seen as static capabilities (once
implemented difficult and expensive to modify) that could sometime act as a brake on business
performance, these tools make it possible, if a firms has the knowledge and understanding, to make
information systems adaptable and more suited to the changing needs of modern business.
References
1
The Unified Modeling Language Reference Manual, Rumbaugh et al, Addison-Wesley Object Technology,
2004.
2 nd
Business Process Mapping: Improving customer satisfaction, Jacka J.M., Keller P.J., Wiley, 2 ed., 2009.

SAP ERP
Master Data
SAP ERP
Sales and Distribution (SD)

SAP ERP Sales & Distribution Functions
• Sales Support
• Sales
• Shipping and Transportation
• Billing
• Credit Management
• Foreign Trade
SAP ERP Structure for Sales Order Processing
Client 410
Sales Area
Company Code Sales Org

C100 S100
Distribution Division
Channel (RE) (01)
Plant P100 Plant P101
SAP ERP Internal Sales Structure
US Sales Office
S100
Western Sales Eastern Sales

Office Office
Northwest Sales Southwest Sales Northwest Sales Southwest Sales

Group Group Group Group
Salesperson 1 Salesperson 4 Salesperson 6 Salesperson 7
Salesperson 2 Salesperson 5 Salesperson 8
Salesperson 3 Salesperson 9
SAP ERP Structure for Distribution
Client 410
Company Code
C100
Plant P100 Plant P101
Shipping Point Shipping Point Shipping Point

Rail Dock Express Dock Freight Dock
Loading Point Loading Point Loading Point

LP03 LP02 LP01
SAP ERP SD Master Data
Customer Master
Material Master
Sales Condition
SAP ERP Customer Master Data
• Customer Master
– Contains all of the information
necessary for processing orders,
deliveries, invoices and customer
payment
– Every customer MUST have a master
record
• Created by Sales Area

– Sales Organization
– Distribution Channel
– Division
SAP ERP Customer Master Data
• The customer master information is
divided into 3 areas:
– General Data
– Company Code Data
– Sales Area Data
SAP ERP Customer Master
General Information relevant for the entire organization:

Name
Address
Communication
Client 410
Company Code specific information: Sales Area specific information:

Acc. Mgmt Sales Office
Payment Currency
Bank
Company Code 102 Sales Org. 101
Company Code 101
Company Code 100 Sales Org. 100
SAP ERP Material Master Data
• Material Master
– Contains all the information a
company needs to manage about a
material
– It is used by most components
within the SAP system
• Sales and Distribution
• Materials Management
• Production
• Plant Maintenance
• Accounting/Controlling
• Quality Management
– Material master data is stored in
functional segments called Views
SAP ERP Material Master Views
Sales Data
Basic Data Purchasing Data
Mat. Plan. Data
Material Master Forecasting Data
Storage Data
Controlling Data Quality Data
Accounting Data
SAP ERP Material Master

Name
Weight
U/M
Client 410
Sales specific information: Delivery Plant Storage Location specific information:

Loading Grp Stock Qty
Sales Org 102 Storage Location 20

Sales Org 101 Storage Location 10
Sales Org 100
SAP ERP
Customer Material Information
Record
• Data on a material defined for a
specific customer is stored in a
Customer material info record.
• Info Records contain:
– Customer-specific material number
– Customer-specific material
description
– Customer-specific data on deliveries
and delivery tolerances
• You can also maintain default text to
appear on sales orders for that
customer
SAP ERP Condition Master (Pricing)
• Condition master data includes:
– Prices
– Surcharges
– Discounts
– Freights
– Taxes
• You can define the condition master
to be dependent on various data:
– Material specific
– Customer specific
• Conditions can be dependent on any
document field
SAP ERP Output
• Output is information that is sent to
the customer using various media,
such as:
– E-mail
– Mail
– EDI
– Fax
– XML
• Output examples:
– Quotation
– Confirmation
– Invoice
SAP ERP
Materials Management (MM)

SAP ERP Functionality
• Inventory Management
• Purchasing
• MRP
• Physical Inventory
• Valuation
• Service Master
• Invoice Verification
• Product Catalogs
SAP ERP Organizational Structure for Procurement
• Client
– An independent environment in the system
• Company Code
– Smallest org unit for which you can maintain a legal set of
books
• Plant
– Operating area or branch within a company
• i.e. manufacturing facility or distribution facility
• Purchasing Organization
– The buying activity for a plant takes place at the
purchasing organization
• Purchasing Group
– Key that represents the buyer or group of buyers
SAP ERP Purchasing Specific Structure
• Purchasing Organization
– Organization unit responsible for procuring
services and materials
– Negotiates conditions of the purchase with the
vendors
• Purchasing Group
– Buyer or group of buyers who are responsible for
certain purchasing activities
– Channel of communication for vendors
SAP ERP Purchasing Organization / Group
Company Code
Plant 100 Purchasing Org
100
100
Purchasing Org
Plant 100 Plant 101
100
Centralized vs. Purchasing Org

100
Decentralized
Purchasing
Company Code Company Code
100 101
SAP ERP Structure for Procurement
Client 410
Purchasing Org Company Code Purchasing Org

P100 C100 P101
Purchasing
Plant P100 Group 100 Plant P101
SAP ERP MM Master Data
Vendor Master Data
Material Master Data
Purchasing Info Record
Condition Master Data
Output Master Data

SAP ERP Vendor Master Data
• Vendor Master
– Contains all the necessary
information needed to business with
an external supplier
– Used and maintained primarily by
the Purchasing and Accounting
Departments
– Every vendor MUST have a master
record
SAP ERP Vendor Master Views
• Client Level
– Address
– Vendor Number General Data
– Preferred
Communication
• Company Code Data Company Code Data
– Reconciliation Account
Financial Accounting (FI)
– Terms of Payment
– Bank Account
• Purchase Org Data Purchasing Data
– Purchasing Currency Materials Mgmt (MM)
– Salesman’s Name
– Vendor Partners
SAP ERP Vendor Master

Name
Address
Communication
Client 410
Company Code specific information: Purchasing Org. specific information:

Acc. Mgmt Incoterms
Payment Currency
Bank
Company Code 102 Purchasing Org. 101
Company Code 101 Purchasing Org. 100
Company Code 100
SAP ERP Material Master Data
• Material Master
– Contains all the information a
company needs to manage about a
material
– It is used by most components
within the SAP system
• Sales and Distribution
• Materials Management
• Production
• Plant Maintenance
• Accounting/Controlling
• Quality Management
– Material master data is stored in
functional segments called Views
SAP ERP Material Master Views
Sales Data
Basic Data Purchasing Data
Mat. Plan. Data
Material Master Forecasting Data
Storage Data
Controlling Data Quality Data
Accounting Data
SAP ERP Material Master

Name
Weight
U/M
Client 410
Plant specific information: Purchasing Data Storage Location specific information:

Work Sch. Stock Qty
MRP Picking
Plant 102 Storage Location 20

Plant 101 Storage Location 10
Plant 100
SAP ERP Purchasing Information Record
• Framework for Purchase
Order
– Contains the relationship
between a vendor and a
material
Purchasing
• Can be created: Information Record
– Manually
– Automatically –
Quotations
– Automatically – Pur
Orders
• Reporting Material Master Vendor Master
– Vendor Evaluation
SAP ERP Purchasing Information Record
• Allows buyers to quickly determine:
– Which vendors have offered or
supplied specific materials
• Info Records contain:
– Data on pricing and conditions
– Last purchase order
– Tolerance limits for deliveries
– Specific lead times
– Availability periods
– Vendor Evaluation data
• Serves as default information for
Purchase Orders
SAP ERP Procurement Process
Purchase Vendor
Requisition Selection
Purchase
Order
Notify
Payment Vendor
to Vendor
Invoice Vendor
Receipt Shipment
Goods
Receipt
SAP ERP Purchase Requisition
• Internal Document instructing the purchasing
department to request a specific good or
service for a specified time
• Requisitions can be created two ways:
– Directly - Manually
• person creating determines: what, how much, and
when
– Indirectly - Automatically
• MRP, Production Orders, Maintenance Orders, Sales
Orders
SAP ERP Requisition Sourcing
• Once the requisition has been assigned a
source of supply it can be released for
processing
• There are a variety of ways that a purchasing
department can process a requisition to
determine the appropriate Source of Supply:
– Internal Sourcing Requirements
– Source List
– Outlined Agreement
– RFQ
SAP ERP Internal Sourcing
• The requisition for materials could be
satisfied by sources within our company.
– It is possible that a plant within your firm could
represent a potential source of supply for the
material needed (centralized warehouse)
– If an internal source is identified the requirement
is covered by an internal procurement transaction
(stock transport order)
SAP ERP Source List
• A source list is a record that specifies the
allowed means for procuring a material for a
certain plant within a given time period.
– If the list contains a sole source the system will
assign the vendor to the requisition.
– If several options exist the system will display a
list of vendors for you to choose from.
– If no source has been established the system will
revert to search information records and outline
agreements.
SAP ERP Outline Agreement
• Requisitions can be satisfied through existing
longer-term purchasing agreement
• These agreements are subdivided into:
– Contracts
• Consists of items defining the individual materials, material
groups, or services with prices and in many cases quantities
– Quantity
– Value
– Scheduling Agreements
• Total quantity of material is spread over a certain period in
a delivery schedule, consisting of line items indicating
quantities and their planned delivery date
SAP ERP Request for Quotation
• If nothing exist in the system we may need to submit a
request for quotation to our vendors. An RFQ is an
invitation to a vendor by a Purchasing Organization to
submit a bid for the supply of materials or services
– The accepted quotations will generate Purchasing Information
Records
– Perform Quotation Price Comparisons
– Finally Select a Quotation
P.O.
Quote 45…12
Vendor 1
Pur generate
RFQ Vendor 2 Quote Eval.
Req.
Vendor 3 Reject
Quote Letter
SAP ERP Quotation from Vendor
• The quotation received by your company is a
legally binding offer, should decide to do
business with the vendor, containing price’s
and conditions for the materials specified in
the RFQ for a predefined period of time.
– In SAP the RFQ and the Quotation will be become
a single document, you will enter the vendor’s
response in the RFQ you created.
SAP ERP Vendor Evaluation once Identified
• Vendor evaluation helps purchasing evaluate vendors for sourcing while also
enabling the company to monitor vendor relationships through performance
scores and criteria you put in place.
– Supports a maximum of 99 main criteria and 20 subcriteria for each main:
• Price
– Price Level
– Price History
• Quality
– Goods Receipt
– Quality Audit
– Complaints/Rejection level
• Delivery
– On-time delivery performance
– Quantity reliability
– Compliance with shipping instructions
– Confirmation Date
– You then must establish a scoring range (1 -100) and determine the weight factors of
scores for each.
SAP ERP Purchase Order
• A purchase order is a formal request to a
vendor for a specific material or service under
the stated conditions
• Purchase Orders can be created manually
– Reference a Purchase Order
– Reference a Purchase Requisition
– Reference a RFQ/Quotation
– Without Reference
• Purchase Orders can be create automatically
SAP ERP Purchase Order
• A purchase order can be
used for a variety of
purposes, the item
category (procurement
type) defined in the PO
will dictate the use of the
order and the process
that the order will follow:
– Standard
• Stock or Consumption
– Services
– Subcontracting
– Third-Party
– Consignment
SAP ERP Purchase Order Structure
Header
Vendor Date
Doc. Number Currency
Terms of Payment PO Price
Item Overview
Purchase Materials Price/UofM

Order Quantities
Delivery Date
45......01
Line Item
PO History Tolerances
Line Price
Delivery Schedule
SAP ERP Purchase Order Output
• Once a Purchase Order has been created the vendor
needs to be notified
– Printed
– E-mail
– EDI
– Fax
– XML
• There are a variety of forms that aid in the purchasing
process and are generated from the Purchase Order
– Purchase Order Output
– Order Acknowledgement Forms
– Reminders
– Schedule Agreements
SAP ERP Goods Receipt
Notify Vendor
Purchase
Order
45......01
Vendor
Goods
Receipt Shipment
• Goods movement in which we accept goods
into our system
• If materials are delivered against a Purchase
Order we will reference that Order
– Determine if we got what we ordered
– System can purpose data for us from the PO
• Material, quantity
– Purchase Order History is update with the receipt
– Updates Physical Inventory
– Updates Inventory G/L Account
SAP ERP Material Movements
• When a goods movement takes place it is represented
by a Movement Type
– Movement types are three-digit keys used to represent a
movement of goods
• 101 – goods receipt into warehouse
• 103 – goods receipt into GR blocked stock
• 122 – return delivery to vendor
• 231 – consumption for a sales order
• 561 – initial entry of stock
• Destinations for Receipt of Goods

– Warehouse – Unrestricted, Quality, Blocked
– Quality
– Goods Receipt Blocked Stock
SAP ERP Effects of a Goods Receipt
• When a Goods Movement for the receipt of
goods takes place a series of events occur
– Material Document is Created
– Accounting Document is Created
– Stock Quantities are Updated
– Stock Values are Updated
– Purchase Order is Updated
– Output can be generated (GR slip / pallet label)
SAP ERP Invoice Processing
• Incoming Invoices are reference against a Purchase Order to verify their
content, prices, and arithmetic.
• If discrepancies arise between the purchase order or goods receipt and
the invoice the system with generate a warning or an error
– Depending on system configuration the difference could cause the system to
Block the Invoice
Purchase order
- Target quantity -
- Target price -
Invoice receipt Goods receipt

- Actual price - - Actual quantity -
SAP ERP Invoice Processing
• When an invoice is saved it applies the liability from
the Goods Receipt of our Purchase Order to a Vendor
• Upon verification the:

– Purchase Order is updated
– Material Master is Updated (MAP)
– Accounting Document is created
• Once the Invoice has been posted the verification

process is completed and the payment process is
initiated within Financial Accounting
SAP ERP Payment to Vendor
• Can be done automatically or manually
– Post Outgoing Payment vs. Payment Program
• Elements of the Payment Transaction:

– Payment Method
– Bank from which they get paid
– Items to be Paid
– Calculate Payment Amount
– Print Payment Medium
• Process will create a financial accounting document to

record the transaction
Goods Receipt / Invoice Receipt
SAP ERP Reconciliation Account
Purchase requisition No impact on

Financial Accounting (FI)
Purchase order
Materials Management (MM)
and Financial Accounting (FI)
Goods receipt via automatic account
assignment
Inventory GR / IR
Debit Credit Debit Credit
$100 $100
Goods Receipt / Invoice Receipt
SAP ERP Reconciliation Account
Amount owed is
Invoice receipt assigned and transferred to
vendor account payable
GR / IR Vendor A/P
D C D C
$100 $100
SAP ERP Vendor Payment
Amount owed is paid to

Bank vendor and account payable is
reduced
Bank Vendor A/P
Dr Cr Dr Cr
$100 $100
SAP ERP FI – MM Integration Point
Goods Invoice Payment

Receipt Receipt Program
AP
Inventory GR / IR (Vendor) Bank
Dr Cr Dr Cr Dr Cr Dr Cr
$100 $100 $100 $100 $100 $100

SAP ERP End
• ?
ERP Integration
OLTP and OLAP
davis_n
3/18/2010
This chapter describes the characteristics of online transaction processing systems (OLTP) and online
analytical processing systems (OLAP). OLTP systems are the foundation of ERP solutions that must
operate manage the flow of information into and out of databases in real-time with high reliability
and integrity. OLAP systems are used to manipulate large volumes or related data in ways that are
not predetermined and are used in particular for business intelligence solutions. The chapter ends
with a side-by-side comparison of OLTP and OLAP.
Contents
1. Introduction .................................................................................................................................... 2
SQL Examples ...................................................................................................................................... 2
2. Online Transaction Processing (OLTP) ............................................................................................ 3
Properties of Transactions .................................................................................................................. 4
3. Online Analytical Processing (OLAP) ............................................................................................... 5
Star Schema and Infocubes................................................................................................................. 6
Slicing and Dicing ................................................................................................................................ 6
4. Comparison between OLTP and OLAP ............................................................................................ 7

OLTP & OLAP
1. Introduction
Enterprise Resource Planning systems like SAP ERP are based on large multi-table relational
databases. They support the execution of business processes by reading, manipulating and writing
data to/from these tables. The tables are designed to represent the business information in a way
that is efficient and logical, keeping related data together either in the same table or in another
table via an explicit relationship. Related information can be accessed by searching based on key
field and via join operations between tables. This data is used to populate data fields, offer lists-of-
values (pop-up and pull-down menus), check for the validity of entered information and provide
other data-related services.
The information in databases can be read and written using structured languages, the most popular
of which (for relational databases) is SQL. This provides a number of commands CREATE, INSERT,
SELECT, UPDATE, JOIN, COMMIT and ROLLBACK.
SQL Examples
The following examples are for a hypothetical database application. First the table structure is
created, then values (records) are added and a number of queries on the data are then performed.
In this example there is a single table.
CREATE TABLE STATION

(ID INTEGER PRIMARY KEY,
CITY CHAR(20),
STATE CHAR(2),
LAT_N REAL,
LONG_W REAL);
populate the table STATION with a few rows:
INSERT INTO STATION VALUES (13, 'Phoenix', 'AZ', 33, 112);

INSERT INTO STATION VALUES (44, 'Denver', 'CO', 40, 105);
INSERT INTO STATION VALUES (66, 'Caribou', 'ME', 47, 68);
query to look at table STATION in undefined order:
SELECT * FROM STATION;
ID CITY STATE LAT_N LONG_W

13 Phoenix AZ 33 112
44 Denver CO 40 105
66 Caribou ME 47 68
query to select Northern stations (Northern latitude > 39.7):

-- selecting only certain rows is called a "restriction".
SELECT * FROM STATION

WHERE LAT_N > 39.7;

OLTP & OLAP
ID CITY STATE LAT_N LONG_W

44 Denver CO 40 105
66 Caribou ME 47 68
query to select only ID, CITY, and STATE columns:

-- selecting only certain columns is called a "projection".
SELECT ID, CITY, STATE FROM STATION;
ID CITY STATE
13 Phoenix AZ
44 Denver CO
66 Caribou ME
query to both "restrict" and "project":
SELECT ID, CITY, STATE FROM STATION

WHERE LAT_N > 39.7;
ID CITY STATE
44 Denver CO
66 Caribou ME
ERP systems are mission-critical systems that require high availability, must be responsive even with
very large datasets (many tables that contain large numbers of complex records), and must protect
the data and maintain its integrity. Failure to support any one of these requirements can lead to
immediate loss of business, lower customer satisfaction, stress the users and damage the businesses
knowledge assets. Success in achieving these can improve the ease with which processes function,
leading to better efficiency, more capacity and high quality.
ERP systems are examples of transaction processing systems. Each activity within a process
sequence that is enabled by the ERP system is considered a transaction from an information systems
perspective. SAP ERP is an online transaction processing system.
2. Online Transaction Processing (OLTP)

A transaction is a response to an event in an enterprise system. In SAP ERP a transaction occurs
when the user selects the OK button (or equivalent) as part of a sequence of data entry or selection
actions on a form or sequence of forms. For example creating a sales order, requesting some
material or paying an invoice. The menu system in SAP ERP provides the user access to a wide range
of transactions. In the example below transactions are identified with technical names ( XD01 ) and
descriptions (Customer Create - Complete ).

OLTP & OLAP
Two views of SAP transactions
Transactions comprise many parts and each part can require accessing and updating information in
one or more database tables. All parts of a transaction must complete successfully for the
transaction as a whole to complete. An OLTP system should not permit partial completion of a
transaction because this can leave the database in a damaged state. This would compromise future
transactions and the ability of the enterprise to operate effectively.
Each transaction is regarded as a single logical unit of data processing that must be entirely
completed or entirely aborted. This is the role of two SQL commands that may be explicitly or
implicitly executed. A COMMIT statement attempts to complete all the operations involved in a
transaction. If any part of this is unsuccessful then a ROLLBACK returns the database to the state it
was in before the transaction occurred. This is one of the reasons that in SAP ERP and other ERP
systems too, the user has to keep confirming that they wish to complete transactions and why this is
not implied when the <return> key is pressed.
It is vitally important that the database is always left in a consistent state after each transaction. To
this end all modifications to data in the system must be performed via the database management
system (DBMS) via SQL statements. Direct manipulation of the data by programmatic means should
be avoided as this cannot be guaranteed to maintain consistency and other properties of a
transaction processing system.
Properties of Transactions
All transactions must maintain the following properties:
 Atomicity – all operations within a logical transaction must complete for the transaction to
complete or else they are all aborted.
 Consistency – all transactions must result in a consistent database state in which all the
business rules and referential integrity is maintained.

OLTP & OLAP
 Isolation – data used in one transaction cannot be modified by another until it has
completed. The first transaction locks the data, preventing modification. Subsequent
transactions can read the data but cannot change it.
 Durability – Once transactions are successfully committed they cannot be undone even if
there is a system failure.
 Serializability – concurrent transactions should produce the same results as the same
transactions carried out in series.
Not all database systems support transactions because they cannot guarantee the properties
described above. For example Microsoft Access does not support it even though it supports SQL.
More sophisticated databases such as Oracle, SQL Server and DB2 are full DBMS that support
transaction processing.
Some of the properties are not required when using single-user databases but ERP systems are
multi-user systems by definition. In particular an ERP system must implement controls on
serializability and isolation in addition to atomicity and durability in order to maintain a consistent
and integral database.
3. Online Analytical Processing (OLAP)

An online analytical processing system operates on multi-dimensional data rather than standard
relational database structures. The primary aim is to enable efficient reporting and analysis of
complex datasets without having to pre-specify reports. OLAP systems are the foundation of
modern data warehouses, business intelligence and data mining solutions.
In SAP OLAP data is structured using a combination of characteristics and key figures (values).
Characteristics are used to identify a piece of information (its context) and key figures provide the

OLTP & OLAP
values of data that describe its attributes. For example in the figure above Net Sales of 1,000 EUR
were recorded for product 310000 in the Foils product line of company 1000. This is not sufficient to
provide efficient manipulation of large datasets so in OLAP these InfoObjects (as they are termed in
SAP) are structured within InfoCubes.
Star Schema and Infocubes

The central unit of storage in OLAP is the InfoCube which is defined and manipulated via a star
schema.
An infocube is a multidimensional table or hypercube that contains InfoObjects. These are

structured using a star schema concept that uses a fact table that contains key figures (also known
as measures outside of SAP) and a number of dimensions that contain characteristics. The data in a
star schema can be used to assemble Infocubes that can then be used in reporting and analysis.
Slicing and Dicing

One example of how Infocubes are used in OLAP is provided by the following example that uses a
‘slice and dice’ approach to select data of some interest.
The example starts by specifying a subset of the characteristics of an infocube, listed here as
dimensions – this produces a query cache that is used thereafter in the slice and dice.
The query cache (cube) can yield a variety of analysis depending on key figure criteria. In the first
example the ‘division’ characteristic is filtered to provide only the ‘ceramics’ business data. In the
last example multiple dimensions are specified to yield key figures for a specific combination of
division and region.

OLTP & OLAP
Query Cache Cube

Dimensions
Product group
Customer group
North South East
Region
Division
Customer
group Area
DeptStores Company code
Wholesale
Retail Region
Glass- Ceramics Plastics
ware Period
Division Profit Center
Bus. Area
1 Analysis 2 Analysis 3 Analysis

of Ceramics of Plastics of Plastics division
division division and Southern region
South East
North South East

Region
Region
North SouthEast
Region
Customer Customer Customer

group group group
DeptStores DeptStores DeptStores
North
Wholesale Wholesale Wholesale

Retail Retail Retail
Glass- Ceramics Plastics Glass- Ceramics Plastics Glass- Ceramics Plastics
ware ware ware
Division Division Division
There are many other operations that can be performed on infocubes within an OLAP environment
but this should provide you with a basic appreciation of how operative transaction data in ERP can
be used for analytical purposes in an OLAP environment like SAP BI (Business Intelligence) that we
will discuss in a later chapter.
4. Comparison between OLTP and OLAP

There are many differences between OLTP and OLAP systems as shown in the table below. OLTP
systems contain detailed records that can be updated throughout their life in response to events in
the operational environment. By comparison OLAP systems manage data in summary form that
cannot be changed once it is entered, all data is a recorded snapshot of a period of operation.
OLTP records must be updated in real-time, they are valid for a duration but OLAP data is only a
reflection of the situation when it was transferred. The OLAP records are historical rather than
current; they always lag the present time.
OLTP systems are operated by operations staff and are based on predetermined requirements
(process definitions) whereas OLAP is used more by managers with less formalised requirements and
sometimes need to be formulated in an ad-hoc manner.
OLAP systems are not mission-critical in the way that OLTP systems are but they may be business
critical. If an OLAP system is unavailable then work can continue but the same is not true for OLTP
systems.
OLTP is used in SAP ERP to manage operative data which can later be fed to an analytical system
such as a business intelligence decision support system that is managed using OLAP techniques.

OLTP & OLAP
Operational (OLTP) Informational (OLAP)

Detailed Summarised
Can be updated Snapshot records, no updates allowed
Accurate up to the second Timestamp on each record

Used for clerical purposes Used by management
Built based on requirements Built without knowing requirements
Supports small uniform transactions Supports mixed workload
Data designed for optimal storage Data designed for optimal access
Very current data Mainly historical data

Data is application oriented Data is integrated
Referential Integrity is useful Referential integrity is not useful
High availability is normal High availability is nice to have

ERP Integration
The Quantitative Approach to IS
Evaluation
davis_n
3/17/2010
This chapter introduces the subject of information systems evaluation. It introduces the Productivity
Paradox and then discusses why this is no longer deemed valid. The quantitative approach using
Cost-Benefit Analysis and capital budgeting techniques is then described. There is a very brief review
of an investigation into the financial impact of SAP ERP on company performance before concluding
that whilst quantitative approaches are to be sought they are increasingly seen as only a part of the
evaluation method for information systems investments.
Contents
1. Introduction .................................................................................................................................... 3
2. Quantitative Approaches to Information System Evaluation......................................................... 5
Cost-Benefit Analysis .......................................................................................................................... 5
Project Cash Flows .............................................................................................................................. 7
Capital Budgeting................................................................................................................................ 7
Net Present Value ............................................................................................................................... 9
Internal Rate of Return ....................................................................................................................... 9
3. Financial Impact of Increasing ERP Scope.....................................................................................10
4. Conclusion.....................................................................................................................................10
References ........................................................................................................................................12

The Quantitative Approach to IS Evaluation

Preamble: The research and development of methods and tools to support the evaluation of
information systems (IS) is mostly combined with methods and tools for evaluating information
technology (IT). In fact, some authors use the term IT in an inclusive way to refer to both. The focus of
this course is information systems (IS) and therefore considers investments in application software
rather than IT which is taken to refer to hardware (including networking). ERP solutions are
information systems as we have already discussed.
1. Introduction
The contribution of IT/IS to business performance has been questioned by many authors at around
the time that ERP systems were emerging. During the 1980s many studies in the US attempted to
verify the assumption that investment in IT/IS would be positively correlated with productivity
improvements but they couldn’t show this. A comparison of technology investment, in particular
information technology, with white collar productivity showed that whilst spending increased there
was no measurable increase in productivity1. The result was the establishment of what has become
known as the Productivity Paradox2 : despite reasonable expectations that IT investment should
increase productivity because it reduces labour effort evidence shows this is not true.
An early comparison between IT investment and business performance (source: Roach ’91)
Since the late 1990s the existence of the Productivity Paradox has been argued against and in a
reference to a famous work of fictioni authors began to write of Paradox Lost: the idea that the
paradox was an illusion. The validity of various analyses supporting the paradox were criticised for
i th
Paradise Lost, by John Milton, a 17 Century poet.

having a weak method and poor data. Counter-analyses that looked at firm level data rather than
economy level data, and also took into account the time delay between investment and reward,
began to show reasonable correlations between IT investment and productivity3.
It is clear that business leaders accept the broad view that expenditure in IT can have a significant
impact on business performance. Expenditure on IT/IS continues to grow over the long term. Short
term variations such as the surge in spend to replace systems prior to the date change at year 2000
and the feared Millenium Bugii, may have made it difficult to correlate spend with performance for a
number of years prior to, and following, the year 2000. However, the answer to the question: “What
methods should be used for justifying IT expenditure?” remains elusive.
Evaluation of IT/IS is notoriously difficult. Many studies have identified a large number of techniques
which suggests that there is little agreement or consensus on what methods work. There also seems
to be quite a difference between the approach and methods that researchers and theorists propose
and those that people use in practice. Some have argued that this is because business managers are
bound by cultural ties to the investment appraisal techniques they use for other types of investment
(such as for plant and machinery) and are unable or unwilling to consider other types of approach.
For these managers, evaluation has become a ritual that they follow blindly. This doesn’t seem to
hold in the light of changes to the way managers have adopted non-traditional performance
measurement techniques like the Balanced Scorecard4 and suggests rather that the theorists
proposals are simply too difficult to learn and too complex to apply.
It is clear that IT systems do not lend themselves to formal analysis in the same way that other
investments do. A survey of Chief Financial Officers (CFO) identified little agreement on how to
tackle the issue of IT system justification5. Some CFOs deployed formal capital budgeting analyses
such as ROI on all IT investments while others applied it in some cases but not others; some had
avoided formal approaches completely and almost half were undecided and were continuing to
search for better methods. It is clear that decision makers are prepared to accept some justification
on non-financial bases and this is largely because of the intangible nature of many aspects of IT
systems.
The business value of IT/IS is difficult to measure, partly because these often yield intangible
benefits and partly because the range of areas in which benefits arise is so large. Four dimensions for
categorising costs and benefits have been identified6 and can help in managing the complexity of
this topic: Infrastructure, Process, Reach and Breakthrough. Efficiency gains are enabled as a result
better information integration through the use of technical infrastructure (hardware and software).
The benefits include increased productivity, increased functionality, user satisfaction, reduced costs
and quality. Effectiveness of operations is promoted by better processes that leverage existing
capabilities leading to increased profits, faster execution and responsiveness. The reach dimension
expresses the benefits that come from closer integration with value chain partners; leading to new
markets, business growth and capability acquisition through partnering. The final dimension
identifies the impact of IT in establishing new capabilities that change the competitive environment
such as new sales channels e.g. on-line retailing and trading.
ii
http://en.wikipedia.org/wiki/Millenium_bug

The valuation of intangible benefits arising from information system use is a major factor in the
uncertainty surrounding how to evaluate IT/IS projects. Intangible benefits are benefits that cannot
be touched - they do not result in things that can be measured directly -unlike a machine whose
output is a tangible product that can be counted, measured and valued in financial terms, intangible
benefits cannot be counted and their valuation is financial terms raises a number of concerns.
Examples of intangibles include customer and user satisfaction, ease of use, teamwork and
communication. Different people within an organisation will have different views about the business
value of intangible benefits and the value of the information system (which has been considered an
example of an intangible asset).
There are broadly two approaches to evaluating information systems: ‘classical’ investment
appraisal techniques that promote quantitative analysis, and more subjective techniques that seek
to assess intangible benefits using more qualitative measures. The Qualitative approach will be
discussed in a later chapter, the remainder of this chapter considers quantitative approaches. In
practice, decision makers are advised to ask for and consider the results of both types to form a
inclusive evaluation.
2. Quantitative Approaches to Information System Evaluation

From an economic perspective, an investment in information systems is an investment like any other
in business. An investment buys a firm ‘a factor of production’ – in this case an information system -
that should enable it to compete in the market. If the investment is successful then it will enhance
the firm’s ability to do business in some way that lowers its costs. For this reason, capital budgeting
techniques should be used to evaluate information system proposals.
Traditional capital budgeting techniques focus on financial measures and are quantitative in nature.
Cost-benefit analysis is a financially oriented technique for evaluating the cash flows associated with
an investment project that can be and has been used to evaluate information systems. Capital
budgeting technique such as discounted cash flow and net present value can be applied in support
of a cost-benefit analysis.
Cost-Benefit Analysis
Cost-benefit analysis (CBA) seeks to estimate and compare the costs and benefits of some project7. It
can be used as a planning tool for choosing between alternatives, as an audit tool for post-hoc
evaluation of projects once they are in use, and as a means of supporting subjective decisions with
quantitative ‘results’.
The basic cost-benefit equation that has been used for many years is to calculate the savings that
result by subtracting the investment and operating costs from the received benefits as follows:
Benefits-Costs= value (net cash flow)
In CBA all costs and benefits are expressed at some point in financial terms even if they are
intangible. Thus, CBA is not entirely objective because at some point costs or benefits have to be
allocated using subjective criteria and judgments. For example, the ease-of-use of a piece of

software can affect the likelihood of data errors, a benefit or cost (a negative benefit) can be
allocated to this on the basis of a judgment about the percentage improvement in ease-of-use
multiplied by the current cost of errors; but who says this is correct? It cannot be independently
measured or verified. A frequently cited example of the difficulty in allocating costs to intangibles is
provided by the answer to the question: What is the value of a human life? How should this be
measured? What is the scope of the life that should inform the answer and how can we account for
what might happen in the future – the person may find a cure for malaria, for example.
The value of CBA is that is allows all contributions to cost or benefit to be included. This doesn’t
mean that they automatically will and evidence suggests that failure to include all costs is one
reason for inadequate evaluations. Benefits on the other hand are often fully enumerated and this
exposes the potential for bias within CBA; although this is present in all evaluation techniques.
Information systems should be evaluated with all sources of cost and benefit included for the whole
duration or life cycle of the system. IT professionals refer to this as the Total Ownership Cost (TOC)
or Total Cost of Ownership (TCO) – see breakout box below.
In most companies in the past and even today, many projects are evaluated with regard to cash
flows that take place from design and development through to end of production/sales but this may
not include all of the cash flows for some projects. There are often up-front costs in market research
and in preparing preliminary bids that get hidden in general overheads and of course there are
disposal costs at the end of life. In some cases the disposal costs are very high such as in the nuclear
industry but these may not have been included in the initial planning. For example, decommissioning
costs for a nuclear power plant can exceed $200 million but these costs were often not included in
the initial investment plans for plants introduced in the 1960s and 1970s.
Life Cycle costing or Whole Life costing is a technique that seeks to recognise and account for all of
the costs of a project throughout its life including its disposal. This was not initially a response to
environmental issues but driven by un-recognised costs in US defence projects. A survey in 1974
identified that 27% of the US Department of Defense budget was allocated to operation and support
costs compared with 20% for initial procurement. This indicated that the initial capital cost was not
always the most significant outflow in a project and that downstream outlays were often significant
and should be included.
The whole life cost of a project is related to the term and concepts of Total Cost of Ownership that
is often cited by the vendors of IT systems. This is often used to explain the benefit that can
sometime accrue from investing more heavily in the initial stages in order to save costs later. We
might ask whether this is simply a ploy to help sell more sophisticated systems or to persuade a
client to upgrade to the latest version but there is no doubt that sometimes such investments are
cheaper in the long term.
Despite these drawbacks CBA retains a prominent position as the most applied financially oriented
and quantitative technique for evaluating information systems. To use it effectively not only does
one have to guard against bias but one also has to apply reasonable means of identifying relevant
cash flows. CBA cash flows can be discounted and used to compute return on investment (ROI)
although increasingly firms use Net Present Value (NPV) – these and simple payback are discussed in
the section on Capital Budgeting.

Project Cash Flows

In CBA and capital budgeting we only include the cash flows that result from the decision to accept
the project, these are known as relevant cash flows. These flows can be either capital cash flows or
operating cash flows. Capital cash flows relate to the initial investment cost and to the end of life or
‘terminal’ cash flows; for example decommissioning costs. Operating cash flows refer to the flows
involved in paying for materials, labour and other items needed to support the project and also the
revenues that come in from the goods or services that the project delivers to the market.
It is important to only include the amounts of cash that differ between the following two cases:
1. if the project isn’t accepted and

2. if it is, i.e. the incremental cash flows.
For example, if the project doesn’t change the amount of saleable output then there would be no
incremental difference in the revenue cash flow. On the other hand, If the current volume of output
is 10,000 units per annum at £100 per unit selling price and the new technology will raise the output
to 11,000 units per annum then the annual incremental cash flow would be £100,000 per annum
((11,000-10,000) units at £100). In this case there would also be an increase in direct material cost
for an additional 1000 units at an appropriate cost per unit and these would show as negative cash
flows.
Sunk costs should not be included in the appraisal. These are costs that have already been
committed and that acceptance or rejection of the project will not affect. They cannot be recovered
or reduced by the current decision. For example if a company has already invested a large sum of
money in developing a new product this should not be included in a current decision about whether
to develop a manufacturing facility as this is a sunk cost. Likewise, past decisions to invest in IT
systems and training should not be included as cash-flows in a current business decision, although
they may be considered for other reasons. However, if the current decision includes the acquisition
of new IT systems then these should be included.
Opportunity costs occur when the current project uses resources that could have been used to
generate revenues on other projects. In effect, by using these, a company is foregoing (going
without) an alternative revenue which may be generate more value (cash). Therefore, this is shown
as a cost in the current project evaluation. For example, if a company is evaluating a new product
that will use an existing vacant building or part of it, then it is foregoing the possible revenue that
could come into the business from selling the space or using it for more profitable purposes (if these
already exist).
Capital Budgeting
The method of appraising a capital investment project is called Capital Budgeting but has also been
known as Capital Investment Appraisal and Capital Expenditure Analysis or ‘CapEx’. Capital
budgeting decisions have a major impact on the value of a firm and the returns it can provide to its
shareholders/owners.

There are a number of different project types. Most projects in manufacturing are examples of
mutually exclusive projects: the acceptance of one project prevents others from happeningiii. Other
types include independent projects in which accepting one does not prevent another and contingent
projects in which the acceptance of one depends on the acceptance or rejection of another.
There are two main types of approach: Discounted Cash Flow (DCF) and non-DCF techniques. We will
deal with the second of these first as it is conceptually simple.
The simplest non-DCF technique is called the payback method. In this case we calculate the time
taken to recoup (earn back) the cost of the initial investment. We simply accumulate the incoming
cash-flows (without discounting for NPV) and identify when these exceed the investment cost. This is
then compared with a target time, usually in years, and if it is sooner or equal to this then the
investment is accepted. This technique can be used as a supporting method for DCF techniques and
may be useful if the project risk is high and therefore a quick return is desirable. The target time is
related to the break-even point, which one would hope is achieved at or before the payback target
time. If a project is terminated before it achieves break-even then it makes a loss. Unfortunately
some projects never break-even but sometimes this is marginally acceptable as they may still be a
source of cash flow (the cash being needed to meet short-term financial commitments).
DCF techniques are more sophisticated and take into account the time value of money. These
include the Net Present Value (NPV) and Internal Rate of Return (IRR) methods.
The key question that an investment appraisal method for a mutually exclusive project seeks to
answer is:
“Compared with other returns that could be expected from other investments, how
well does this project perform? Is it better or worse?”
In most cases this question can be simplified to compare the expected return from a project with
what could be received from a risk-free investment in government bonds. These produce a
guaranteed rate of return that is higher than the bank interest rate available to businesses.
To calculate this, we rely on the concept of the time value of money. This states that the value of
one dollar today (say) is worth more than one dollar in the future. For example, which of the
following would you choose?
A. £10,000 today
B. £10,000 in one year’s time
A, of course, and this is simple because we know that inflation exists and is usually iv increasing over
time but what about the next choice:
A. £10,000 today
B. £10,500 in one year’s time
iii
For example, having chosen to develop and produce the Airbus A380, the company would not develop an
alternative aircraft in the same market segment. It could develop a smaller aircraft but this would be a
different project in a different market segment.
iv
Not always though. Japan has suffered periods of deflation in recent years. This is when things get cheaper in
the future.

How much is inflation likely to be in the future? What rates will the banks be offering? Also, if we
invest in a business we expect to earn more than bank rates because we expect a premiumv for
taking risk but how much of a premium? This is why a ‘safe’ comparison is made by using
government bond rates because these are guaranteed, this is known as the discount rate.
Net Present Value

We express the time value of money by calculating the present value of future money. The present
value represents the amount of money needed today to match an amount in the future. For
example, if we expect to receive £1100 one year in the future as the result of an investment and the
discount rate is 10% then the present value of this is £1000 (£1100 *(100/(100+10)). The present
value is almost always less than the equivalent future value.
In capital budgeting we sum together the present values of all identified cash flows and arrive a Net
Present Value (NPV). If this is positive then the project may be expected to achieve the wealth
maximisation goal of the firm because it will add value to the business. If the NPV is zero then we
won’t lose money, the firm will cover its costs but won’t grow.. it will survive. If the NPV is negative
then the investment should not be continued and other investment opportunities should be
explored.
௡
‫ܥ‬௧
ܸܰܲ ൌ ෍ െ ‫ܥ‬଴
ሺͳ ൅ ‫ݎ‬ሻ௧
௧ୀଵ
Where n is the number of years over which cash-flows are generated; t is the future year and t=0 is
the present; C is the sum of cash-flows and r is the discount rate.
For example, if a project will incur an initial capital cost of £900 today and will generate net cash
flows in the next three years of £300, £400 and £600 (note that the revenue in year 1 is counted at
the end of the year, when t=1) and if the discount rate is 8% per annum. The NPV is:
£300 £400 £600

ܸܰܲ ൌ െ͉ ͻͲͲ ൅ + + = £197.01
(1.08)ଵ (1.08)ଶ (1.08)ଷ
This project will add £197.01 to the firm’s value and should be adopted if the capital can be
obtained. This last clause has been added because in recent times (since the credit crisis of 2008) it
has not always been possible to obtain credit i.e. borrow, because the banks do not have the
necessary liquidityvi. In such times the negative cash flows may need to be increased to cover the
higher charges lenders place on borrowing.
Internal Rate of Return

The Internal Rate of Return or IRR is a complementary DCF based approach to evaluating projects. It
differs from NPV by calculating the discount rate at which NPV=0. Recall that with NPV we start with
a discount rate and determine whether the NPV is positive (the criteria for acceptance because it
adds value to the firm). The calculated IRR is then compared with a predefined rate that is needed to
make it acceptable but the meaning of this in business terms is difficult to assess.
v
Premium in this case is an exceptional sum, an amount greater than would otherwise be expected, a prize.
vi
The ability to meet outstanding debts. If liquidity is low then lenders want to hold on to money to meet their
own obligations before they lend to others.

IRR is a goal-seeking approach that requires an amount of trial and error to establish the discount
rate at which NPV=0. We need to try different discount rates in an iterative manner. In the past this
was tedious and time consuming but now applications such as Microsoft Excel include functions for
solving IRR although this still requires an initial guess.
Many managers are more familiar with ‘rates of return’ as a concept and so may favour IRR
methods, however these can be difficult to calculate and it has been argued don’t actually indicate
how much value is added to the firm as a result of a project. It is suggested by some that IRR be used
to complement NPV i.e. use NPV as the primary measure and IRR as a secondary measure if
required.
The overall procedure for performing CBA is included at the end of this chapter as a flowchart in
Appendix A
3. Financial Impact of Increasing ERP Scope

In a paper from 2002 Hitt et al analysed the impact of SAP ERP solutions of the business
performance of a number of firms8. They concluded that ERP adopters did see greater than average
improvements in business performance across a range of factors, thus showing simultaneously a
rebuttal of the Productivity Paradox mentioned in the introduction.
Hitt also looked for evidence of synergistic effects resulting from increasing ERP scope. They
segregated their data according to the number and type of SAP modules that were implemented in
each of the firms whose data they analysed.
Level Functions within specified SAP Modules

0 Only one module (any type)
1 FI, MM & IS
2a FI, MM, IS & PM
2b FI, MM, IS & HCM
3 Functions from all modules
Table showing Hitt’s Levels of ERP adoption
They found evidence that business performance increased more the greater the scope of operations
covered in an ERP solution, although they did identify that increasing scope was also accompanied
by a reduction of benefit at Level 3 that they assign to managing the resulting IS complexity.
4. Conclusion
Formal methods using financial values are well established in management and popular even if the
way in which value is allocated to intangibles can be rather obscure and judgmental. Analysts have
to be careful to justify their methods for allocating costs to avoid their allocations being disputed by
senior managers; in all cases there should be a clear description of the rationale for allocating costs.
Despite the formal nature of CBA and capital budgeting techniques the difficulty in allocating costs
to intangibles which in one sense is strength, is a weakness too. Rather than apply somewhat
contrived allocations to convert intangibles into quantified values many people are increasingly

augmenting quantitative techniques like these with qualitative techniques. This will be the subject of
a later chapter.

References
1
Services under Siege - The Restructuring Imperative, Roach S.S., Harvard Business Review, Sept/Oct, 1991,
pp82-91.
2
The Productivity Paradox of Information technology, Brynjolfsson E., Communications of the ACM, Dec
1993/v36, No 12, pp67-77.
3
Beyond The IT Productivity Paradox, Willcocks L., Lester S. (eds), Wiley, 1999.
4
The Balanced Scorecard – Measures That Drive Performance, Kaplan R.S., Norton D.P., Harvard Business
Review, Jan-Feb 1992, pp 71-79.
5
‘One Way, or Another? CFO IT, 2004
6
IT Performance Management, Wiggers et al, Elsevier, 2004.
7
Cost-Benefit Analysis in Information Systems Development and Operation, King J.L., Schrems E.L., Computing
Surveys vol 10 No1, March 1978, pp19-38 (now in ACM Digital Library)
8
Investment in Enterprise Resource Planning:Business Impact and Productivity Measures, Hitt L.M. et al,
Journal of Information Systems Management, v19 (1), 2002, pp71-98.

APPENDIX A

SAP ERP
Master Data
PP and LO
SAP ERP
Production Planning & Execution (PP)

SAP ERP Production Planning
• SAP Divides Production into multiple processes

– Production Planning
– Manufacturing Execution
• Discrete Manufacturing
• Repetitive Manufacturing
• KANBAN
– Production – Process Industries

• Integrated planning tool for batch-orientated process
manufacturing
• Design primarily for chemical, pharmaceutical, food and beverage
industries along with batch-oriented electronics
SAP ERP Structure
• Client
• Company Code
• Plants
• Storage Locations
• Work Center Locations
SAP ERP PP Master Data
• Materials
• Bill of Materials (BOM)
• Routings
• Work Centers
• Product Groups
SAP ERP Material Master Record
SAP ERP Bill of Materials (BOM)
• List of components that make up a product or assembly
• Frame  Saddle
• Pedal - Post
• Break Kit - Seat
- Clip
• Front Wheel
– Front Rim
 Handle Bar
– Front Tire
- Bell
– Front Tube - Clasp
• Rear Wheel - Handle
– Rear Rim
– Rear Tire
– Rear Tube
– Gear
• Single-Level
Single-Level
Finished Bike
Frame Front Wheel
Pedal Kit Rear Wheel
Brake Kit Saddle
Handle Bars
• Single-Level vs. Multi-Level
Single-Level
Finished Bike
Single-Level Single-Level Single-Level Single-Level
Rear Front Handle

Frame Pedal Brake Saddle
Wheel Wheel Bars
Rear Front
Bell Bell
Rim Rim
Rear Front
Clasp Clasp
Tire Tire
Handle Handle
Tube Tube
Bar Bar
Multi-Level BOM
Gear
• Variant Bill of Material (BOM)
– Several products with a large proportion of identical parts.
Single-Level Single-Level
Finished Bike Finished Bike
Graphite Frame Front Wheel Tubular Frame Front Wheel
Pedal Kit Rear Wheel Pedal Kit Rear Wheel
Brake Kit Saddle Brake Kit Saddle
Handle Bars Handle Bars

SAP ERP BOM – Item Categories
• Item Category
– Stock Item
– Non-stock Item
– Variable Material – Sheet of steel
– Intra Item – Phantom material – process industry
– Class Item – place holder
– Document Item
– Text Item
SAP ERP Routings
• Routings enable you to plan the production of
materials (products).
• Routings are used as a template for production
orders and run schedules
• Routing are also used as a basis for product
costing.
• Series of sequential steps (operations) that must
be carried out to produce a given product
• Routings contain:
– What, Where, When, How
SAP ERP Routings
• Routing – Operation 10
– Explains the steps involved in this operation
• BOM – Front Wheel, Rear Wheel and Frame
– Outlines the components that will be
consumed in the routing
• Work Center – 00WC1
– Identifies were the operations will take place
and identifies the business transaction to be
carried
SAP ERP Routings
• Routing for Finished Bike
Operation Plant Description Activity Type
Work Center Control Key Time and Unit of Measure

SAP ERP Routing and BOM
Material Master – Finished Bike
Routing BOM Products arrive at the

beginning of the operation to
Oper. 10 Front Wheel which they are assigned
Rear Wheel Op. 10 Op. 20 Op. 30

Oper. 20
Frame
Oper. 30 Saddle
Front Saddle Handle
Wheel Bars
Oper. 40 Handle Bars Rear
Wheel
Oper. 50 Pedals Frame
Pedals Time
Component assignment in routing

SAP ERP Work Center
• A location within a plant where value-added work (operations or
activities) are performed
– Work Centers can represent
• People or Groups of People
– Johnny Storm, Day Shift 1
• Machines or Groups of Machines
– Ink Mixer, Ink Injection Machine
• Assembly Lines
– Pen Assembly Line 2
• Work center used to define capacities
– Labor
– Machine
– Output
– Emissions
• Capacities used in
– Capacity requirements planning (CRP)
• Detailed scheduling
• Costing
SAP ERP Work Center
• Work centers capture and use the following Resource
Related data
– Basic Data
• Person Responsible, Location of Work Center
– Scheduling Information
• Queues and Move Times (interoperation), Formula Keys
– Costing Data
• Cost Center, Activity Types
– Personnel Data
• People, Positions, Qualifications
– Capacity Planning
• Available Capacity, Formulas, Operating Time
– Default Data
• Control Key, Standard Text Key
SAP ERP Product Group
• Aggregate planning that group together
materials or other product groups (Product
Families)
• Multi- or Single- Level Product Groups
Bikes
– The lowest level must always consist of materials
Mountain Touring
18 Speed 24 Speed 18 Speed 24 Speed
Red 24M Blue 24M Red 24T Blue 24T

SAP ERP Production Planning & Execution
SIS Forecasting CO/PA
Sales & Operations

Planning
Strategic Planning
Demand
Management
Detailed Planning
MPS
MRP
Manufacturing Procurement
Execution Process
Order
Settlement
Manufacturing Execution
SAP ERP Production Planning & Execution
• Players in the Game
– Strategic Planning SIS Forecasting CO/PA
• CEO, COO, CIO,
CFO, Controller, Sales & Operations Strategic Planning
Marketing Planning
Director
– Detailed Planning Demand
• Line Managers, Management
Production
Scheduler, MRP Detailed Planning
Controller, MPS
Capacity Planners
– Execution MRP
• Line Workers,
Shop Floor
Supervisors
Manufacturing Procurement
Execution Process
Order Manufacturing Execution

Settlement
SAP ERP Planning Levels
Bikes Planning at
Product Group
Level
45% 55%
Mountain Touring
30% 70% 40% 60%

40% 60% 50% 50%

Planning at Material Level

SAP ERP Sales and Operations Planning (SOP)
• Information
Origination
– Sales
– Marketing
– Manufacturing
– Accounting
– Human Resources
– Purchasing
• Intra-firm
Collaboration
– Institutional
Common Sense
SAP ERP Sales and Operations Planning (SOP)
• Flexible forecasting
and planning tool
• Usually consists of
three steps:
– Sales Plan
– Production Plan
– Rough Cut Capacity
Plan
• Planned at an
aggregate level in
time buckets
SAP ERP Demand Management
• Link between Strategic Planning (SOP) & Detailed Planning
(MPS/MRP)
• The results of Demand Mgmt is called the Demand Program, it is
generated from our independent requirements - PIR and CIR
Product Groups Bikes

Disaggregation
45% 55%
Mountain Touring
30% 70% 40% 60%

40% 60% 50% 50%

Material Red 24M Blue 24M Red 24T Blue 24T
SAP ERP Demand Management
Forecast Sales
Planned Customer
Independent Independent
Requirements Requirements
Demand
Program
MPS / MRP
SAP ERP Transfer from High Level to Detailed Planning
Planning at Group Bikes Demand

Level Planning Data
45% 55%
Disaggregation
Mountain Touring
30% 70% 40% 60%

40% 60% 50% 50%

Planning at Material
Level
Transfer
Operative Planned Independent Requirements

Planning
Data At Material and Plant Level
SAP ERP Master Production Scheduling (MPS)
• MPS allows a company to distinguish planning
methods between materials that have a strong
influence on profit or use critical resources and
those that do not
MPS Items
MPS run
Bike Set Non-MPS Items
Helmet FG-0010-00 Gloves
Frame Handle Bars Saddle Etc.

SAP ERP Material Requirement Planning (MRP)
• In MRP, the system calculates the net requirements while
considering available warehouse stock and scheduled
receipts from purchasing and production
• During MRP, all levels of the bill of material are planned
• The output of MRP is a detailed production and/or
purchasing plan
• Detailed planning level
– Primary Functions
– Monitor inventory stocks
– Determine material needs
• Quantity
• Timing
– Generate purchase or production orders
SAP ERP Demand-Independent vs. Dependent
• Independent Demand – Original source of the demand.
• Dependent Demand – Source of demand resides at
another level.
Single-Level
Indep
MPS
Bike Set
Planned Order
Multi-Level
Dep Dep
MPS MRP
FG-0010-00 Helmet
Planned Order Purchase Order
Dep
MRP
Brake Kit
Purchase Order
SAP ERP Material Requirement Planning (MRP)
• MRP is used to ensure the availability of

materials based on the need generated by
MPS or the Demand Program
– 5 Logical Steps
• Net Requirements Calculation
• Lot Size Calculation
• Procurement Type
• Scheduling
• BOM Explosion
SAP ERP Procurement Type
• External Procurement
– Purchase Requisition
– Purchase Order
– Schedule Line
• Internal Procurement
– Planned Order
– Production Order
– Process Order
SAP ERP Multi-Level Scheduling
Requirements
Planned Order Date
Purchase Requisition
Finished Product
Assembly 1
Semi-Finished Good
Raw Material
Component
Time
SAP ERP Output of MRP
MRP
In-House External
Planned Order
Production Procurement
Convert to
Production Purchase
Orders Requisitions
Process Purchase Schedule

Orders Orders Lines
SAP ERP Orders, orders, orders
• Planned Order (planning)
– A request created in the planning run for a
material in the future (converts to either a
production or purchase order)
• Production Order (execution)
– A request or instruction internally to produce a
specific product at a specific time
• Purchase Order (execution)
– A request or instruction to a vendor for a material
or service at a specific time
SAP ERP Manufacturing Execution Process
Capacity
Production Planning Schedule
Proposal and Release
(Planning/Other)
Shop Floor
Documents
Order
Settlement
Goods
Issue
Goods
Receipt Completion
Confirmation
SAP ERP Production Order
How
What BOM
Quantity Production Orders define the

following:
Time Line
Material produced
Quantity
Location
Time line
Work involved
Resources used
How to costs are settled
SAP ERP Schedule
• Calculates the production dates and capacity
requirements for all operations within an
order
– Determines a Routing
• Operation specific time lines
• Material Consumption Points
– Material Master
• Scheduling Margin Key (Floats)
– Work Center
• Formulas
• Standard Inter-operation Times
SAP ERP Release
• Two release processes
– Header Level
• Entire order and all operations are released for
processing, order is given a REL status
– Operation Level
• Individual operations within an order are released, not
until the last operation is released does the order
obtains a REL status until then it is in a PREL status
• Automatic vs. Manual
SAP ERP Availability Check
• Automatic check to determine whether the
component, production resource tools, or
capacities in an order are available
– Can be automatic or manually executed
– Determines availability on the required date
• Generates an availability log
– Displays results of the check
– Missing parts list
– Reservations that could not be verified
SAP ERP Schedule & Release
• The time between scheduling and releasing
an order is used for company checks and any
preparation needed for the processing of the
order
• Once an order has been released it is ready
for execution, we can at this time
– Print shop floor documents
– Execute goods movements
– Accept confirmations against the order
SAP ERP Shop Floor Documents
• Shop Floor Documents are printed upon release
of the Production Order, examples would be:
– Operation-based Lists
• Time Tickets, Confirmation Slips
– Component-based Lists
• Material Withdrawal Slips, Pull List (consumption list)
– PRT Lists
• Overview of PRT’s used and in which operations
– Multi-Purpose Lists
• Operation Control Ticket, Object Overview
SAP ERP Confirmations
• Confirmations are used to monitor and track the
progression of an order through its production cycle
– Confirmation can be done at the operation or order level
• Exact confirmation shortly after completion of an
operation is essential for realistic production planning and
control
• Data that needs confirmation include
– Quantities – yield, scrap, rework
– Activity data – setup time, machine time
– Dates – setup, processing, teardown started or finished
– Personnel data – employee who carried out the operation,
number of employee involved in the operation
– Work center
– Goods movements – planned and unplanned
– Variance reasons
– PRT usage
SAP ERP Confirmations
• Acceptance of the confirmed quantity of
output from the production order into stock
– Effects of the Goods Receipt
• Updates stock quantity
• Updates stock value
• Price stored for future valuation changes
• Production order is updated
– Three documents are created
• Material document
• Accounting document
• Controlling document
SAP ERP Order Settlement
• Settling a Production Order to Stock
– Debt posting is made to the Production Order
with the value of the material
– Difference between the debt posting and credit
posting is posted to a price difference account
Material Prod. Order Price Diff.
80 100 20
**Material Price determine by the quantity produced times the Standard Price in the Material Master.
• Costs analyzed
– Primary
• Materials
• External Processing
– Secondary
• Production, Material, and Administrative Overhead
• Labor
• Cost Analysis Reporting

– Calculate and analyze planned costs, target costs, and
actual costs of the production order.
– Calculate and analyze variances
SAP ERP Order Status
ERP Integration
The Qualitative Approach to IS Evaluation
davis_n
[Pick the date]
This chapter considers the use of qualitative approach to information systems evaluation and
focuses on the use of the Strategy map as a way of assessing the alignment between ERP solution
and business requirements.
Contents
1. Introduction .................................................................................................................................... 2
Information Systems as Strategic Investments....................................................................................... 2
The Influence of the Balanced Scorecard ........................................................................................... 2

1. Introduction
The application of qualitative approaches to information systems evaluation has grown in scale and
significance in the last 10 years as a reaction to difficulties experienced in applying quantitative
methods. The main reason for this lies in the nature of the business effects that information systems
have. Some effects can have a direct impact on bottom-line performance by automating some tasks
and speeding up others. These directly influence labour costs and have a directly measurable
financial impact. However many of the effects are intangible and not directly measurable; some
people regard the attempt to quantify them as misguided and instead better served using qualitative
measures.
The use of qualitative measures that rely more on subjective assessments of benefits (primarily)
should not be regarded as inferior to formal quantitative approaches: they can be just as formal.
Nevertheless, they should not be seen as a convenient escape route to avoid thinking about
evaluation carefully.
Information Systems as Strategic Investments

The strategic impact of information systems is clear but this does not in itself justify the avoidance of
formal evaluation. While many managers are reported to justify IS as strategic and necessary to
counter competitor’s actions and capabilities irrespective of their costs, this is not rational. Faith in
the power of information systems is touching but not scientific. The fact that they are strategic is an
argument for evaluation not against it.
There may be a case for limited evaluation on the basis that certain information systems are either
qualifiers or in some way mission-critical. A qualifying system is needed in order to do business of
any sort. For example, in the UK now it is almost unthinkable for a travel agency not to have an
online presence and hence this requires a system to support this. Mission critical systems are
different, they aren’t qualifiers (competitors may or may not have equivalent capability) but might
be needed to support new ways of doing business that are deemed strategic in nature and required
now. The absence of a system in such situations would expose the business to such high risk that a
system at almost any cost is regarded as acceptable.
The Influence of the Balanced Scorecard

Senior decision makers increasingly understand that traditional financial measures of performance
are not inclusive and require support from other techniques. The Balanced Scorecard has been
adopted quite widely, particularly in large firms, to address the weakness of traditional measures in
capturing the use and performance of intangible assets such as innovation and continuous
improvement activities1. This ability to represent the contribution of a range of intangibles in a way
that managers can grasp and make us of is what makes the balanced scorecard concept of interest in
information systems evaluation.
The balanced scorecard accommodates a range of measures including financial and operational
measures along 4 dimensions that are presented using a grid. The four dimensions are:
 Customer view
 Internal view

 Innovation and Learning

 Financial
The following example is taken from SAP training materials:
Balanced Scorecard Views (original source: The Balanced Scorecard Collaborative)
Each view or perspective is qualified with a relatively small number of goals and summary measures
that express their achievement. The process for selecting these and allocating measures to them is
by executive level consensus. Once established the scorecard becomes a tool for monitoring
progress towards their achievement and as a means of then prioritising action. Variances in the
performance against plan act as signals that something needs to be done and in what area. In fact,
information systems provide an important function in the context of operating the scorecard. As
Kaplan states:
“Information systems play an invaluable role in helping managers disaggregate the summary
measures. When an unexpected signal appears on the balanced scorecard, executives can query their
information systems to find the source of the trouble. If the aggregate measure for on-time delivery
is poor, for example, executives with a good information system can quickly look behind the
aggregate measure until they can identify late deliveries, day by day, by a particular plant to an
individual customer.”
2. The Strategy Map as an Evaluation Framework

The thinking behind the balanced scorecard has led to the development of techniques for evaluating
intangibles as exemplified in Kaplan and Norton’s later work in developing Strategy Maps2 which we
saw earlier in the context of requirement identification.

The foundation for this approach to evaluating IS is located in the information capital element of the
strategy map which considers the role of systems, databases and business networksi.
The method for applying this to evaluation relies on understanding corporate strategy for revenue
growth and productivity increase. This helps identify the financial and customer measures and what
internal processes have to deliver. Evaluation of any proposed information system proceeds by
assessing the support it provides for these key attributes and the alignment of system capabilities
and process support with the high-level strategy and through this to shareholder value.
The specific evaluation of information systems can be further categorized according to applications
and technology. Some applications and functions provide a transformation capability: they change
the nature of business and allow it to operate in new markets and in new ways extending its reach
and providing breakthrough opportunities. Some applications help the business analyse how
effective it is in supporting its existing customers. Other applications support the hour-by-hour
execution of business processes that result in efficiency gains; these are termed transaction
processing applications and are the core of an ERP solution. Technology infrastructure provides the
final category; of particular note are the openness and adaptability of the software and its ability to
integrate with services on the web.
i
Not hardware networks but the communication channels between data sources and applications.

Final ranking of the proposed solution can be carried out in a number of ways using combinations of
consultations, surveys and focus group meetings. Rankings may need to be moderated to ensure
that a consistent and balanced view is achieved.
3. Discussion
The strategy map provides a framework into which qualitative evaluation of an information system
proposal can be made. It doesn’t seek to provide a financial evaluation but instead provides a broad
and inclusive view of the strengths and weaknesses of the proposal in the context of a defined
strategy.

The development of a formal business case that can be used to help senior decision makers decide
whether or not to invest in a particular proposal could be based solely on the results of a qualitative
analysis but in the case of an ERP solution should also be supported by some form of formal cost
benefit analysis.
Cost-benefit analysis is more likely to support a justification in terms of the effects of efficiency gains
in the executions of day-to-day business processes – in the transaction oriented applications and
functions. Qualitative evaluations can support this level but also provide less contentious
assessments of more strategic factors because they don’t require conversion into financial terms.
References
1
The Balanced Scorecard – Measures That Drive Performance, Kaplan R.S., Norton D.P., Harvard Business
Review, Feb 1992 pp71-79.
2

ERP Integration
Process Alignment
davis_n
2/16/2010
This chapter introduces the importance of business process in modern organisations and looks at
how they can be modelled and managed as part of an integrated information systems environment.
It briefly reviews the evolution of business process reengineering into business process management
and concludes with some observations about the relevance of this to ERP systems.
Contents
1. Introduction .................................................................................................................................... 2
2. Business Processes.......................................................................................................................... 3
Standardization................................................................................................................................... 5
3. Business Process and Information Systems.................................................................................... 6
Approaches to BPR.............................................................................................................................. 7
Lean versus Function .......................................................................................................................... 8
Business Process Management.........................................................................................................10
4. Conclusion.....................................................................................................................................11
References ........................................................................................................................................11

Process Alignment
1. Introduction
A growing realisation that started during the 1980s and 90s and continues today is that successful
businesses are often those that not only have desirable products but also have processes that
deliver these effectively. Thus, there has been a shift in focus from only considering product
development to understanding how process affects the flow of information and materials across
functional boundaries in an end-to-end way (i.e. from start to finish). Firms have re-discovered their
purpose: to satisfy customer requirements rather than only their own internal goals1.
Enterprise information systems have a central role to play in the definition, operation and
management of business processes, particularly those that span organisational units. Business
applications encode a way of working in the way they operate, if this matches with what the users
require in order to do their jobs then processes are enabled, if there is a mismatch between the
information systems and the way of working then processes may be inhibited.
There is a perceived conflict in many organisations between the desire to operate end-to-end
business processes and the desire to retain existing organisational units that are organised according
to function. Whether these are mutually exclusive or whether one is superior to the other remains
to be seen. The use of matrix organisations is one way that this has been managed and Lean
Thinking2 is seen by many as another very effective way to approach the development of more
effective processes. While Lean may be effective within an individual organisation there is some
question about whether its techniques are suited to processes that span enterprise boundaries. How
is process performance influenced by the span of action that one person executesi? How much of
the process should an individual be expected to carry out? What is the role of information systems in
supporting process execution?
Process Management has emerged as an idea to counter the conflict between horizontal process
and vertical management (protectionism and hierarchy). This creates new roles, values and culture
within a firm. Changes need to be made in the way in which products are developed, resources are
allocated and accounts are prepared. The aim is to align the various activities that a business needs
to perform in an efficient and effective way so that value is added for the customer and waste is
eliminated.
For many firms that operate on a global basis there is a need to standardise processes and deliver a
consistent interface to customers, many of whom also operate on a global scale. This is particularly
evident when a product or service is the result of activities that take place in different locations,
under different management. Customers should not have to learn and adopt different methods to
access these services, they should not see or even be aware that this is the case even if it is.
Customers typically value consistency; they like easy to operate and familiar processes that appear
stable and new process that add value to them in some way. This applies whether they are external
customers of goods or services or internal customers who support the delivery of goods and
services.
i
The verb ‘execute’ is used in the sense of carrying out some task or action rather than the meaning to kill.

Process Alignment
The changing attitudes of managers towards process affects the way businesses organise themselves
and how they define, execute and manage their business processes and systems. The design and
operation of information systems often imply a certain way of executing process (in the way that
they present information and require data entry). The challenge for system architects, designers,
implementers and users is to align the information system logic with the business process logic, and
ensure that information is provided at the right time to the right people in the right format.
When an effective business process has been designed opportunities then arise to automate some
of the process steps. This speeds up the process, reduces the labour cost associated with carrying
out routine tasks and frees-up time for people to improve products, services and processes so that
new business can be won.
2. Business Processes
Business organisations exist to make money by selling goods or services to end users or to other
organisations. Manufacturing organisations do this by creating tangible products such as cars,
cameras and washing machines, service organisations do this by providing intangible goods such as
software, insurance, banking and healthcare.
In order to deliver goods or services firms typically have to perform a number of tasks. Each task
takes some inputs in the form of materials, information or both; requires a set of resources: a
suitably qualified person or capable machine to perform it; and produces one or more outputs in the
form of transformed material, checked or authorised information and sometimes waste products.
A process describes the sequence in which a set of tasks should be executed and may also specify
the resources and information needed at each step. The order in which tasks are carried out affects
both the quality and cost of delivering the final output; therefore process design has a fundamental
effect on organisational performance.
Business processes are performed in part or as a whole by one or more ‘actors’. In most
conventional processes these are humans who create paperwork, enter data, check information and
perform physical tasks. Each actor is responsible (or in control) for a span of the process: a number
of activities in the sequence.
It is often convenient to describe processes using diagrams rather than words. A diagram is concise
and explicit, it uses a limited set of symbols in a formal way, it makes it possible to exchange the
definition of a process in an unambiguous manner avoiding some of the misinterpretations that can
arise when we use natural language. A diagrammatic description can be processed automatically
using machine-based reasoning i.e. by computer programs, and these can be exploited by
information systems. People often use the term process mapping to refer to the use of diagrams.

Process Alignment
Step 1 Step 2 Step 3
A generic process
There are a number of common business processes that can be seen in most organisations; these
include procurement, production and order fulfillment. All firms need to procure resources; this
involves identifying sources, negotiating prices and delivery, placing orders, receiving the orders and
settling financial accounts. Production involves identifying requirements, obtaining materials,
allocating resources, releasing orders, executing tasks and receiving finished goods. Fulfilment
involves receiving orders, preparing shipment, sending goods, invoicing the customer and receiving
payment.
Create & Send

Create Purchase Receive Goods Receive Invoice Send Payment
Purchase Order
Requisition (PR) (GIN) From Supplier To Supplier
(PO)
Procurement process
Identify
Obtain Allocate Release Works Execute Receive Into
Requirements
Materials Resources Orders (WO) Production Stock
(MRP)
Production process
Receive
Prepare Send Invoice To Receive
Customer Order Send Shipment
Shipment Customer Payment
(SO)
Order-to-Cash process
The procurement process can start in one of many functional areas. A purchase requisition could be
created to request material for production by a material or stock controller from the operations
function, by a manufacturing engineer working in the manufacturing department requesting a new
machine, or by a range of other people working in a variety of departments. A purchase order must
be raised within the purchasing function and when goods are received this is done by someone in
the Inventory or Warehouse department who records details on a Goods Inwards Note. Invoices are
received and auctioned by people working in the finance department who must check that the
correct goods were received in the quantity ordered and only then can payment be authorised.

Process Alignment
It should be clear that the execution of business processes involves the exchange of material and
information between numbers of people working in different functional areas. A lot of information
has to be created, checked and transferred. In the past this was done using paperwork and still is.
Today the information can be managed by information systems but paperwork is still widely used in
parallel to capture information and to record its verification and authorisation via signatures or
stamps.
The generic processes described before are only

Activity
high-level descriptions and do not provide
enough detail to define real-world actions. To do
this the process steps can be decomposed into
more detailed tasks that can be broken down
further until individual elements of work are
reached. As more detail is added alternative
Activity Activity actions often arise that require branching in the
process definition. Some tasks can be performed
in parallel with other tasks i.e. at the same time.
Some tasks are exclusive i.e. if one task is
Activity Activity
performed then another is not. Most detailed
business processes involve combinations of
sequential, parallel and conditional branching,
with some merging of sequences and
recombination of flows from parallel back into
Activity
sequential steps. These can all be represented in
diagrammatic form using a range of techniques.
An example of a generic parallel process
The speed with which business processes can be performed has a direct influence on its
performance. Faster processes can deliver new products to market before competitors and in this
way they earn more profitable business, they can deliver existing products to customers quicker,
they consume less working capital and so overall have an impact on the firm’s revenue, its costs, and
its profitability.
In a global environment firms also need to consider how best to present their processes to an
expanding range of customers and partners, from an expanding number operating divisions and
country organisations. This raises the issue of standardisation and whether one process should fit all
people or whether they should be tailored to suit local conditions.
Standardization
In traditionally organised firms where management is exercised along functional and departmental
lines standardisation is difficult. Each unit has operational independence and is free to adopt
whatever processes suit it best, often according to local and internal requirements. The voice of the
customer is hard to ‘hear’ and may not be regarded as significant. The same customer may have to

Process Alignment
learn different ways of dealing with different units within the same company and this is a source of
inefficiency and waste.
By standardizing the way in which business transactions are performed not only as individual steps
but also in a sequence we hope not only to improve the customer’s experience but also gain
efficiencies for the business as a whole. These arise from three sources [Hammer & Stanton 99]:
The overhead cost associated with installing and maintaining a standard process is less than the cost
of doing this for many processes. Only one standard rather than many local ones needs to be
developed; documentation and training costs are reduced; and fewer staff are needed to design the
process and regulate it. Variances from the standard are easier to spot and quality is safeguarded.
Secondly, internal and external customers see a consistent and regular presentation of information
and gain familiarity sooner. This improves the efficiency in performing transactions and the quality
of data – its accuracy and meaning. Overall one should expect the transaction costs to fall as a result
of standardisation. When IT is aligned with a standardised process, opportunities exist to exploit
shared information and further reduce costs. For example, it becomes possible to rationalise
supplier lists and gain benefits from price discounts; alliances are easier to form and can lead to
further benefits.
Thirdly, Hammer & Stanton argue that standardisation promotes flexibility by making it easier to re-
allocate human resources without the need for re-training. The consistency of process and IT
interface is what makes this possible. That standardisation should promote flexibility may seem a
little counter-intuitive at first because many people regard a fixed process as inhibiting freedom of
action. There is a difference though between uncontrolled action and controlled action. In the first
case although it may indeed be possible to initiate an action outside a formal process more quickly,
the long-term costs of doing this may outweigh the short-term benefit. Uncontrolled ‘flexibility’ can
lead to chaos and much management action to resolve.
However, standardization is not without its problems, and in some cases it is beneficial to have some
process diversity. All customers are not the same, different products and different markets require
different levels of support, buying items in bulk and buying them individually require different
information and different negotiations on price, delivery and performance. In general, Hammer
suggests that standardization should be pursued as the default unless a good case can be made for
diversity. He acknowledges that diversity is often the easier course for many managers but warns
that this can often be motivated by a desire to maintain established boundaries and autonomy
rather than a customer-focussed position.
3. Business Process and Information Systems

Most firms need to adapt their business processes to meet the changing demands of the business
environment and to exploit what new technologies can provide. At various times in the last 20 years
management theorists have focussed on the role of business processes in making businesses more
efficient, effective and competitive. The need for effective business processes is not new, it has
always been important and people have developed approaches to tackle aspects of it for many
years. However, it wasn’t until the 1990’s that business processes gained the prominence and
recognition that they now have. At first this was through the development of business process

Process Alignment
reengineering (BPR) and more recently through its further development and integration with other
ideas (such as Total Quality) into business process management (BPM). ERP and other IS developers
and consultants now promote the use of business process management systems that can be used to
define, implement and deploy business processes that are integrated with information systems such
as ERP, SCM and others.
The business environment determines the relative power between customers and suppliers, the
speed of response needed to satisfy demands and the changing way that businesses collaborate with
external organisations to deliver goods and services. The environment is not fixed but is constantly
changing and therefore we might expect business processes to need to change as a response to this
in order to maintain market position and sustain corporate strategy.
New technologies provide the means by which people can share information and process, track
changes and status within a process and respond to customers’ needs. Enterprise Information
systems provide much of this capability either as part of a homogeneous toolset such as SAP
business solutions or by combining tools from different vendors using emerging technologies which
we will consider in another chapter.
BPR refers to the redesign of business processes using structured approaches, often enabled by
process mapping and resulting in revised organisational structures, responsibilities and spans of
control. Many practitioners believe that it is most effective to have one person carry out as wide a
span of control as possible as this shortens the time to complete an activity sequence. The reason
for this is that there are fewer handovers between actors and less need to keep storing and then
retrieving information.
Approaches to BPR
Over the years a number of approaches to re-engineering processes have emerged. At a high-level
there has been a debate about whether to redesign process from the beginning i.e. to discard any
existing process and start as if for the first time; or to make small incremental changes to existing
processes. The main protagonists in this debate were Hammer & Champy3,4 who argued for radical
change and Davenport who agreed at first and later argued for more incremental change because
this was easier to manage and less risky.
These main proponents of BPR defined it as follows:
"... the fundamental rethinking and radical redesign of business processes to achieve dramatic
improvements in critical contemporary measures of performance, such as cost, quality, service, and
speed." Hammer & Champy ‘93
"...encompasses the envisioning of new work strategies, the actual process design activity, and the
implementation of the change in all its complex technological, human, and organizational
dimensions." Davenport ‘93
Davenport5 identified five concepts that BPR in its initial development was founded on but then
argued that the idea that these were unique to BPR was false.

Process Alignment
1. A clean slate approach to organizational design and change.

2. An orientation to broad, cross-functional business processes, or how work is done.
3. The need for, and possibility of, radical change in process performance.
4. Information technology as an enabler of change in how work is done.
5. Changes in organizational and human arrangements that accompany change in technology.
Davenport’s observations about the role of information systems and whether these should lead
reengineering or be an equal partner are particularly pertinent. In many firms reengineering was led
by information systems developers but experience showed that this approach often created a mis-
match between the processes that people used and the processes that the information system
eventually implemented. Furthermore, long time delays while systems were designed and
implemented often meant that physical process change was inhibited or proceeded with no concern
about later integration. Davenport argued that information systems developers need to work more
closely with process owners to develop a joint plan and one that tackles the significant process
issues first.
Today the principle ideas and goals of BPR have become widely accepted. Radical reengineering is
generally avoided if possible because the shock to the enterprise can be severe and the risk of failure
is high. Smaller scale of change is more common.
Firms now focus increasingly on the management of business processes and the adoption of best
class processes before amending these to develop competitive ‘new’ or ‘next’ processes. Many
enterprise information systems embed what are referred to as World Class processes within the way
they work. The challenge for users of these systems is then how to modify them so that they can
develop processes that offer competitive advantages, of which we will discuss more later.
In recent years, starting in manufacturing and spreading to other domains, what has been termed as
the ‘Lean’ approach has been promoted as a way of addressing the process needs of business. This
contrasts markedly with some of the more IT-centric ways of enabling processes in more functionally
oriented firms.
Lean versus Function

Much has been written about the benefits of redesigning processes along Lean theory but this does
not mean that functional organisation is worthless. In fact there are reasons to believe that
functional orientation offers some advantages over lean, particularly when combined with effective
information systems. In some ways it can be argued that a lean approach will inhibit the
development of new process designs rather than support this; a somewhat counter-intuitive
argument.
Many authors have criticised traditional business organisations that rely on a functional approach for
being slow and unresponsive and unable to compete effectively with emerging firms. As firms grow
they have to develop formal organisation structures with which to subdivide management tasks into
manageable units. Continuing growth tends to lead to increasing numbers of managers that then
need to be subdivided into another level of manageable units and a management hierarchy
emerges. Smaller emerging firms on the other hand tend to have smaller hierarchies in which
communication is simplified and managers can see more clearly when and how to respond to
changing situations.

Process Alignment
Functional organisation is a response to the division of labour concept in which workers become
skilled in a small set of tasks rather than having a broad range of skills. The immediate managers of
these worker groups also need to be specialised in the same area as their subordinates; these
managers are often referred to as ‘line managers’. In large organisations, line managers are
organised into further functional groups and a functional management hierarchy is the result. In an
engineering business we commonly find departments for engineering, manufacturing, procurement,
sales and finance.
Company
Engineering Manufacturing Sales & Marketing
Design Engineering Test Component Manuf Assembly Marketing Sales
A simple organisation chart
Functional organisations worked well during the period of market expansion as firms grew and new
markets were found but are less able to compete effectively in today’s competitive environment.
When markets were growing power lay with the suppliers who could dictate the terms of provision.
Manufacturers could determine what products the markets would be given, when they could expect
to receive goods and, importantly, the price. Prices were set at a level that would almost guarantee a
profit and because the market was growing, customers could always be found. Today, power is with
the customer who is more demanding about what they want, when and where they want it, and are
very aware of what constitutes a good price. The older established companies in Western economies
have been particularly affected by this change and the ones that have failed to respond have gone
out of business or been taken over by more successful ones.
Increasing global competition since the 1980s has eroded profit margins for established companies,
forcing them to look for efficiency improvements if they are to survive and prosper. The emerging
economies of South Asia (at first South Korea, Taiwan and Malaysia; and more recently Thailand and
of course China) that entered the markets in the last 20 years, have changed the fundamental cost
structure of business and are providing customers and producers with an increasing range of
business opportunities. To compete against aggressive new entrants, established companies have
responded by questioning their existing organisational structures, processes and costs. Much of has
been achieved by reengineering their processes but much more needs to be achieved in future.
Lean approaches that emerged from Japan in the 1980s have been adopted by many successful firms
in recent years and are having very beneficial effects on process performance. At first these were
limited to the automotive sector but have been adopted with success in the aerospace sector and in

Process Alignment
commercial and healthcare settings too. They rely on the principle of only doing activities that the
end customer values and is willing to pay for; everything else is a waste that should be eliminated.
The value adding activities should be arranged in a smooth flowing process that cuts across
functional boundaries and is managed from end to end using simple control methods and visual
management techniques.
Visual management is the main area in which conflict arises with IT-based approaches such as ERP.
The use of simple controls such as kanban and visual indicators such as flags and whiteboards is
quite contrary to an IT-centric approach favoured by ERP implementers. However, Lean and ERP are
not mutually exclusive: they can and do co-exist but support different aspects of business.
Business Process Management
Business process management (BPM) is a management discipline that continues the trend towards
process-centric thinking, with the desire to reduce reliance on traditional territorial and functional
structures. BPM has evolved from past management theories and practices, such as total quality
management (TQM) and business process re-engineering (BPR). It requires and enables
organisations to manage process in a systematic and controlled manner - from process design to
monitoring and optimisation - and to change them more frequently to adjust to changing
circumstances. Such rapid change is impractical while processes are embedded in conventional
applications, in what technologists refer to as ‘hard-coded’ i.e. embodied within the program codes.
The development of BPM technologies helps business managers to abstract process flows and rules
in a model-based form and separates these from the underlying applications and infrastructure. This
makes it possible to change them more easily but change needs to be managed if chaos is to be
avoided. BPM is neither a technology nor an updated version of BPR. It is an IT-enabled management
discipline. It represents a fundamental change in how businesses manage and run their operational
processes.
The BPM Life Cycle source Gartner Inc.

Process Alignment
Gartner identify a life cycle in which new processes are identified, defined, modelled (using process
maps), these are then validated using simulation techniques because the complexity of many
business processes makes them difficult to assess by purely manual means, implemented (activated
at a planned time) and then used (executed). Processes are monitored and their performance
analysed in order to improve them. When significant changes are needed because the processes no
longer meet the business needs then the cycle is repeated.
In their review of BPM in 20066, Gartner – a leading market research company – predicted that BPM
would continue to expand and be adopted by leading companies. They identified that it will become
a key means of creating an agile business environment that will help firms respond to changing
business environments in the future.
4. Conclusion
Information systems have had a fundamental role in shaping and enabling business processes. They
are used to define processes at a logical level and these models can then be used to guide the
execution of processes. Information systems no longer lead business process development but must
work alongside process owners to ensure that the information process and the physical process are
aligned.
Business Process Modelling systems are increasingly used to help develop and manage business
processes, particularly when these are large and complex. BPMS are used to store models and make
them available for explanation, analysis and improvement.
ERP systems are large and complex information systems that span across a range of business
functions and will benefit from being integrated with BPMS. At present many ERP systems enact
processes that are hard-coded and therefore difficult and expensive to modify. However, ERP
vendors recognise this as a limitation and are seeking to abstract process logic away from code
making it easier to make changes to process: making this faster, cheaper and more reliable.
In later chapters we will consider how recent and new technologies support BPM and how these are
also enabling the development of business processes that span organisational boundaries and
integrate heterogeneous systems and applications.
References
1
How Process Enterprises Really Work, Hammer & Stanton, Harvard Business Review, Nov-Dec 1999 pp108-
118 .
2
Lean Thinking: How to..... , Womack J. and Jones D., 1996
3
Hammer, M. "Reeingineering Work: Don't Automate, Obliterate," Harvard Business Review (66 A),
July-August 1990, pp. 104-112.
4
Hammer, M., & Champy, J. (1993). Reengineering the corporation: A manifesto for business
revolution. New York: HarperBusiness.
5
Reengineering: Business Change of Mythic Proportions?, Davenport T., MIS Quarterly, June 1994
pp121-127.
6
Gartner's Position on Business Process Management., Hill, Sinur, Flint & Melenovsky, Gartner Inc.
2006 http://downloadsap5.googlepages.com/136533.pdf accessed 4th March 2010.

ERP Integration
Technical Infrastructure
davis_n
3/19/2010
This chapter reviews the development of technical infrastructures for enterprise computing from the
dominance of mainframes, to the primacy of client server architectures and to the rebirth of modern
mainframes in the internet era. This has spawned the introduction of Software as a Service (SaaS)
and the concept of Cloud computing that is offered here as one possible way that technical
infrastructures may evolve in the future.
Contents
1. Introduction .................................................................................................................................... 2
2. Mainframes and Data Centres ........................................................................................................ 2
SAP R/2................................................................................................................................................ 3
3. The End of Mainframe Computing.................................................................................................. 3
4. Client-Server Computing................................................................................................................. 4
SAP R/3................................................................................................................................................ 4
The Influence of the Internet.............................................................................................................. 5
5. The Rebirth of Mainframe Computing............................................................................................ 7
Software as a Service .......................................................................................................................... 7
6. Cloud Computing ............................................................................................................................ 8
7. Conclusion....................................................................................................................................... 9
References ........................................................................................................................................10

1. Introduction
All information systems rely on the existence of a technical infrastructure to store, exchange and
process information, to distribute it to users and receive their input. The technical infrastructure
includes the hardware devices that store and process information, provide the means for
distribution this information as electrical, optical or radio transmissions i.e. networks and the devices
that users use to interact with the system. It also includes the software environment for executing
the applications, routing information over networks and that make it possible for user devices to
‘understand’ how to engage in the system functions. In this chapter we focus on the hardware
infrastructure used in supporting the OLTP requirements of ERP systems.
2. Mainframes and Data Centres

In the earliest implementations of ERP solutions, as an extension to existing MRP solutions,
hardware infrastructure was based on mainframe computers. At the time, in the late 1970s and
early 1980s, modern PCs hadn’t been invented; desktop computing was rare, office-type applications
didn’t exist and technical users of CAD systems used very expensive workstations. The mainframe
computer was the only computing device with the computational capacity to support transaction
processing. Without wishing to complicate this mainframes are ..
“powerful computers used mainly by large organizations for critical applications, typically bulk data
processing such as census, industry and consumer statistics, enterprise resource planning, and
financial transaction processing.”
Wikipedia.
This definition is interesting because it identifies both ERP, mission criticality and transaction
processing as characteristics of mainframe computing.
Mainframes are designed to handle very high volume input and output (I/O) and emphasize
throughput computing. Since the mid-1960s, mainframe designs have included several subsidiary
computers that manage the I/O devices, leaving the CPU free to deal only with high-speed data
processing.
Mainframes were concentrated in purpose built data centres because they were large and produced
a lot of heat. They needed a dedicated staff of operators to load and unload application programmes
using tape drives. It is common in mainframe data centres to deal with massive databases and files.
Giga-record or tera-record files are not unusual. A terabyte (or Tbyte) is equal to 10 12 bytes or 1000
gigabytes. The unit symbol for the terabyte is TB. Compared to a typical PC, mainframes commonly
have hundreds to thousands of times as much data storage online, and can access it much faster.
The acquisition costs of mainframe computers were very high and combined with the need for data-
centres and dedicated staff was seen as an expensive burden. Businesses were keen to find cheaper
alternatives and these began to arrive during the 1980s and early 1990s with the emergence of
increasingly powerful personal computers and easy to use graphical environments like Windows.

SAP R/2
SAP’s first ERP solution of major note was called R/2 and was mainframe based. All processing was
carried out on the mainframe and user interaction was made through dedicated text terminals
connected to the mainframe using point-to-point wiring (similar to conventional land-line
telephones). Every attached device was connected individually to an input/output port at the data
centre.
3. The End of Mainframe Computing

The introduction of relatively cheap personal computers seemed to signal the end for many of the
applications that had been served from mainframe computers. Increasing numbers of business users
(clients) started to demand more power and flexibility on their desktops. This was difficult to provide
using mainframe infrastructure which couldn’t support some of the emerging applications that
needed more processing power at the client end. The Visicalc ‘Killer App’1 changed the way business
users regarded computers.
Competitive pressures were increasingly directing executives to think about cost and the IT
department was often the focal point of this. It was seen as an expensive overhead that while
necessary perhaps had become bloated and inefficient. Compared with what PCs seemed to offer
the mainframe was a dinosaur: large, old and cumbersome.
Mainframes are dinosaurs
Unlike dinosaurs, in fact, mainframe computing didn’t die. There were still many organisations,
particularly in the finance sector, with critical legacy systems that couldn’t easily switch to the new
paradigm of client-server computing. These organisations continued to use mainframes and, with
reductions in the physical characteristics of these devices and their storage sub-systems, could
reduce the costs of ownership considerably.
1
Killer applications are applications that change the way people work with computers. The first of these was
the Visicalc spreadsheet, email was the next, we might argue that Google has followed.

4. Client-Server Computing
Client-server computing emerged in the 1990s as a consequence of a number of factors and
advantages over mainframe computing:
 Computer networks became a cost-effective solution to transmit data. Instead of point-to-

point wiring from a central ‘host’ to terminals, hosts could be connected in a variety of
configurations, not just hierarchically.
 Cheaper alternatives to mainframes could handle higher throughput of data. These were
referred to as Servers. Some could serve data, some could serve email and with the
emergence of the web, some could serve web pages.
 PC’s could function as client devices connected on the network with enough processing
power and memory to perform some if not all of the application processing requirements.
These were more flexible than mainframe/terminal paradigm because they could stand-
alone or be connected as part of a business information system.
The predominant configuration of a client-server solution is the three-tier client server architecture
as shown below.
3 tier Client-Server Architecture
The three tiers handle 4 tasks between them. In 3-tier architecture the client manages display and
presentation; the application server manages the application logic and databases store and manage
the data. When first applied, each client had a local installation of software to manage the
presentation and display and to perform some of the manipulation of data (performing calculations,
for example); this was known as a ‘thick’ client.
SAP R/3
SAP R/3 was the first enterprise level application for business to support a 3-tier client-server
architecture. This revolutionised the ERP industry and led to SAP gaining its market leading position.
The client-server concept, uniform appearance of graphical interfaces, consistent use of relational

databases, and the ability to run on computers from different vendors have been cited by SAP as
major reasons for this.1
In ERP terms, the client server approach provides robustness through having the opportunity to run
multiple servers at data and application levels, makes it possible to balance the load on the system
more evenly and share resources across wide areas (particularly as network bandwidth has
increased).
In a typical SAP implementation, separate database, application, message and gateway servers are
used and can be distributed over a number of instances. Separate instances can be used to allow
development and testing work to be done without risking the ‘operative’ live system.
The Influence of the Internet

All installed software needs support and has to be maintained and upgraded when new versions of
applications are released; this costs money and caused a gradual re-assignment of the client-end
processing. IT managers began to realise that thick clients required a lot of support and their TCO
was significantly higher than expected; acquisition cost was low but life-time costs were high. Over
time, more and more clients became ‘thinner’ as less and less was required of them in order to
reduce TCO. Nevertheless, the cost of supporting clients, thick and thin, remains significant.
4 tier architectures have also emerged recently where the clients are very ‘thin’ and do no more
than display the output and capture user input; this is an attempt to reduce the cost of managing
clients and also giving the users more freedom in their choice of device. This is has become much
simpler as web-technologies have evolved and standards have emerged for messaging and rendering
output.
In the last 5 years SAP have gradually introduced client solutions that use simple web-browser
interfaces served from the SAP Web Application Server. The basis of SAP now includes a web-based
protocol for messaging between parts of the system using Java and web browsers as well as more
traditional client server techniques and the SAP GUI (the client tool that you are using during this
course).

The components and their tasks are described below:
 The Internet Communication Manager (ICM) sets up the connection to the Internet. It can
process both server and client Web requests. It supports the protocols HTTP, HTTPS, and
SMTP. The SAP Web AS can behave as a Web server or as a Web client
 The dispatcher distributes the requests to the work processes. If all the processes are
occupied the requests are stored in the dispatcher queue.
 The ABAP Work Process executes the ABAP code.

 The SAP Gateway makes the RFC interface between the SAP instances available (within an
SAP System and beyond system boundaries). For information on the architecture see
Architecture of the SAP Gateway.
 The message server exchanges messages and balances the load in the SAP System.
 In the Java component of the SAP Web AS there are the components Java Dispatcher, Server
Process and Software Deployment Manager.
5. The Rebirth of Mainframe Computing

As stated previously mainframe computing didn’t die with the advent of client-server computing and
is now making a come-back.
Technical advances have made mainframe computers much cheaper to acquire and operate and at
the same time people have recognised that the TCO of client-server solutions can be much higher
than initially suggested. Xephon Inc., an IT survey company identified that average TOC per user over
5 years (most clients are replaced within this period) for a modern mainframe solution was $6250
compared with $19,000 for a client-server solution and IT personnel costs were 21% compared with
68% respectively.
The ubiquity of the internet now removes the need to have dedicated communication channels
between mainframe and user and combined with increasing bandwidth makes it possible to carry
out all of the data processing on the mainframe. In effect, mainframes have become servers that
manage data and applications. All the user needs is a web browser and this could be on a thin client,
thick client, a netbook or even a smartphone.
Software as a Service
The rebirth of mainframe computing, as well as increased capacity of servers in general, and the
move to browser based ultra-thin clients, has also opened up the provision of on-demand services or
Software as a Service (SaaS, pronounced “Sass”). This model of application deployment does not
require users to invest in any software or install any software. The costs that any client business has
to pay to realise SaaS are limited to hosting fees for storing and managing their data and rental fees
each time they use a service. These can either be paid for on an as-you-go basis or under a contract
based on a fixed level of use in a time period, just like the way we pay for mobile phone use.
Saas is particularly attractive to small and medium sized businesses who in the past have found
enterprise systems too costly to acquire and operate. Providers of SaaS can exploit their expertise in
installing and maintaining complex applications, performing back-ups and supervising security while
users can concentrate on operations and the execution of their business processes. SaaS also makes
it easier for users to upgrade their service, adding new features as they need them rather than
having to anticipate requirements that they may not need or be unable to support.
The provision of SaaS alone is not sufficient, for SMEs in particular: access to software does not
guarantee success. Users need to know how and when to use the services, but SMEs still lag behind
larger organisations in their knowledge and ability to absorb even the end-use of sophisticated ERP
solutions.

ERP providers like SAP have been supporting and continue to support both traditional and newer
web-based channels to serve their solutions to their customers but have their eyes firmly fixed on
the future of both Saas and Cloud computing.
The service concept is being extended to include more than applications (where SaaS fits) to include
business process integration as a service, platform as a service and infrastructure as a service 2.
Business process services enable much wider inter-organisational collaboration and access to
business process solutions for individual business problems; rather than adopt a pre-configured
process or have to develop one, they can be accessed as required. Platform as a service provides the
programming environment that is optimised for the cloud computing environments and
infrastructure as a service provides access to storage, network and processing resources as they are
needed with no regard for the user as to who provides them and where from.
The Service Stack
6. Cloud Computing
Many technologies and infrastructural changes having been combined in the realisation of the
concept of cloud computing, the basic principle of which is very simple. The internet and devices on
it are the cloud. The cloud is intangible in many ways, we cannot see it and we cannot touch it,
devices are constantly being added and removed. Services that are provided on some devices can

change and user devices can move around. What we do with the cloud changes from moment to
moment, reading books, executing business transactions, listening to music, booking holidays etc.
There is not a single cloud but many virtual clouds within it. If the cloud is roughly equivalent to the
internet then these virtual clouds are like intranets and virtual private networks. They can be private
clouds (like Facebook), sector clouds, business/project clouds and many more.
Cloud computing is hard to envision
Cloud computing is in its infancy and there are many issues that need to be resolved before it can
become reality in the business world:
 Security & trust: where is my data and who is looking after it?
 Pricing: what is the economic cost of a service?
 Payment: how is usage monitored so that payments can be calculated and billed?
 Service levels: How is this guaranteed and who is penalised when a service fails?
Despite these issues, cloud computing provides the opportunity to acquire information system
capabilities without the need to carry them as overheads. The majority of cost can in principle be
allocated directly to the level of specific business activities. Access to new capabilities is not
constrained by historical investment decisions.
7. Conclusion
Changes in infrastructure happen regularly and can be exploited for business benefits.
In the past this was mostly done to achieve cost savings
In the future, changes in technical infrastructures may fundamentally alter the economics of
information systems and the way they are used.
Information systems professionals need to keep aware of these changes but must not forget that
technical change is only useful if users can absorb it quickly enough.

References
1
SAP Website http://www.sap.com/about/company/history/index.epx accessed 19/3/2010
2
International Research Forum, Woods et al, Evolved Press, 2008 http://www.sdn.sap.com/irj/scn/articles-
saas-all accessed 19/03/2010.
Google like crazy

ERP Integration
Process Integration
davis_n
2/17/2010
This chapter considers the opportunities afforded by emerging information technologies to support
better integration between business processes and enable the development of next generation
processes. These capabilities provide the means to develop innovative processes that can change
the competitive environment of a firm and add value. It highlights the concept of Enterprise
Application Integration (EAI) and the supporting technologies that enable this. In particular in gives
an overview of the Service Oriented Architecture (SOA), SOAP messaging and Web Services.
Contents
1. Introduction .................................................................................................................................... 2
Process Innovation.............................................................................................................................. 2
2. Enterprise Application Integration.................................................................................................. 4
Mediation............................................................................................................................................ 5
Federation........................................................................................................................................... 5
Orchestration ...................................................................................................................................... 6
3. Supporting Technologies................................................................................................................. 6
Service Oriented Architecture (SOA) .................................................................................................. 6
SOAP.................................................................................................................................................... 8
Web Services & WSDL......................................................................................................................... 9
4. Conclusion....................................................................................................................................... 9

Process Integration
1. Introduction
ERP solutions provide a means of supporting business activities by managing their information needs
more effectively than paper-methods can but the business environment is not static so processes
need to adapt. If processes need to adapt then so do the information systems that support them.
Unfortunately, existing software architectures do not help to achieve this. For SAP users this has
been a particular problem that has been acknowledged by many authors, even those close to the
company.
Fortunately a number of technical advances, conceptual models and actions on the part of the ERP
vendors to open up their systems have helped to reduce this problem. The challenge is to convert
these capabilities into process innovations in the real world.
Process Innovation
One way of achieving a competitive advantage in the market is to improve the ease with which
customers can access your product and services and Information systems often play a significant role
in achieving this. Innovation can be delivered in the product itself (through having a higher
performance or added features) or it can be the result of better collaboration between those who
specify and design the product and also through improved processes that allow customers to find
and acquire what they want more easily.
Amazon and Dell Computers are arguably the best known and earliest companies to successfully
apply information technology as a means of innovation in process. In both cases the products these
companies sell are neither technically superior nor cheaper than comparable products and services
but they make it easier to acquire them. Each company has developed a process that customers find
convenient to operate, that offers them a level of service that was previously unavailable in the mass
market and that they value i.e. they are prepared to pay for.
Managing the information associated with innovation helps enhance business benefit. The
development of a new product can also be speeded up by improving collaboration between
designers, engineers and marketers. Better processes that streamline information and material flow
can realise significant cost and time savings, so there is a link between product design, business
collaboration and process innovation. Information systems are increasingly recognised as major
infrastructural means of supporting the interactions between these innovation channels. As shown
in the following diagram.

Process Integration
Innovation through
collaboration
Innovation through
design
Innovation through
process
Although many system implementers decide to use the built-in best practice processes delivered
with enterprise systems, others question whether this is an entirely good idea. The reason for this is
a concern that it removes differences between the way that firms operate. In the case where
everyone uses the same process where is competitive advantage for anyone?
Kirchmer and Scheer 1, 2 argue that what matters is the ability to develop and integrate what they
refer to as ‘Next Practices’. These are new ways of performing processes, organising resources and
engaging with stakeholders (customers, suppliers or colleagues).
Scheer argue that traditional BP integration as practised within SAP ERP can only specify variants of
pre-defined best practise processes; the so-called ‘reference models’. This is done by customising
the database tables to adapt the logic – the table contents themselves are fixed. IDS argue that in
order to truly innovate the only solution (if using this architecture) is through low-level software
development. This significantly increases the total ownership costs as previously described1.
With conventional approaches, the development of next processes requires program level software
developments that either modify or add to the existing modules within SAP. This can only be done
by dedicated software engineering teams, with formal requirements engineering and project
management. The cost of doing this is high and the time taken to develop and test the code is long.
1
Refer session on implementation approaches (vanilla etc.) and cf to Customisation session.

Process Integration
Very few such projects are likely to get sanctioned and most often they will focus on resolving
existing performance issues rather than developing new capabilities.
IDS propose a solution that requires the separation of applications, integration and process design as
shown in the following figure. Their proposed solution is based on the concepts of Enterprise
Application Integration (EAI) that have existed for some time along with other technologies that
have emerged in recent years, particularly associated with the internet.
2. Enterprise Application Integration

As the name suggests, EAI aims to support better integration between applications involved in
enterprise systems. This integration is focussed at the data level and allows applications to share
data and process definitions more easily. When combined with workflow technologies EAI provides
the foundation for the generation of information systems support for next generation processes.
EAI is designed to provide the means to share information in heterogenous environments. In the
following diagram data from a set of modules is provided via an EAI layer to a set of steps within a
business process. The business process definition layer does not need to know how to access the
data it needs directly. It only needs to specify what information is required and EAI manages the
exchange. Likewise, the individual application software modules with their underlying data sources
(not shown) do not need to know how the data and function they provide will be used at the process
level.
The encapsulation of application information is what makes it possible to link together applications
from different vendors, not just applications from a single vendor. This is shown in the next figure in
which third party applications can be an equal partner in enabling a process. Furthermore, the
application services and data can be distributed anywhere on the internet, in principle. Scheer refer

Process Integration
to solutions formed in this way as composite applications that can be packaged together and
provided to customers as part of a salebale product or, as we have seen, on a pay as you go basis via
cloud computing or SaaS.
To be effective EAI has to operate in a heterogenous environment with a mix of source systems that
have different operating systems, databases and programming languages. It is not economic or
viable to implement EAI by writing point to point queries. Instead it requires the development of
neutral and standardised mechanisms. These have been implemented in two ways:
Mediation
Here, the EAI system acts as the go-between or broker between multiple applications. Whenever an
interesting event occurs (e. g., new information created, new transaction completed, etc.) an
integration module in the EAI system is notified. The module then propagates the changes to other
relevant applications.
Federation
In this case, the EAI system acts as the overarching broker across multiple applications. All from the
'outside world' to any of the applications are mediated by the EAI system. The EAI system is
configured to expose only the relevant information and interfaces of the underlying applications to
the outside world, and performs all interactions with the underlying applications on behalf of the
requester.
When used for process integration, the EAI system can also provide transactional consistency across
applications by executing all integration operations across all applications in a single distributed
transaction (using two-phase commit protocols COMMIT and ROLLBACK).

Process Integration
Orchestration
Business process definitions in the form of process models specify the goal of a workflow engine.
The workflow engine monitors the status of tasks in a workflow and applies defined rules to
determine which tasks to perform. Orchestration works with a workflow engine to manage the
initiation of services and to monitor the execution of tasks to make sure they proceed in a timely
fashion and to reveal abnormal conditions within the overall process. An orchestration performs a
similar role to that of a conductor of an orchestra which is how it got its name. All members of the
orchestra have tasks to perform and must perform them at certain times. The conductor has a
master copy of the music – the process definition - and directs and co-ordinates the orchestra
members by beating time with a baton and pointing at them.
3. Supporting Technologies
To support the concept of EAI and enable the automation of business processes a number of
technologies have been either exploited or developed.
Service Oriented Architecture (SOA)

Enterprise information systems vendors as well as vendors of systems in other disciplines have been
moving towards the service concept of software for many years as a means of improving the re-
usability of code and of creating composite applications without having to care about the internal
implementation of these code units.
In SOA a service is a loosely coupled functional unit of code. The unit of code will perform a function
of some complexity. It may be a simple function that computes some result or performs a database
query, or it could invoke a complex process that calls on further services. Loose coupling suggest that
the code isn’t tightly integrated within a containing system; its looseness is what makes it available.

Process Integration
Tightly coupled code used to be necessary to ensure software was protected from accidental
corruption or misuse but object-oriented code makes this easier to accomplish.
Services communicate with each other via messages; they do not directly access each others’
properties or execute functions directly. In order to do this, messages have to be formatted in
standard ways. To access the right services, applications need to know what the purpose of a service
is and how the content of messages (both sent and received) should be presented. This can be
achieved using a broker that finds services, records their characteristics and can put service
consumers in contact with service providers.
Companies like SAP use the SOA model internally; they don’t need to find services because within
their development organisation they know what services are available and how they should be
formatted. This is achieved through the use of a Reference Model that describes information
objects, functions and events.
Conceptual model of a SOA using UML
Within an enterprise environment, SOA exists at a number of levels. In the following diagram
authored by IBM, pre-packaged ERP modules and business processes exist at the Operational level,
more loosely couple SOA components exist at the Enterprise components level and expose their
service descriptions at the Services level. These can be invoked by business process definitions at the
Choreography level. The Presentation level exposes business process and underlying services to the
outside world (the web).

Process Integration
SOAP
The simple object access protocol (SOAP) provides a standard way of describing the content of
messages used in SOA and Web Services. Applications communicate with services using messages
that contain SOAP envelopes. Each envelope contains a header that specifies the encoding of the
message i.e. how it is transmitted over the network, and a body that contains the content. In the
following example the body contains two objects; the first is called GetStockPrice and this contains
the object StockName with the value IBM.
<?xml version="1.0"?>
<soap:Envelope
xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
<soap:Body xmlns:m="http://www.example.org/stock">
<m:GetStockPrice>
<m:StockName>IBM</m:StockName>
</m:GetStockPrice>
</soap:Body>
</soap:Envelope>

Process Integration
This message only makes sense in the context of an application that can look-up stock prices. This
can only be found by interrogating the available service descriptions, a process known as service
discovery.
Web Services & WSDL

In the previous discussion about SOA no precondition was made about the location of a service: it
could be a component within a packaged solution such as SAP ERP, it could be a stand-alone
function in a programming library on a server or it could be somewhere on a server on the web.
Web Services are the specific case of a service that is made available on a web server. Subject to
required access and authentication tests any application could send a message to a web service and,
assuming the message made sense to the web service, could expect a response with some expected
value or effect.
The W3C defines a "web service" as "a software system designed to support interoperable machine-
to-machine interaction over a network”. It has an interface described in a machine-processable
format (specifically Web Services Description Language WSDL). Other systems interact with the web
service in a manner prescribed by its description using SOAP messages.
Web Services Description Language (WSDL pronounced “Wizdle”) is the web services equivalent to
the service description for general SOA. It is used to identify what a web service can do, how it
expects any input to be formatted (using SOAP) and how the reply is formatted (again in SOAP).
Broker services can be used to for service discovery, either by the programmer explicitly searching
for a service and hard coding the messages into their application or implicitly when the service used
is only identified at run time. This later requirement is necessary for the implementation of cloud
computing because we cannot know what services will be available in advance.
4. Conclusion
The opportunities for supporting adaptable business processes that integrate enterprise applications
are substantial and growing. The ERP vendors have been forced by their own internal need to
improve their application capability in this area. They also recognise that the business community,
whilst still accepting the benefits of integrated enterprise information systems, does not want to be
prevented from taking opportunities to develop more effective business processes by working with
any information system or individual application provider.
Cloud computing is also emerging and stimulating information technology companies to open up
their applications so that they can compete in the future. No company can afford to be saddled with
an application architecture that forces its customers to remain static in a dynamically changing
business world. This is especially so for companies that must compete on their agility and on their
exploitation of knowledge assets.

Process Integration
References
1
Business Process Automation: ARIS in practice, Scheer A-W. et al. Springer, 2004
2
Business Process Automation – Combining best and Next Practices, Kirchmer M., Scheer A-W. in 1 above.

ERP Integration
SAP NetWeaver
davis_n
3/1/2010
This chapter describes SAP NetWeaver, the integration framework that is the technical foundation of
SAP’s Business Suite (including SAP ERP). It explains the role of SAP NetWeaver, its conceptual model
and some of the associated tools and techniques. It explains how SAP NetWeaver supports SAP ERP
solution and how it provides integration with 3rd party applications. Finally it describes the
conceptual relationship with Composition Environment.
Contents
1. Introduction .................................................................................................................................... 2
2. Goals ............................................................................................................................................... 2
3. SAP ERP and SAP NetWeaver.......................................................................................................... 3
4. Business Benefits ............................................................................................................................ 4
5. SAP NetWeaver............................................................................................................................... 6
People Integration .............................................................................................................................. 7
Business Integration............................................................................................................................ 7
Process Integration ............................................................................................................................. 7
Application Integration ....................................................................................................................... 8
6. Composite Applications .................................................................................................................. 9
7. Conclusion.....................................................................................................................................10
References ........................................................................................................................................11
Author: N Davis ©University of Warwick (WMG) 2010 Page 1 of 1

SAP NetWeaver
1. Introduction
SAP NetWeaver provides the technical foundation of recent generations of SAP Business Solutions
including SAP ERP. It was created in response to various changes in the business and technical
environments of the early 21st Century. These included the increased demand from customers for
more integration between their enterprise systems and the development of computing concepts
that had the potential to radically alter the way information systems were constructed in the
internet era.
SAP likes to think that it already had a head-start in finding a way to address these issues. It s existing
infrastructure was founded on abstraction principles and this just needed to be updated. It also had
to manage a customer transition period of many years and a vast investment in existing code that
meant it could not simply start again from scratch. Abstraction involves separating out what needs
to be done from the way in which it is implemented in detail. SAP R/3 had been so successful partly
because it used abstraction to insulate its internal operation from the databases and hardware that
customers used, it meant that SAP R/3 could work on pretty-much anyone’s hardware. The key
foundations for this were SAP Basis and ABAP its programming language.
At the end of the 20th Century SAP needed to control is costs following a period of massive
expansion and going into a period of uncertainty and more competition. Enterprise systems are very
complex and it is difficult to predict how customers will use them until they are being operated.
Every customer has slightly different goals and ways of achieving these but also comes up with new
requirements that are not known prior to operation. SAP needed a more efficient and effective
means of providing customers with what they needed at a price and delivery they could afford whilst
still maintaining their profit margin. The result was SAP NetWeaver.
2. Goals
SAP NetWeaver was developed with the following goals in mind1:
 Enable Change
 Increase Usability
 Enhance Integration
 Enable Innovation
 Save Money
SAP NetWeaver was designed to provide an environment that makes it easier for businesses to
adapt their processes and still be able to support them with relevant information systems. In some
ways this goal addresses the criticism of Vanilla implementations: that they make one size fit all. The
test of SAP NetWeaver’s success in meeting this goal will depend on seeing how much businesses
feel comfortable in doing this for themselves without having to hire expensive consultants.
The complexity of enterprise systems and previous interface design often made users nervous about
using all of a system’s features. SAP NetWeaver was designed to support more convenient interface

SAP NetWeaver
design and methods. The goal of this is to increase adoption and exploit information better to yield
more cost savings.
Businesses need to work with each other but it was difficult to get existing systems to communicate
with each other. Point-to-point integrations could not be built fast enough nor maintained well-
enough to support expanding demands. SAP NetWeaver is designed to make inter-system and inter-
application integration easier, cheaper and more robust.
In the internet era some companies have seen phenomenal growth through innovation; this
provides one source of competitive advantage over low-cost competition but sometimes existing
approaches to information systems have not been able to support this. SAP NetWeaver provides the
means to assemble new applications from existing and new components to create composite
applications.
SAP NetWeaver seeks to achieve all of the above goals and at the same time reduce total ownership
costs. It wants this for its customers but it also needs this itself.
3. SAP ERP and SAP NetWeaver

SAP ERP is only part of the overall portfolio of SAP’s Business Suite, albeit a fairly central part as
shown in the figure below. These business solutions: Product Lifecycle Management (PLM),
Customer Relationship Management (CRM), Supply Chain Management (SCM) and Supplier
Relationship Management (SRM) and Enterprise Resource Planning (ERP), where all founded on SAP
Basis and ABAP in the past.
In the future these products will all be founded on SAP NetWeaver and will gradually be translated
to use SAP NetWeaver technologies as new versions are released (this process has already been
going on for almost 10 years).
Individually these solutions are all examples of pre-packaged integrations. These integrations
provide the best-practice processes that SAP have gradually incorporated into at first SAP R/3 and
more recently SAP ECC (ERP Central Components). Their various parts are designed to move related
information from different functional areas in a seamless way to support business processes.

SAP NetWeaver
However, SAP NetWeaver seeks to support integration between these and other applications, both
within SAP’s portfolio and with external 3rd party vendors.
The evolution of SAP Basis technology to SAP NetWeaver has also seen a refinement of the
traditional 3-tier client-server model to include a more complex but ultimately more powerful model
of integration.
The stack of applications

application within an enterprise solution
There are many organisations and products involved in solving integration problems in business as
shown in the following table:
Portal software many

Business Process Management Systems IDS Scheer, Appian,
Enterprise Application Integration Consulting firms & system integrators, Bea...
Data warehouses Oracle, Teradata ...
Development tools Eclipse, Visual Studio ...
Application servers IBM Websphere, SAP Web AS
Databases Oracle, SQL Server, DB2, MySQL
Operating Systems Unix/Linux, Windows, z, MVS,
4. Business Benefits
Although the goals of SAP NetWeaver clearly identify general benefits some specific benefits are
already being attained in the business world and many more are being exploited than can be shown
here.
If businesses are to get the most from their enterprise system investments then it is important that
users find them convenient and effective in meeting their individual needs. One of SAP NetWeavers
main benefits is in it’s support for portal building. Portals are aggregators that bring together
information fromm various sources into a single place avoiding the need to open and close different
programs and to write down information before moving on. Portals can also be dis dis-aggregators,
allowing users to drill down into detail from within a portal.

SAP NetWeaver
SAP NetWeaver helps businesses manage their data by consolidating it from multiple applications
and providing tools to manage master data, prevent its duplication and ensure its consistency and
meaning across a variety of contexts (applications and processes).
SAP NetWeaver supports transaction processing between systems and applications with capabilities
to help manage orchestration and provide users with a single interface irrespective of their location,
function or affiliation. This makes business processes transparent to the user and breaks down
barriers within and between organisations.
SAP NetWeaver reduces the TCO of information systems in situations where processes are changing
and when firms need to exchange information at a transaction level through reducing workload and
lowering costs as shown in the following diagram.
Process
Integration ability automation
Lower
workload
Enhanced
Pre-configured productivity
integration
TCO
Specific Lower Reduction
adaptability hardware costs
Lower
Integration hubs development Lower costs
costs
Use standard Lower

technologies maintenance
costs
Ultimately, SAP promoting the concept of Enterprise Services Architecture (ESA) which corresponds
with the thinking of Scheer on how next generation business processes should be enabled by
information systems. Process management and information management are related but separate
functions; in the past they were managed together which sounds like a good thing but was made
difficult by the constraints of the pre-existing foundations. SAP NetWeaver has re-engineered these
and replaced them with a more open and flexible integration that is split across multiple levels of
abstraction (the stack referred to earlier).

SAP NetWeaver
Role specific user

step1 step2 step3
interface
A B C D E
F1 F3 F5 F7 F9
F2 F4 F6 F8 F10
SAP Enterprise Services Architecture
5. SAP NetWeaver
Because it supports different needs, SAP NetWeaver means different things to different people. For
some people it provides business solutions, for others it simplifies system maintenance and for some
it is a programming tool.
SAP NetWeaver provides integration in four areas: people, information, process and applications as
shown in the following diagram (informally known as The Fridge by some).
The Fridge

SAP NetWeaver
People Integration
SAP NetWeaver provides portal building capabilities that bring information and processes to the
people that need them. SAP Enterprise Portal does more than specify page layout; it provides
dynamic access to underlying information that can span many applications on the basis of the role
that a user has logged in with.
SAP NetWeaver provides an abstraction layer for mobile devices that allows them to access
applications within SAP’s environment but does not force integrators to worry about how this is
achieved. For each device SAP work with the manufacturers to develop the necessary
communications and command conversions to make this work.
SAP NetWeaver supports collaboration with built in support for email, workflow and other
technologies.
Business Integration
SAP NetWeaver provides an integration framework for making connections, specifying reports and
analytics with business data warehouses and their Business Intelligence functions. These can be
managed and presented via process logic and user interface tools either in a portal (using People
Integration components of SAP NetWeaver) or using traditional SAP GUI integrations using ABAP and
WebDynpro.
Master Data Management is a critical component of a fully integrated business and SAP NetWeaver
supports this with tools for consolidating master data from different sources and ensuring this is
harmonised. More sophisticated businesses can go further with central master data management
and tools to map centrally controlled master data objects from and to a variety of applications.
Process Integration
SAP NetWeaver supports a range of tools to integrate the processes that are central to the operation
of any business enterprise. Central to the achievement of this are tools and services to manage the
exchange of information using standard messaging techniques. This is achieved using brokers to
capture service descriptions and discover new services when needed.
Process integration provides the means that enable other SAP NetWeaver components to talk to
each other. When a business intelligence process needs to present information via a portal it uses
process integration capabilities to do this.
Process integration tools can be used to link SAP ERP to other Business Suite applications as part of
a process orchestration. There may be many points within many processes that would benefit from a
closer integration and SAP NetWeaver makes this much simpler to achieve with far less need to
develop special software. SAP NetWeaver tools at within its application integration component are
used to do this, often using process modelling tools for much of the work, leaving only a small
amount of bespoke programming to be done.

SAP NetWeaver
Application Integration
SAP applications execute on the Web Application Service (SAP Web AS) and SAP NetWeaver provides
solutions in three areas in which develop new code, integrate existing code from SAP applications
and also integrate with external applications.
 J2EE is the Java Enterprise software development kit. This has become the de-facto
programming environment for web-based applications. However, SAP NetWeaver also
provides external integrations to tools like Microsoft’s .Net platform
 ABAP is the original programming abstraction that was used to build SAP Basis and allowed
these to execute on any hardware platform.
 SAP’s database abstraction, like ABAP provides the means by which SAP can operate on any
hardware platform. It uses SAP Open SQL internally and this is then mapped onto the target
DBMS (database management system).

SAP NetWeaver
6. Composite Applications
A composite application is
“..an application that uses service calls to acquire existing data and functions from various solutions
in the system landscape, and combines these to create new, primarily collaborative business
processes, which are supplemented by their own user interfaces and business logic.”2
Custom applications are built by combining existing applications to create new capabilities without
having to develop and test too much custom code. This approach is cheaper and yields new
applications in shorter time than what was possible with older architectures and development tools.
Custom applications are needed to add capabilities in specific areas to: exploit new business
opportunities, develop next generation processes and reduce the costs of operating stable existing
processes. For example, supporting a new business relationship with an external partner, creating a
processes that crosses previously un-connected functions and automating an existing process. Other
reasons include to: provide better decision support, close-up information gaps and prevent errors.

SAP NetWeaver
Composite applications have a well defined

defined structure that links the front end process steps that
users execute via interfaces that support the presentation of information and accept inputs to
advance the status of business objects (orders, stock movements, schedules) that then employ the
services provided by the pre-existing
existing applications that are being combined (such as SAP ERP). This is
shown in the following diagram.
7. Conclusion
SAP NetWeaver is the result of many years of experience in building and operating enterprise
solutions. Using a combination
ination of SAP abstractions and recently developed standards technologies
that are used throughout the web-application
web application community, it provides the technical foundation for
SAP’s Business Suite of solutions for large enterprises.
SAP NetWeaver provides the foundations

oundations for business to leverage their existing ERP investments and
develop next processes that will help them compete more effectively in the future.
For companies that need to collaborate on medium to long term basis SAP NetWeaver provides the
means to o let them create effective integrated processes without having to throw away existing
investments or acquire new and additional solutions. It also makes it easier for mergers and
acquisitions to take place because legacy systems can continue to be used for
fo r longer.
The acid-test
test will be to see if the capabilities and opportunities that SAP NetWeaver provides are
taken up, particularly from within the enterprises that use them rather than only be used by external
consultants and system integrators.

SAP NetWeaver
References
1
SAP NetWeaver for Dummies, Woods D. & Word J., Wiley Publishing, 2004.
2
SAP NetWeaver Composition Environment, Rauscher J. Stiehl V. SAP Press, 2008.

ERPI Exercise
This exercise has 2 steps. Please complete step 1 before attempting step 2.
STEP 1.
Time allowed: 2 ½ hours
Develop a strategy mapi for a generic company within a business sector of your choice. The generic
company and sector should be one for which an ERP solution should provide a sensible and
appropriate investment.
Your map should identify the following:
 Up to 6 high level strategic goals to support shareholder value. [Row1]

 A set of attributes that should deliver value to your firm’s customers and allow it to compete
against its competitors. [Row 2]
 A set of strategic processes that support the customer value proposition. These should be
mapped according to the four internal process perspectives. At least three of these should
be associated with the Operations Management perspective. [Row 3]
Example IT Strategy Map
cont/d ....
ERPI Exercise
STEP 2
Time allowed: 1 hour
For the example you developed in STEP1:
Transfer the set of strategic processes that you mapped against the Internal Process Perspective in
STEP 1 [Row3] onto a blank Strategic Readiness Map for Information Capital (IC). The blank map
should not have any entries in the middle portion.
With specific focus on ERP functions and related technologies, identify and position individual
information systems components onto the map. These could be specific modules, brief function
descriptions, requirements or information objects. They identify the critical requirements of the IT
Portfolio.
Transferred from step1
optional
Identified and positioned by your group
in this step
You will be asked to present your maps after this exercise as a separate step. Please write them
neatly on two pieces of flipchart paper.
i
ERP Integration
Business Intelligence
davis_n
3/18/2010
This chapter builds on the previous material on OLAP. It introduces the role and operation of
business warehouses then reviews the types of analytical tools and outputs that can be used on this.
It briefly considers how the output can be presented giving the particular example of SAP’s SEM
Cockpit.
Contents
1. Introduction .................................................................................................................................... 2
2. Data Warehouse ............................................................................................................................. 3
Information Representation ............................................................................................................... 4
3. Analytics.......................................................................................................................................... 5
Reports................................................................................................................................................ 6
Slice-and-Dice and Drill Down............................................................................................................. 6
Ad Hoc Queries ................................................................................................................................... 7
Real-Time Analytics............................................................................................................................. 7
4. Presentation of Business Intelligence ............................................................................................. 7
The Cockpit in SAP SEM ...................................................................................................................... 8
5. Conclusion....................................................................................................................................... 9
Further Reading ................................................................................................................................10

1. Introduction
Information systems have often been used to support strategic decision making. At first this was
through the use of data processing applications that collected and aggregated data in paper reports,
then the use of relational databases to extract information about recent transactions and recently
through the use of data warehousing technique and what we call business intelligence. In the past
the terms Decision Support System (DSS) and Executive Information System (EIS) have been used to
describe the application of information systems to support corporate and strategic decision making.
Business Intelligence is rapidly taking over as a term of choice.
Business intelligence (BI) is a data-driven DSS that combines data gathering, data storage, and
knowledge management with analysis to provide input to the decision process. The term originated
in 1989; prior to that many of its characteristics were part of executive information systems.
Business intelligence emphasizes analysis of large volumes of data about the firm and its operations
and includes competitive intelligence (monitoring competitors) as a subset. Business Intelligence
uses a large database, typically stored in a data warehouse or data mart, as its source of information
and as the basis for sophisticated analysis. Analyses ranges from simple reporting to slice-and-dice,
drill down, answering ad hoc queries, real-time analysis, and forecasting. Perhaps the most useful
type of analytical tool is the dashboard. Recent developments in BI include business performance
measurement (BPM), business activity monitoring (BAM), and the expansion of BI from being a staff
tool to being used by people throughout the organization (BI for the masses). In the long-term, BI
techniques and findings will be imbedded into business processes.
A Business Intelligence system combines data gathering, data storage and knowledge management
with analysis to evaluate complex corporate and competitive information for presentation to
planners and decision maker, with the objective of improving the timeliness and the quality of the
input to the decision process.
Business Intelligence is the processing of data into information at first and then into knowledge. For
many years this was used to describe the purpose of information systems such as transaction
processing systems like ERP. BI goes further to say that the information is then transformed into
knowledge. But what is knowledge?
Knowledge is information that can be used for interpreting events and predicting future outcomes.
Information is data in context i.e. data with meaning. The number ‘7’ on its own is meaningless,
simply a piece of data, but if this is the result of a question “How many days until Easter?” it
becomes information. This information becomes useful if it is combined with other information and
some rules or relationship. If I also know that I eat one apple every day and I currently possess two
apples then I can know how many apples I will need to buy to keep me fed until Easter (5).
Knowledge is one of the most useful assets to a business. As Aristotle Onassis1 one said:
“The secret of business is to know something that nobody else knows.”
Business Intelligence comprises a number of technologies as shown in the next figure. These support
an information and knowledge management process that aims to get the right information and no
1
A famous shipping tycoon, one of the richest men in recent history, who built a global business by predicting
the need to ship oil in very large tankers.

more to the right person at the right time. Many managers are overwhelmed by the amount of data
that is pushed at them by subordinates and superiors alike, this often prevents them from making
any sense of the business environment. It is important not only to filter information but also to
ensure its validity because the wrong data will lead to poor predictions and bad decisions. It is also
important to provide a full picture and not have gaps in the information.
STEPS in a BI Process
1 Identify the business decision
2 Formulate business question (key values)
3 Specify the required information (filter)
4 Locate the information (search)
5 Retrieve the information (extract)
6 Analyse the information (dashboard)
7 Report
8 Take action
Components of BI
Business Intelligence is more than using predefined reports although this provides the majority of BI
information. Some users need to carry out ad-hoc analyses to expose underlying relationships and to
explore future opportunities.
2. Data Warehouse
Business Intelligence is performed on data that is held in data warehouses and data marts (as in Wal-
Mart: a supermarket).This data is not operative data, it isn’t the data that is created and stored in
the ‘live’ operational systems, but a copy of this data as shown below.

Few enterprises have or are likely to ever have a single source of original data. Information comes
from a wide variety of sources in a variety of formats. Much of this data will come from internal
sources and a firms ERP solution is likely to be a major source but departmental spreadsheets, non-
ERP databases, Engineering PLM systems and external sources are all potential providers.
The data in a Data Warehouse is less detailed than operative data, it cannot be updated and it isn’t
‘live’ – it is a snapshot taken at a particular time. In a live system we need to know many details
about individual orders for example; we need to know billing data, address data and much more. In
most cases this level of detail is not important for corporate decision making; we need to know how
many orders were placed in a period, what they were for and where they were sent but not much
more than that. The data flows into a warehouse where it is stored but it doesn’t return. The
warehouse has to do some housekeeping on the data to ensure its integrity and it may have to
convert it into a common format that can then be analysed in a consistent way.
Although the data in a data warehouse is in summary form it is a long term storage area that over
time grows in size. The figure below shows that the data warehouse (also known by some as a
business warehouse) is like the tip of a pyramid with progressively more refined summary data that
focusses the information and makes it manageable. However, unlike the operational systems that it
feeds from that only retain information for a limited period, the data warehouse retains information
for much longer becuase some analyses require long time-histories.
Data warehouses can be quite large. For large organizations, they can quickly grow to many
terabytes. Fortunately, not all the information in a data warehouse is used for BI. To speed response,
a small data warehouse, called a data mart, is created for use by analysts. The data mart contains a
subset of the data warehouse that contains most of the information used routinely for business
intelligence. If information beyond what is stored in the BI data mart is needed, analysts can query
the firm’s data warehouse.
Information Representation
The methods for storing and retrieving information in a data warehouse must be efficient, scale-able
and optimised for access. Analysis and reporting tools must be able to access specific information
from within a massive and expanding store, reliably and in useful time.

BI systems use OLAP technology to represent, store and retrieve information from the data
warehouse.
Information within the warehouse can also be queried using standard query languages such as SQL
and manipulated likewise. This requires specialist skills and so is mostly performed by the relatively
small number of BI Analysts who are needed to build generic reports and carry out ad-hoc analyses.
3. Analytics
Firms gather business intelligence information to help increase the firm’s competitiveness. But
information by itself is not enough to fulfil this mission. The information needs to be interpreted in
terms of the strategic and tactical objectives of the firm. As Davenport and Harris (2007), in their
important book Competing on Analytics: The New Science of Winning point out, the role of analytics
is to drive managerial decisions and actions. Analytics are the input to human and automated
decision making.
The simpler forms of analytics (standard and ad hoc reports, query and drill down, and alerts)
answer questions such as: What happened? When and how much? Where does the problem occur?
What requires action? These questions usually require answers at the operational level. The more
complex forms (statistical analysis, forecasting and extrapolation, predictive modelling, and
optimization) get at issues such as: Why is something happening? What if the trend continues? What
is going to happen?, What is the best we can do in anticipating the future?
Analytic capability requires both people and organizational infrastructure. Good information
management, usually supported by a data warehouse, is fundamental. BI professionals, who are
skilled, computer-savvy professionals with advanced degrees in such fields as operations research,
statistics, logistics, and marketing, work as staff people who create the models and methods that
apply in the firm and who run specific studies. As discussed in Sections 6.3 and 7.1, to be effective,
the ability to use analytic outputs should be widespread. Perhaps the most important group of
people and organizational issue is senior management and its commitment to analytics (Davenport
and Harris 2007), for without it, nothing happens.

Reports
Routine reports, produced on a heartbeat schedule such as weekly or monthly, are mostly created
automatically by the data warehouse and distributed on a firm’s intranet. Most users view
automated reports statically as is. Analysts, however, also create and examine reports filtered by
criteria (e. g., type of business, location, size of purchase), exception reports (e. g., high or low
demand), requests for specific information from managers who use BI output, and customized data
combinations (called cubes) for special projects. It has been estimated that 75% of users of historical
data principally use routine reports that describe what happened.
Slice-and-Dice and Drill Down

The next level of usage beyond reporting is for analysis: to find out why something happened. Here
spreadsheets, online analytic processing, planning, and forecasting are involved. Much of this work
involves slice-and-dice and drill down on reported data. In slice-and-dice, analysts can view data
from many perspectives. For example, the revenue from, say, cereal, can be examined by brand,
region, (e. g., New York, Washington, Sydney), time (last week versus this week), and combinations
of parameters.
Drill down is used both to deal with exceptions and to find the components of a particular number or
result. In drill down, the user navigates through the data to Business Intelligence 181 obtain more
detail that helps explain why results are what they are. For example, if cereal in aggregate is selling
well in Washington, which brands are doing better and which are doing poorly? It is also possible to
drill up (e. g., consolidate data) and drill across (examine data at the same level for other products,
such as milk or cookies).
Query Cache Cube

Dimensions
Product group
Customer group
North South East
Region
Division
Customer
group Area
DeptStores Company code
Wholesale
Retail Region
Glass- Ceramics Plastics
ware Period
Division Profit Center
Bus. Area
1 Analysis 2 Analysis 3 Analysis

of Ceramics of Plastics of Plastics division
division division and Southern region
South East
North South East

Region
Region
North South East
Region
Customer Customer Customer

group group group
DeptStores DeptStores DeptStores
North
Wholesale Wholesale Wholesale

Retail Retail Retail
Glass- Ceramics Plastics Glass- Ceramics Plastics Glass- Ceramics Plastics
ware ware ware
Division Division Division
As an example, consider a financial analyst who wants to determine the monthly changes in the
balance sheet to assess trends and directions of growth or decline. The analyst also wants to
determine the potential effects of changes in the business environment (e. g., or in interest rate).
Changes in payables (e. g., to whom and how much is owed) and receivables (including the length of

the receivable cycle) indicate the health of both individual units and the firm as a whole. For the
income statement, the analysis revolves around changes in the origins of revenue and operating
expenses. The objective is to know which parts of the enterprise are producing financial resources
and which are consuming them, and the variances between actual values and budgets. If anomalies
(better or worse than expected values) occur, the analyst drills down to see which specific unit or
product is the source of the anomaly.
Ad Hoc Queries
The most sophisticated analysis of warehouse data is used for predicting what will happen. Here
techniques such as regression, optimization, data mining , and simulation are used. These future-
oriented BI studies usually result from ad hoc questions posed by users and analysts. The analyst
uses a query language, such as structured query language (SQL) or MySQL to ask for the needed data
from the data warehouse. In a typical situation, the analyst uses the metadata about the variables in
the data warehouse to obtain the data needed for the study. The metadata shields the analyst from
complexity in working with the warehouse. Analysts are given tools so they can work with the data
directly. Prebuilt solutions are becoming available that address specific areas such as procurement.
Real-Time Analytics
With the ever-faster pace of business, BI is moving to real-time analytics. Real time does not
necessarily mean zero latency; it does mean that data and analyses must be completed and available
in time so that decisions can make a difference. As a result, a number of analysis aids are used,
including dashboards to monitor the current situation, alerts to assemble the team needed to
respond, and decision engines that give accurate answers quickly.
4. Presentation of Business Intelligence

Reports, analyses and queries are of limited use if the users cannot interact with them in a
convenient and comfortable manner. The role of the user interface is an important design
consideration for BI implementers. The lead on this has come from a range of providers but must
acknowledge the influence of familiar Office tools such as Excel. These are the tools that people in
the workplace are used too and mostly feel comfortable with. A lot of development work has gone
into this and BI implementers tend to adopt the same look-and-feel. This is aided by the availability
of software development tools that are optimised for Windows and also for web-browsers.

In management information systems, a dashboard is an executive information system user interface

that (similar to an automobile's dashboard) is designed to be easy to read. For example, a product
might obtain information from the local operating system in a computer, from one or more
applications that may be running, and from one or more remote sites on the Web and present it as
though it all came from the same source.
In SAP’s Strategic Enterprise Management tool multiple dashboards are implemented and accessed
via a ‘cockpit’.
The Cockpit in SAP SEM

“Information systems play an invaluable role in helping managers disaggregate the summary
measures. When an unexpected signal appears on the balanced scorecard, executives can query their
information systems to find the source of the trouble. If the aggregate measure for on-time delivery
is poor, for example, executives with a good information system can quickly look behind the
aggregate measure until they can identify late deliveries, day by day, by a particular plant to an
individual customer.”
The concept of the balanced scorecard can be seen reflected in the approach that SAP have taken in
presenting business intelligence information in their Strategic Enterprise Management tool (SEM)
that is fed by BI.

In the SEM cockpit an initial view of four ‘walls; is presented. These represent the four dimensions of
the Balanced Scorecard – modified a little – and represent:
 Black Wall – Finance (at the back in the figure above)

 Red Wall – Customers and Markets
 Blue Wall – Processes
 White Wall – Projects (a floor really)
There is no wall for learning and development which is a feature of the balanced scorecard but this
dimension does not yield much operative data and so is of limited value compared with other
summary measures. Management of this dimension is handled quite well in the Human Capital
Management module of SAP ERP. However, it can still be loaded into the warehouse and anlaysed –
it just doesn’t have a wall allocated in SEM.
5. Conclusion
Business Intelligence is a growing capability that more and more enterprises are seeking to leverage.
BI and ERP are not the same thing. A BI system draws data from many sources not just ERP. The data
is summarised and represents a snapshot rather than live transactional data.
Many firms see BI as a key capability that is needed to help them identify opportunities to improve
internal processes and exploit changes in the external environment, in their customer base but also
in the wider market and in what their competitors are doing as well.

Further Reading
Handbook on Decision Support Systems 1, Bernus et al , Springer, Berlin, 2008
Handbook on Decision Support Systems 2, Bernstein & Holsapple, Spring, Berlin, 2008
Continental Flies High with real-time Business Intelligence, Anderson-Lehman et al , MIS Quarterly
Executive, v3 No 4 Dec 2004 pp163-176

ERP Integration (U of Warwick)

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

ERP Integration (U of Warwick)

Uploaded by

Copyright:

Available Formats

UNIVERSITY OF WARWICK

Author: Neil Davis ©University of Warwick (WMG) 2010 Page 1 of 1

Author: N. Davis ©University of Warwick (WMG) 2010 Page 1 of 14

Author: N.Davis ©University of Warwick (WMG) 2010 Page 2 of 14

In this course we will seek to address the following questions:

 What is meant by integration in the context of Enterprise Resource Planning?

Author: N.Davis ©University of Warwick (WMG) 2010 Page 3 of 14

Case Study – Apple Computer Inc/Apple Inc.

Author: N.Davis ©University of Warwick (WMG) 2010 Page 4 of 14

product information, to ordering materials, planning and executing manufacturing strategies to

The definition of Information System used here is based on that of Alter1.

DEFINITION: An information system is a type of system that uses information technologies to

Author: N.Davis ©University of Warwick (WMG) 2010 Page 5 of 14

an Information system in context (based on Laudon).

The roles of information systems at different levels.

Author: N.Davis ©University of Warwick (WMG) 2010 Page 6 of 14

 analyzing data to establish relationships  ability to brainstorm, thinking

 providing technical or customer support

Author: N.Davis ©University of Warwick (WMG) 2010 Page 7 of 14

Every Business is an Information Business

2. Introduction to SAP ERP.

Author: N.Davis ©University of Warwick (WMG) 2010 Page 8 of 14

Author: N.Davis ©University of Warwick (WMG) 2010 Page 9 of 14

The evolution from SAP R/3 to SAP ERP

SAP Business Solution Suite

Author: N.Davis ©University of Warwick (WMG) 2010 Page 10 of 14

Fig 7 SAP ERP Solution Map 2004

Author: N.Davis ©University of Warwick (WMG) 2010 Page 11 of 14

IBM example of a workflow scenario

 Workflow Engine automates business processes

Author: N.Davis ©University of Warwick (WMG) 2010 Page 12 of 14

 Steps can be activities comprising one or more tasks

Components of a SAP Workflow Step (source: SAP Workflow in Plain English)

Author: N.Davis ©University of Warwick (WMG) 2010 Page 13 of 14

IT Doesn’t Matter. Carr N., Harvard Business Review, 2002.

Author: N.Davis ©University of Warwick (WMG) 2010 Page 14 of 14

Author: Philip Foster ©University of Warwick (WMG) 2010 Page 1 of 1

Here is a brief time line of the history of ERP: [8]

Author: Philip Foster ©University of Warwick (WMG) 2010 Page 2 of 2

2003-2005 Industry consolidation occurs: [6]

Author: Philip Foster ©University of Warwick (WMG) 2010 Page 3 of 3

Author: Philip Foster ©University of Warwick (WMG) 2010 Page 4 of 4

2. Drivers for change

Figure 1 Forrester effect [8]

Author: Philip Foster ©University of Warwick (WMG) 2010 Page 5 of 5

Fig 2 Current thinking based on the Forrester effect [8]

As can be seen in the Forrester effect,

Author: Philip Foster ©University of Warwick (WMG) 2010 Page 6 of 6

Author: Philip Foster ©University of Warwick (WMG) 2010 Page 7 of 7

There is less likelihood of stock perishing, becoming obsolete or out of date

Author: Philip Foster ©University of Warwick (WMG) 2010 Page 8 of 8

Author: Philip Foster ©University of Warwick (WMG) 2010 Page 9 of 9

2. Anderegg, Travis, MRP/MRPII/ERP/ERM — Confusing Terms and Definitions for a Murkey

9. Forrester J. (1961) “Industrial Dynamics” MIT, 1961.

Author: Philip Foster ©University of Warwick (WMG) 2010 Page 10 of 10

Author: N. Davis ©University of Warwick (WMG) 2010 Page 1 of 1

The Order-to-Cash process

Author: N. Davis ©University of Warwick (WMG) 2010 Page 2 of 2

2. Basic Process for Sell-from-Stock Order Fulfilment.

Author: N. Davis ©University of Warwick (WMG) 2010 Page 3 of 3

Author: N. Davis ©University of Warwick (WMG) 2010 Page 4 of 4

Customer (purchasing) Goods Receiving Accounts

Receive Purchase Pick & Prepare Create & send

Receive Create & Send