introduction to enterprise systems - ntnu · j. a. gulla introduction to enterprise systems page 2...
TRANSCRIPT
J. A. Gulla Introduction to Enterprise Systems
Page 1 of 42
Introduction to Enterprise Systems
Version 1.0 (Created on 14.04.2004 13:50)
Jon Atle Gulla
Norwegian University of Science and Technology
Trondheim, Norway
Email: [email protected]
Abstract:
This document gives a brief introduction to enterprise systems. Using SAP R/3 as
an example, we discuss the particularities of these systems and see how they
distinguish themselves from traditional information systems. As these systems are
delivered with pre-implemented modules and address the organizations’ business
processes, they require a slightly untraditional implementation approach with a
strong focus on business modeling and organizational analysis. Enterprise systems
are often introduced as part of larger reengineering projects, enabling the
organizations to streamline their backbone operations and work more efficiently.
1. What is an Enterprise System?
Organizations today depend on information systems that help them carry out their
operations efficiently and reliably and keep information updated and available.
Some of these systems have been developed internally and cover just a small fraction
of the organization’s processes or data. They are often not well integrated with other
systems and require a substantial amount of manual work to complete the business
processes. Increasingly, however, large-scale standard packages are replacing the
smaller and specialized solutions. From 1985 to 1997 the share of large organizations
using packaged enterprise systems has risen from about 30% to 95% (Robsen 1997).
When Hydro Agri Europe introduced its SAP enterprise system in 1999, it replaced
around 120 applications that were used all over Hydro’s 17 sites in Europe. Whereas
the packages in the past were only used by large organizations, we now have
software intended for small and mid-size companies as well. A survey of European
mid-size companies shows that the adoption of packaged enterprise systems
increased from about 27% in 1998 to more than 50% in 2000 (van Erdingen et al.
2000). With the introduction of light versions and accelerated implementation tools
in recent years this trend has continued and few organizations are now running their
businesses without packaged software.
An enterprise system is a packaged application that supports and automates business
processes and manages business data. They come with pre-implemented and
customizable modules that reflect best practice for common business operations.
Business data from different functional areas are integrated and kept consistent
across the organization. A characteristic of enterprise systems is their complexities
both in terms of business data and in the way they affect the organization’s business
J. A. Gulla Introduction to Enterprise Systems
Page 2 of 42
practices and individual work tasks. The term enterprise system is often used
synonymously with enterprise business application or with the more restricted term
enterprise resource planning (ERP) system. We will in this document base the
discussion on ERP systems, though the conclusions are equally valid for other types
of enterprise systems.
1.1 Packaged Software
Enterprise systems closely mirror the typical operations of large corporations. They
include electronic documents for traditional paper documents like purchase orders,
sales orders, plant maintenance orders, and invoices. There are enterprise system
transactions that automate or support traditional manual tasks like creating purchase
orders, verifying invoices, and generating various reports. An analysis of all these
traditional tasks and documents reveals that there is little variation from one
company to another. The companies tend to use the same documents, carry out the
same tasks, and structure the company along the same lines. This is not very
surprising, as these tasks and documents do not really depend on the products or
services offered by the organization. They refer to generic activities that any
company needs to address to keep the company going and satisfy various legal and
business-imposed requirements. For example, both a software company and a travel
agency need to purchase products and services. Of course, not all companies have
exactly the same internal operations and documents. A consulting company may not
need to maintain a plant, though it is still the case that most activities of the
consulting company are also found in other kinds of companies.
However, it is also a fact that some companies tend to carry out these tasks more
efficiently or effectively than others. It may be that they have more skilled workers,
which is difficult for other organizations to duplicate, but the reason may also be the
way they organize the tasks or the way the staff is supported by other tools. The
internal business processes can vary substantially and have very different costs
associated with them. When Progressive Insurance started reengineering their
business, the average claims settlement took 31 days. The reengineered process took
only 4 hours. Similarly, 93% of L. L. Bean’s orders were fulfilled within 24 hours,
against an industry average of only 61% (Laudon & Laudon 1998).
The idea of packaged enterprise software, thus, is to develop a solution that
incorporates common tasks and data in companies and reflect best practice in the
industry. Many of the modules of enterprise systems are implemented in close
collaboration with industry partners to ensure that they provide state-of-the-art
functionality. In this way, the package is applicable in most organizations, and less
efficient organizations can use it to raise the standard of their internal business
processes. It is not just for automating tasks, but also for streamlining or
reengineering processes according to what has proven successful in other companies.
Most enterprise systems address the typical backbone operations of organizations.
These do not constitute any competitive advantage for the organization in any way,
and the only concern is to make them as efficient as possible. Since they are of low
J. A. Gulla Introduction to Enterprise Systems
Page 3 of 42
strategic importance, it is unproblematic that the same package is also used by
competitors. For strategically important processes, organizations still tend to
develop in-house solutions that are not available to competitors. It has to be noted,
though, that what is strategically important to some may be of little concern to
others. Companies like Amazon and Dell have advanced sales and distribution
processes that distinguish them from other online shops and give them a strategic
advantage. If they adopted a standard sales and distribution package, they would
lose this advantage and any other company could replicate the way they sell and
distribute products on the internet.
Standard packages include modules that are to some extent customizable to the
needs of the organization. Each module typically corresponds to a functional
department and includes a set of transactions. It is up to the organization to select
which transactions they should implement and customize them to their own needs.
For example, as part of the customization of the invoice verification transaction, the
organization decides to what extent the amounts on the received invoices can deviate
from the amounts assumed in the corresponding purchase order. There may be
organizational needs that cannot be met by the standard functionality, forcing the
project to implement add-ons that are added to the standard package as any other
transaction.
Some of the advantages of standard packages are listed in Figure 1 below. They are
usually faster and cheaper to implement, and the functionality is based on sound
business practices. If a well respected vendor is chosen, the documentation is
usually very good and the packages are continuously updated and improved.
However, there is a danger that the package does not provide the functionality the
organization really needs. If substantial customization and numerous add-ons are
needed, the costs may also rise substantially and lead to later upgrade problems. A
survey from AMR Research of 202 American package customers showed that one-
third planned to ask vendors to renegotiate their software maintenance contracts,
and more than 20% are considering switching to another software vendor (Sonqini
2004). Many organizations find that standard packages lock them to a particular
vendor, since it may be very costly and problematic to replace a package with
another one.
� Rapid availability
� Sound business practices
� Known and verifiable quality
� Low up-front and overall costs
� Inspectable documentation
� Available maintenance
� Continual research and updates
� Varied support and training
Figure 1. Advantage offered by standard packages (adapted from Robsen 1997).
J. A. Gulla Introduction to Enterprise Systems
Page 4 of 42
1.2 Integrated Solution
The same information is often needed in different departments of an organization.
When the purchasing department acquires a new material, it needs information
about that material, about potential vendors, and about how to allocate the costs of
the material. The finance department afterwards needs information about the
material and the vendor to verify and pay the invoice they receive. The sales
department needs information about customers rather than vendors, but must also
be able to relate revenues to the materials being sold. When all the transactions are
recorded in the General Ledger, information about materials, invoices and
organizational units has to be made available to the finance department. In the past,
there would be separate systems for each of the major tasks to be carried out
internally. This situation is illustrated in Figure 2, where we can see how different
systems keep track of the same business data and exchange information over batch
interfaces. The finance department, for example, would have a General Ledger
system, an Accounts Receivable system, and an Accounts Payable system, and all of
them receive data from other departments’ systems. Aggregated data from the G/L
system is then exported to a separate reporting system at regular intervals.
Each department defines its data according to its own goals and priorities. They use
the data for different purposes and may end up with slightly inconsistent records
with partly overlapping information. For example, the purchasing department needs
the names and addresses of vendors, price lists of all vendors’ products, and
information about the vendors’ deliveries and reliabilities. To the finance
department, a vendor is associated with an account and linked to information about
its bank, payment conditions and other financial data. Even if the same type of
information is used in different system, thus, the perspectives are different and the
records are not necessarily compatible.
In the past this led to departmental software that each kept information about the
same entities. When information had to be exchanged, like when the Accounts
Payable system was to process invoices from purchasing activities, information had
to be transferred from one system to another Since no system saw the complete
picture, the information maintained by different systems was often inconsistent,
incomplete, and a different levels of granularity. This was not necessarily
problematic for the departments themselves, but could cause considerable problems
when data about the complete process was to be collected. Data had to be reconciled
manually every time data was transferred between two systems. This was an error-
prone process, and the result was often delays and erronuous data. The whole
concept of maintaining and using batch interfaces was expensive and prevented the
organizations from working closely together to carry out the complete business
processes. Bancroft et al (1997) discusses a publishing company that had more than a
hundred undocumented batch interfaces that had to be run manually by operators of
the data center.
J. A. Gulla Introduction to Enterprise Systems
Page 5 of 42
Figure 2. Batch interfaces connecting multiple systems (adapted from Bancroft et al. 1998)
Enterprise systems provide an integrated and harmonized view of business data
across organizational boundaries. All the relevant data is stored centrally, and no
duplicates are used by locally developed systems. Instead of having a range of
business applications, we now have a range of transactions in one enterprise system
that all access the same database. There is not consistency issue, and all applications
have access to data that is continuously updated and checked for consistency and
completeness. Data from new transactions are immediately included in all the
reports available in the system. The data dictionary provides a unified view of all the
relevant business data and gives the different departments a common terminology.
Figure 3. An integrated data-driven enterprise system (adapted from Bancroft et al. 1998)
Warehouse systemWarehouse system
1 2
Fullfilment systemFullfilment system
1 2 4
A/R systemA/R system
1 2 4
G/L systemG/L system
1 4 5
Reporting systemReporting system
1 4 5
Sales systemSales system
1 2 4
Purchasing systemPurchasing system
1 3 4
A/P systemA/P system
1 3
Asset systemAsset system
1 5
Manufacturing systemManufacturing system
1 3 4 5
1: product/material master information
2: customer master information
3: vendor master information
4: financial master information
5: organizational master information
Warehouse systemWarehouse system
1 2
Fullfilment systemFullfilment system
1 2 4
A/R systemA/R system
1 2 4
G/L systemG/L system
1 4 5
Reporting systemReporting system
1 4 5
Sales systemSales system
1 2 4
Purchasing systemPurchasing system
1 3 4
A/P systemA/P system
1 3
Asset systemAsset system
1 5
Manufacturing systemManufacturing system
1 3 4 5
1: product/material master information
2: customer master information
3: vendor master information
4: financial master information
5: organizational master information
5 2
3
1
4
Sales
ManufacturingWarehouse
Fullfilment
A/R
Asset
management
G/L
Purchasing
Reporting
A/P
1: product/material master information
2: customer master information
3: vendor master information
4: financial master information
5: organizational master information
5 2
3
1
4
Sales
ManufacturingWarehouse
Fullfilment
A/R
Asset
management
G/L
Purchasing
Reporting
A/P
1: product/material master information
2: customer master information
3: vendor master information
4: financial master information
5: organizational master information
J. A. Gulla Introduction to Enterprise Systems
Page 6 of 42
1.3 System Complexity
Enterprise systems are among the largest and most complex IT systems on the
market. They process thousands of transactions every day and store information
about all aspects of the business. Unified data about materials, vendors and
customers need to be defined and maintained as the business evolves. Parts of the
organization also has to be modeled in great detail, like the structure and materials
used in production plants. There are models of production plants, including
locations and equipment, that include more than 50,000 entities.
However, the most difficult complexity comes from the intricate relationship
between enterprise system and organization. Organizations with complex
structures and processes will necessarily need enterprise systems that are customized
to deal with this type of complexity. As the organizational complexities grow, it will
be increasingly more difficult to analyze the organization’s needs and agree on the
requirements to the enterprise system. There are rarely any clear lists of
requirements in enterprise systems projects. The organization has vague ideas of
how their operations can be made more efficient, but these ideas cannot be directly
translated into system requirements. They also depend on the way the organization
works, their internal structures and their business processes. An alternative to
customizing a strict approval system for purchase orders, for example, is to involve
managers directly when purchase orders are created. While defining the system
requirements, thus, the project needs to define organizational structures and
business processes as well. The fundamental challenge is to find the combination of
system customization and business reengineering that optimizes business processes
with respect to speed, quality and costs. This involves knowledge of functional areas
of the organization, enterprise system technology, technical issues, management
structures, and external factors like legal requirements and partnerships.
Terminological misunderstandings and cultural conflicts are not uncommon when
people from so different backgrounds meet to discuss project objectives.
The complexities for individual employees should not be underestimated. Due to the
intimate relationship between enterprise system and organization, employees expect
the system also to change their duties and the way they carry out their tasks. Some
are uncertain about their jobs, knowing that many enterprise systems lead to later
staff reductions. They may also be skeptical towards spending all these resources to
develop a system that will just replace systems that are already in operation and
have proven themselves. Some employees may be reluctant to the whole project and
do not see the need for a new and very expensive solution. As many enterprise
systems projects are initiated by the top management team, many employees also
feel neglected or overrun in these projects. For the success of the project, however, it
is extremely important that the whole organization supports and contributes to the
implementation of the enterprise system.
J. A. Gulla Introduction to Enterprise Systems
Page 7 of 42
Company data (at end of project):
� Chemical industry sector
� Revenues 39.7 billion NOK ($$$$)
� 6,400 employees
� Represented in 9 countries
Project data:
� Solution: SAP R/3 v3.0F (10 modules)
� $ 126 million budget
� Duration 4 years
� More than 500 people involved
End-user training:
� 245 instructors trained
� 3,971 end-users trained
� 1,421 user procedures
� 58 training courses
Project documentation:
� Process model for each module
� 12,859 development documents
� 1,632 test documents
� 1,061 training documents
Figure 4. Complexities of large-scale enterprise systems project
Take the project data listed in Figure 4. They illustrate some of the complexities of
ambitious large-scale enterprise systems projects. This project, which was for a
global market leader in its segment, implemented a comprehensive solution over a 4
years period with some 500 people involved at various stages. A change
management team was set up to deal specifically with organizational changes in the
plants and offices. As the new solution was defined and prototyped, the CM team
tried to assess the impact on organizational units together with the relevant
employees. Plans for how to deal with these changes and prepare the people were set
up and used to work out a comprehensive training program. More than 1,400 user
procedures were written to explain the new business processes, and 58 training
courses were designed. Each site nominated its own local instructors that were
trained by the central implementation team. The 245 local instructors then trained
almost 4,000 end-users at the various sites. With this approach, the project tried both
to involve the line organization more actively and make sure that the users would
feel confident about the new enterprise system.
1.4 Software Vendors
A few large software vendors dominate the enterprise system business. SAP AG,
which has the largest market share with SAP R/3, was founded in 1972 in Walldorf,
Germany, by people that saw a market for generic business applications at a time
when business applications were customs made. It has also introduced products for
data warehousing, business intelligence, and customer relationship management,
among other things. The company now has a 30% market share in the strictly
defined ERP segment. An analysis based on software revenues against its four
biggest rivals (Oracle Corporation, PeopleSoft, Siebel Systems, and i2 Technologies)
in the wider enterprise system segment gives SAP close to 60% of the market. The
company has more than 21,000 customers in 120 countries that run close to 70,000
SAP installations. The total revenues of SAP in 2003 were at 7.0 billion Euro, and the
net income was at 1.1 billion Euro. With around 28,900 employees, it is the world’s
fourth largest software vendor.
J. A. Gulla Introduction to Enterprise Systems
Page 8 of 42
Figure 5. Worldwide ERP service revenues by segment (adapted from Accenture 2001)
The market of enterprise systems has shown continuous growth over the last 10
years (see Figure 5). Whereas the total global revenues in the ERP segment were at
about $32 billion in 1999, it is now assumed to be close to $58 billion (Accenture
2001). It is worth noting, however, that the isolated implementation costs only
account for about a fourth of these total revenues.
2. Enterprise System Functionality
The functionality of enterprise systems is broken down into high-level work areas like
logistics, financial accounting, and human resources. Within each area, there are
modules that tend to correspond to organizations’ functional units. There are
modules for plant maintenance, sales & distribution, materials management, service
management, asset management, finance, etc. Some of these modules are again split
into sub-modules that also correspond to organizational units. The Materials
Management module contains sub-modules for purchasing, inventory management,
and invoice verification, for example.
An area, a module or a sub-module each comes with pre-defined customizable
functionality that reflects best practice in this business. The functionality is
comprised of the following four important elements:
� Transactions: These are the business operations that the software offers. Some
of them can be set up for automatic execution, but most transactions are
manually carried out according to some operational instructions. A transaction
consumes or refers to some data, is performed by a particular user on behalf of a
particular organizational unit, and produces results like reports, documents, or
changed status variables. Creating sales orders is a transaction, but so are approving
purchase requisitions and listing outstanding (not delivered) purchase orders. An
enterprise system will usually have thousands of transactions available to its
users. Figure 6 shows how the transactions are organized in functional
0
10000
20000
30000
40000
50000
60000
1999 2000 2001 2002 2003 2004
$M
Implementation Consulting Operations management Support Training
J. A. Gulla Introduction to Enterprise Systems
Page 9 of 42
hierarchies in SAP R/3. Each transaction in R/3 is also assigned a unique
transaction code, like ME25 for creating purchase orders with unknown vendor.
Figure 6. The SAP main menu
� Organizational structures: Business transactions are always carried out on
behalf of some organizational unit. When the system is customized, the
organization’s organizational units have to be mapped onto the generic
structures assumed by the enterprise systems. Each defined user in the system is
linked to an organizational unit that also constrains what he is allowed to do.
Examples of organizational structures are company codes, sales organizations, and
purchasing organizations.
� Documents: Documents are used and produced when transactions are executed.
The status of these documents decides which transactions can run, and in what
order. There are both external documents like sales orders and purchase orders, and
internal documents like purchase requisitions and goods receipts.
� Master data: Data that is reused in many transactions tend to be defined
separately as master data. Examples of master data are materials, customers, and
vendors. When a new purchase order is created, thus, the user searches for the
right material in the material master data and for the appropriate vendor in the
vendor master data. This both speeds up the entering of transactional data and
ensures that the data used is consistent.
To go into some more detail, we will now have a brief look at the overall
functionality of SAP R/3. Figure 7 displays some of SAP’s most important
J. A. Gulla Introduction to Enterprise Systems
Page 10 of 42
organizational concepts and their relationships. These structures represent the legal
and organizational views of the organization and form a framework that supports all
business activities. Each installation is set up as a separate client that all other data is
related to. The other concepts are explained as we go through the functionality of
the various parts of SAP R/3. More detailed and complete presentations of SAP R/3
are found in Hiquet & Kelly (1998), Curran & Keller (1998).
2.2 Financial accounting
SAP R/3 includes three main categories of functionality that are needed to run the
financial accounts for a company: FI (Finance), CO (Controlling), and AM (Asset
management). Together these modules take care of all financial data related to both
the external and internal organization of the business.
The external organizational units of a company represent legal corporate entities that
must report financial data to regulatory agencies for external investor or tax
purposes. The balance sheet, profit and loss, and cash flow statements are all
produced at the level of these legal entity structures. The FI module addresses the
external organization and includes accounts payable (A/P), accounts receivable
(A/R), general ledger (G/L) and capital investments. Each legal entity is represented
by a company code, and all financial postings in SAP must contain a reference to a
company code. The company code is the smallest organizational unit for which a
balance sheet and profit and loss statements can be produced. The financial results
of many company codes can be consolidated into a company in SAP. As an example,
the Hydro Agri Europe SAP implementation contains almost 50 company codes
(Gulla & Mollan 1999). A common charts of accounts is then produced for a number
of company codes. Within each company code, there may also be several business
areas with their own reporting requirements.
Figure 7. Some organizational concepts in SAP R/3
Charts of
accounts
Charts of
accounts
Company
code
Company
code
PlantPlant
Purchasing
group
Purchasing
group
Purchasing
organization
Purchasing
organizationSales
organization
Sales
organization
Distribution
channel
Distribution
channel
DivisionDivision
ClientClient
Business
area
Business
areaProfit center/
Cost center
Profit center/
Cost center
Controlling
area
Controlling
areaCharts of
accounts
Charts of
accounts
Company
code
Company
code
PlantPlant
Purchasing
group
Purchasing
group
Purchasing
organization
Purchasing
organizationSales
organization
Sales
organization
Distribution
channel
Distribution
channel
DivisionDivision
ClientClient
Business
area
Business
areaProfit center/
Cost center
Profit center/
Cost center
Controlling
area
Controlling
area
J. A. Gulla Introduction to Enterprise Systems
Page 11 of 42
The internal organization reflects how the company wants to analyze its own
business. The controlling area is the highest CO organizational unit, for which
internal analyses are needed. The functionality in CO handles costing, cost centers,
profit centers, internal orders, and a variety of analysis and reporting needs. The
actual costs and revenues to CO are normally posted from other SAP modules.
The asset management category is used to manage all types of corporate assets
including fixed assets and leased assets. It also provides the ability to manage,
measure , and oversee capital investment programs.
Plants play very important roles in enterprise systems. They produce goods, renders
services, or makes goods available for distribution. In practice, plants are used to
represent entities as different as manufacturing facilities, warehouse distribution
centers, regional sales offices, corporate headquarters. An SAP installation can have
anything from a few plants to several thousand plants defined.
Whereas the plant is a central organizational concept, the material master is a vital
master data concept. All materials and services are defined as master data that is
linked to various organizational concepts. Basic data about units of measure and
material numbers are stored are the same across all organizational units. Different
sales organizations can have different strategies for selling the material. The costs
and purchasing strategies for a material is specific to each plant that buys it. Finally,
there may also be particular storage and MRP requirements that depend on where
the material is stored in the plant. The main views of the material master are shown
in the table below:
Material view Data in view
All levels Material numbers, units of measure, etc.
Sales organization/distribution channel How material is sold, material status, etc.
Plant How material is purchased and delivered, quality
management status, accounting and costing data.
Plant/storage location Material requirements planning data, storage
conditions
2.3 Manufacturing and Logistics
This is a very large category and contains some of the most complex business flows
of a business. It can be divided into five major components: materials management,
plant maintenance, quality management, production planning and control, and a
project management system.
The materials management (MM) module covers all tasks within the supply chain,
including consumption-based planning, purchasing, vendor evaluation, inventory
management, and invoice verification. Each vendor used in the organization must
be defined as a master data record that includes company-specific data about bank
J. A. Gulla Introduction to Enterprise Systems
Page 12 of 42
accounts and accounting information as well as purchasing and partnering data that
are specific to each purchasing organization. A purchasing organization normally
buys materials for one or more plants, and many purchasing organizations are
grouped under the same company. All material needs in the organization are sent to
the purchasing organization in the form of purchase requisitions. If there are
contracts or valid price lists available for this material, a purchase order may be
created with reference to these and sent to the vendor. Requests for quotation may
be sent out to potential vendors and later used to create purchase orders or new
contracts/price lists. When the goods arrive at the warehouse, a good receipt process
checks the deliveries against the purchase order and an invoice process verifies and
records the amount on the corresponding invoice. An accounts payable posting in FI
is automatically triggered, and the system may use a payment program to handle the
cash transaction automatically. Quality management is integrated with the
procurement process, so that the user can identify inspection points for incoming
materials during the manufacturing process.
The plant maintenance (PM) module supports the tasks associated with planning
and performing repairs and preventative maintenance. A detailed model (master
data) of the plant has to be defined, and this model establishes links to the materials
needed and the people responsible for the various installations. When something is
broken or has to be replaced, plant maintenance (PM) orders are created. If the
needed materials are in the warehouse, a request to the warehouse is generated form
the PM order. Otherwise, the material needs are automatically entered into a
purchase requisition that is sent to the purchasing department.
The production planning and control (PP) module supports both discrete and
process manufacturing processes. It provides functionality for capacity leveling and
requirements planning, materials requirements planning, product costing, bills of
material, explosions, CAD dialog interface, engineering change managements, and
production orders creation.
2.3 Sales & Distribution
This SD module provides all the functionality needed to manage a global and
integrated sales process. A company may contain a number of sales organizations that
are responsible for distributing goods and services, negotiating sales conditions, and
carrying out sales transactions. Each sales organization sets it own distribution and
pricing policies. It uses distribution channels like retail trade, direct sales or e-commerce
to reach its customers. Each distribution channel may include a number of product
lines (divisions).
Customers are defined as master data records with three levels of data: General data
about names and addresses are common across all units, accounting data are
specified at the company code level, and information about shipping, billing, and
partnering is specified for each sales organization.
J. A. Gulla Introduction to Enterprise Systems
Page 13 of 42
When potential customers make inquiries to the sales organization, it may send them
quotations with products and prices. If a quotation is accepted by a customer, a sales
order is created and the goods are shipped to the customer. The same is the case if
there are valid contracts that commit a customer to buy some product at a particular
price and date. The information about goods and customer is sourced from the
corresponding material master records. Special functionality for entering sales orders
that are assemble-to-order, build-to-order or engineer-to-order is available. When
the invoices are created and sent by the billing department, corresponding accounts
receivable postings are automatically made in the FI module. Incoming payments by
direct debiting or manual means are later matched against these invoices.
2.4 Human Resources
The human resources (HR) category contains transactions for managing, scheduling,
paying, and hiring the people that make the company run. This includes payroll,
benefits administration, application data administration, personnel development
planning, work-force planning, time management, and travel expense accounting.
It also allows the company to maintain and plan human resources and work plans
according to a matrix organization. Jobs and responsibilities can be defined in
temporary project structures.
3. Architecture
Enterprise system packages come with both pre-implemented modules and
environments for customization, programming, and administration. They typically
depend on a standard underlying database management system like Oracle and
provide interfaces to a range of other applications.
3.1 Client/Server Architecture
Large enterprise systems are set up as client/server applications with two or three
tiers. The architecture is made up of a number of clients (generally desktop
computers) that request services from a number of servers (specialized larger
computers). The server’s job is simply to reply to all the requests made of it, like
sending back data or updating some master files. As the combination of hardware,
software and networks needed to construct a client/server architecture is complex, a
collection of software providing the connections and processing the interactions
between the layers is also needed. This software is referred to as middleware and is
installed on each of the layers of the architecture. It includes functions like the
network operating system, transport stacks, routers, bridges, and gateways.
For enterprise systems it is common to set up a three tier client/server architecture, as
shown in Figure 8:
� User interface: The first tier provides the graphical user interface and is installed
on the end-user’s desktop computer. If the user needs to access some
J. A. Gulla Introduction to Enterprise Systems
Page 14 of 42
information or run a transaction in the system, he sends a request to the
application server. When the application server has carried out the request, it
returns the results to the user interface part.
� Application server: The application server at tier 2 runs all the modules of the
enterprise system. Transactions like Create purchase order in MM and Post invoice
in FI are run on this server, but access the underlying data from the database
server. Requests to the database server are sent, and the results are processed
and prepared for being sent to the user interface part. Third party- or user-
developed software can be added at this tier, as long as it is written according to
the standards of the enterprise system environment. In SAP’s case it means that it
must be written in ABAP/4 and use the BAPI interfaces defined.
� Database server: The database server is accessed and updated constantly and is
often distributed among multiple machines. The logical mapping of data
between application modules and database is supported by a sophisticated data
dictionary.
Smaller enterprise systems installations can be implemented in a two-tier
environment. Very large and complex installations may use separate application
servers for separate groups of modules. Whereas financial accounting runs on one
applications server, for example, another server is used for logistics and human
resources.
Figure 8. A three-tier enterprise system architecture
3.2 Data Repository
All the data in an enterprise system is arranged in accordance with a central data
dictionary that defines all the system’s entities and their attributes and relationships.
User requests from PC:
Show report of customer
#4711
User requests from PC:
Show record of customer
ACME
Customer
database
Clientsrun program partUSER INTERFACE
Client/serverruns program partAPPLICATION
Serverruns program part
DATABASE
USER INTERFACE request
customer data from APPLICATION
USER INTERFACE request
customer data from APPLICATION
APPLICATION processes data and
delivers result to USER INTERFACE
APPLICATION processes data and
delivers result to USER INTERFACEDATABASE delivers data to
APPLICATION
DATABASE delivers data to
APPLICATION
APPLICATION requests retrieval
of customer data from DATABASE
APPLICATION requests retrieval
of customer data from DATABASE
Tier 1 Tier 2 Tier 3
User requests from PC:
Show report of customer
#4711
User requests from PC:
Show report of customer
#4711
User requests from PC:
Show record of customer
ACME
User requests from PC:
Show record of customer
ACME
Customer
database
Customer
database
Clientsrun program partUSER INTERFACE
Client/serverruns program partAPPLICATION
Serverruns program part
DATABASE
USER INTERFACE request
customer data from APPLICATION
USER INTERFACE request
customer data from APPLICATION
APPLICATION processes data and
delivers result to USER INTERFACE
APPLICATION processes data and
delivers result to USER INTERFACEDATABASE delivers data to
APPLICATION
DATABASE delivers data to
APPLICATION
APPLICATION requests retrieval
of customer data from DATABASE
APPLICATION requests retrieval
of customer data from DATABASE
Tier 1 Tier 2 Tier 3
J. A. Gulla Introduction to Enterprise Systems
Page 15 of 42
The data dictionary tells us for example which tables are used to store purchase
orders and what the fields of these tables are. It also gives us the names and contents
of all reports defined, as reports and programs in general are stored as any other
object in the system.
The data dictionary is based on the table structure shown in Figure 9 and explained
below:
� System configuration tables: These are tables that are maintained primarily by
the software vendor or the IS department. They define the overall structures of
the system and should rarely be changed by the customer. Some of these tables
determine how the implementation environment should work, or how new
programs are registered in the system. Others concern general things about units
of measure, printers, or transport objects.
� Control tables: Control tables contain parameters that govern the actual
behavior of the system. They can for example decide if it is possible to process
invoices for goods that are not delivered, or who is allowed to approve purchase
requisitions at which approval level. The tables also contain the organizational
structures of the company, e.g. which purchasing organization works on behalf
of which company codes. When we talk about system customization, we usually
refer to the values entered in control tables.
� Master data tables: Master data tables and transactional data tables define the
application data of the system. Both types are updated by customers when the
system is in operation as part of their business responsibilities. An initial set of
master data is set up in the course of the project. They describe business entities
that are reused and referred to by the daily transactions in the system. Examples
of master data are G/L accounts (FI), assets (AM), cost centers (CO), materials
(MM), customers (SD), vendors (MM), employees (HR), plants (PM) and work
centers (PP). Each of these entities are defined by means of several tables.
� Transactional data tables: The tables are not entered as part of the project. They
are the largest in the operative system, since they capture the daily operations in
the system. Documents like purchase orders, sales orders and plant maintenance
orders are all transactional data, and each document tends to be split up in
different parts that are stored in different tables. The information about vendors
in purchase orders, for example, is stored in another table than the actual
materials being requested. Information from the appropriate vendor is copied
into the transactional data table from the vendor master data table.
Complete data sets for several clients can be stored in the same machine, allowing
the project to run different prototypes at the same time on the same machine.
J. A. Gulla Introduction to Enterprise Systems
Page 16 of 42
Figure 9. Tables in SAP R/3
3.3 User Administration
The definition of user profiles is very important in enterprise systems. The profiles
correspond to their daily tasks and responsibilities and should ensure that a user can
only perform transactions that belong to his job. The data in enterprise systems can
be very sensitive and concern the entire organization. Misuse or leak of data is a
serious issue that has to be reflected in the way user rights are set up. Another thing
is that limited user rights prevent the user from running transactions that he does not
know well and that may easily result in errors.
We will not go into the details of authorization profiles and objects, as these tend to
vary from one package to another. However, it is important to realize that the user
profiles consists of two elements (see Figure 10). On the one hand, we can specify
that a user of a particular profile can only enter certain values for certain fields. We
can for example restrict a purchaser to be able to place purchase orders on behalf of
only one particular purchasing organization or for one particular plant. On the other
hand, a profile must also list the transactions that the user is allowed to run. This is
done by grouping related transactions together into task groups and associating the
profile with a number of these task groups. We will see some examples of task
groups in Figure 13.
Figure 10. User authorization objects
3.4 Implementation Environment
Master
data tablesMaster
data tablesMaster
data tablesMaster
data tablesMaster
data tables
Master
data tablesMaster
data tablesMaster
data tablesMaster
data tablesTransaction
data tables
Master
data tablesMaster
data tablesMaster
data tablesMaster
data tablesControl
tables
Master
data tablesMaster
data tablesMaster
data tablesMaster
data tablesSystem
configuration
tables
R/3 Applications
Master
data tablesMaster
data tablesMaster
data tablesMaster
data tablesMaster
data tables
Master
data tablesMaster
data tablesMaster
data tablesMaster
data tablesMaster
data tables
Master
data tablesMaster
data tablesMaster
data tablesMaster
data tablesTransaction
data tables
Master
data tablesMaster
data tablesMaster
data tablesMaster
data tablesTransaction
data tables
Master
data tablesMaster
data tablesMaster
data tablesMaster
data tablesControl
tables
Master
data tablesMaster
data tablesMaster
data tablesMaster
data tablesControl
tables
Master
data tablesMaster
data tablesMaster
data tablesMaster
data tablesSystem
configuration
tables
Master
data tablesMaster
data tablesMaster
data tablesMaster
data tablesSystem
configuration
tables
R/3 Applications
Job (profile)Generic tasksGeneric tasksGeneric tasks
Transaction codesTransaction codesTransaction codes
Legal range of
object values
Job (profile)Generic tasksGeneric tasksGeneric tasksGeneric tasksGeneric tasksGeneric tasks
Transaction codesTransaction codesTransaction codesTransaction codesTransaction codesTransaction codes
Legal range of
object values
J. A. Gulla Introduction to Enterprise Systems
Page 17 of 42
Enterprise systems include a sophisticated implementation environment that helps
the system experts to customize the system and implement additional software.
Pure programming tools are needed, and each vendor tends to define its own
programming language with high-level functions for common system operations.
The example routine below is written in ABAP/4, the language supported by SAP
and is explained in more detail in Kretschmer & Weiss (1996).
* Database table with flight data tables flights. * Internal table for flights data my_flights like flights occurs 10 with header line. * Statistical data data sum_occupied_seats like my_flights-seatsocc. * Reading the flights from the database select * from flights into table my_flights order by primary key * Displaying the number of occupied seats on each flight * with headers and subtotals for each carrier loop at my_flights. at new carrid. new-page. write / my flights-carrid. clear sum_occupied_seats. endat. add my_flights-seatsocc to sum_occupied_seats. write / my_flights-seatsocc. at end of carrid. write / sum_occupied_seats endat. endloop.
The lines that begin with an asterix are comments. This little program displays the
number of occupied seats for each flight in the database. All the flights are stored in
the flights database, and we define an internal my_flights table that is filled with
information from flights.
The implementation environments also incorporate non-programming facilities for
easy customization of standard system functionality. The idea is to use graphical
models of system functionality and provide a user interface to customization tables
that refer to the business terms of the model. These two features are shown as the
model level and the implementation level in Figure 11, respectively. The model
provided by the vendor – the reference model – documents the complete functionality
of the system in business-related terms. Overall business requirements are analyzed
and specified in the same modeling formalism. An implementation guide explains
what the customization tables mean and how they should be set up to reflect the
business requirements from the model. Business models and implementation
guides, thus, replace traditional programming for standard enterprise system
functionality.
J. A. Gulla Introduction to Enterprise Systems
Page 18 of 42
Figure 11. Using models to map real world needs to customization tables
3.5 Transportation System
There are usually several installations of the enterprise system in a project. These
installations are used by different people for different purposes and ensure that new
functionality is efficiently developed, tested and put into operation. A typical
project makes use of the following three systems:
� Development system: All new functionality is developed and initially tested
here. The system is used by customization experts and contains very little
realistic data. Only unit testing is performed in this system, and the testing rarely
involves any business people.
� Integration system: This system is often referred to as test system or simulation
system as well. The system is set up with real business data and is used to test
the new functionality under realistic conditions. Business experts are used to run
the tests and analyze the results. No functionality is developed in this system.
� Production system: This is the enterprise system that is in actual use. All
functionality here has undergone intensive testing in the integration system
beforehand. Since enterprise systems are so important for the organization’s
daily operations, the systems will often run while additional functionality is
being developed and tested. Upgrades of the production system can then be
performed in batches at night.
Application level(real world)
Implementationlevel
(software)
Model level(Process model)
Application level(real world)
Implementationlevel
(software)
Model level(Process model)
J. A. Gulla Introduction to Enterprise Systems
Page 19 of 42
Figure 12. Transporting new functionality from development to production
Within a system there may also be several clients. The development system may for
example introduce all new functionality on one client and conduct the initial unit
testing on another client on the same system. A transportation system helps the
project to move new functionality or new data from one system to another (see
Figure 12). When new functionality is developed, the development teams reserves
the appropriate objects, does the necessary customization or programming, runs unit
tests, and finally releases the objects for transportation. The objects are grouped
together in classes and transported to the integration system for testing. If errors are
detected, the new functionality is taken out of the test environment and the
development team is notified. A new round of development and unit testing on the
development system is necessary. A successful integration test leads to a new
transport from the test system to the production system, making the new
functionality available in the system used to run the organization’s business.
4. Customizing Enterprise Systems
Enterprise systems come with pre-implemented customizable modules that do not
require any programming to run. The behavior of each module is controlled by a
number of system-defined parameters. To set up the system, the project needs
intimate knowledge of the nature of these parameters and how they combine to
produce a running enterprise solution. Understanding how business needs map
onto these parameters is vital to the project and necessitates experts on both business
issues and enterprise system features.
In the following, we will see how the enterprise system supports the matching of
business needs and system functionality.
Release
object
Reserve
object
Test
object
Developmentsystem
Test system
Productionsystem
Use
object
Transport if OK
Transport if OK
Release
object
Reserve
object
Test
object
Developmentsystem
Test system
Productionsystem
Use
object
Transport if OK
Transport if OK
J. A. Gulla Introduction to Enterprise Systems
Page 20 of 42
4.1 Fit Analysis
It is important to understand that enterprise system projects do not specify system
requirements as independently as many other projects. In the requirements
engineering phase we investigate how to map the desired processes and structures of
the company onto the functionality offered by the enterprise system. Ideally, all the
needs can be identified and fulfilled simply by customizing the modules that are
needed. In most cases, however, the needs are not clear and it is not obvious how to
relate them to the enterprise system functionality.
From an enterprise system’s point of view, an organization can be described in terms
of processes, organizational structures and jobs. Figure 13 shows how each of these
parts are involved in a fit analysis process that tries to work out an optimal match of
wanted and offered functionality. The example data used in the figure comes from a
fertilizer plant in Rostock, Germany, which is part of a pan-European fertilizer
company. When the system is to be customized to the needs of the organization, the
project needs to examine how the desired business processes can be supported by the
transactions available in the enterprise system. In our example from Rostock, the
desired overall business processes had already been specified beforehand as the
result of a reengineering activity in the company. These took into account best
practice reports from the industry, key performance indicators needed by the
management, and various other organizational and legal constraints. The challenge
of the project was to decide which transactions to use, and how these were to be
customized or possibly changed. If the needs were not covered by the system, the
project had to decide whether the requirements had to be modified or additional
programming was called for.
Figure 13. Analyzing jobs, processes and organizational structures
Harmonized purchasing
process in HAE:
- best practice processes
- key performance indicators
- responsibilities
- legal considerations
Harmonized purchasing
process in HAE:
- best practice processes
- key performance indicators
- responsibilities
- legal considerations
Rostock
purchasing
organization
Rostock
purchasing
organization
Create/change/display
purchase order
Create/change/display
purchase order
HROHRO
RSK1RSK1
CCMCCM
HRO1HRO1
RSK2RSK2
SAP organizational structureSAP transactions
HAE site organizationHAE business processes
Purchasing
Purchasing contracts
Purchasing analysis
Request for quotation
Creation/rel. – requisition
Approval of requisition
Stock overview
Purchasing
Purchasing contracts
Purchasing analysis
Request for quotation
Creation/rel. – requisition
Approval of requisition
Stock overview
TasksJob
Rostock
purchasing
Rostock
purchasing
Fit analysis
Job analysis
Harmonized purchasing
process in HAE:
- best practice processes
- key performance indicators
- responsibilities
- legal considerations
Harmonized purchasing
process in HAE:
- best practice processes
- key performance indicators
- responsibilities
- legal considerations
Rostock
purchasing
organization
Rostock
purchasing
organization
Create/change/display
purchase order
Create/change/display
purchase order
HROHRO
RSK1RSK1
CCMCCM
HRO1HRO1
RSK2RSK2
HROHRO
RSK1RSK1
CCMCCM
HRO1HRO1
RSK2RSK2
SAP organizational structureSAP transactions
HAE site organizationHAE business processes
Purchasing
Purchasing contracts
Purchasing analysis
Request for quotation
Creation/rel. – requisition
Approval of requisition
Stock overview
Purchasing
Purchasing contracts
Purchasing analysis
Request for quotation
Creation/rel. – requisition
Approval of requisition
Stock overview
TasksJob
Rostock
purchasing
Rostock
purchasing
Fit analysis
Job analysis
J. A. Gulla Introduction to Enterprise Systems
Page 21 of 42
The project also needs to map the organization’s organizational structures to the
structures assumed by the enterprise system. Since the structures used by the
enterprise system reflects common ways of structuring organizations, it is rare that
this mapping fails. However, there are usually several ways of mapping
organizational structures, and these can have serious consequences for reporting,
accounting, and work coordination and flexibility. In the example from Figure 13
The Rostock site is mapped onto company code HRO, though the physical plant is
split up into two logical plants in the system, RSK1 and RSK2. RSK1 is used to
control the production and management of finished goods, which are owned by a
separate legal unit that is also is charge of finished goods from other plants. RSK2 is
for raw materials and spare parts and has no role in the sales process of the
company. Two purchasing organizations are set up, HRO1 and CCM. Whereas
HRO1 is a local purchasing organization for Rostock, CCM is a central purchasing
organization that maintains all the contracts of the entire company. Another and
simpler way of mapping the organizational structures would have been to set up
only one purchasing organization (HRO1) and only one plant that would take care of
raw materials, spare parts, and finished goods. An even simpler solution would be
to avoid having local purchasing organizations at all and use CCM for all purchasing
at all sites of the company.
The project also needs to decide who should have access to which transactions. This
reflects the way work is organized and the human resources available. It also needs
to take into account certain security issues and strategies for preventing transactional
errors to occur. The normal procedure is to define jobs, or roles, that users are linked
to when their accounts are set up in the system. The job determines which tasks the
user can perform on behalf of which organizational units. A task is further
implemented as a collection of system transactions that are somehow interconnected.
In Figure 13 we show how the purchasing job in Rostock is defined. People linked to
this job perform 8 tasks that are each defined in terms of transaction codes. The
purchasing task, for example, includes the transactions for creating, changing and
deleting purchase orders. How these jobs are defined depends on the way the
organization wants their people to work. Notice that purchasers in Rostock are
linked to the Approval of requisition, which allows them to approve and release
purchase requisitions. A more control-oriented organization than Rostock might not
want the purchasers to approve purchase requisitions and would only include this
task in the purchasing manager’s job.
As already mentioned, it may not be possible to reconcile the needs of the
organization with the capabilities of the enterprise system. When discrepancies are
detected, the project faces four basic options (see Figure 14).
J. A. Gulla Introduction to Enterprise Systems
Page 22 of 42
Figure 14. Strategies for capabilities/needs mismatch (Robson 1997)
� Tolerate mismatch: If the discrepancy does not lead to any serious business
problems, it may be advisable to leave it as it is.
� Modify business processes: This allows the organization to keep its enterprise
system simple and standardized, but requires that the routines are changed and
people trained to work differently.
� Customize package: In some cases the problem can be solved simply by changing
some of the system’s parameters. This is a straight-forward approach that allows
the company to keep their processes and avoid unnecessary programming.
� Surround package with extra functionality: If the discrepancy cannot be solved by
means of customization, additional programs may be developed and integrated
with the system. Typical add-ons are programs for generating company-specific
reports or interfaces to other computer applications used by the organization. A
more serious change is to develop software that replaces some of the standard
software, like implementing a new user interface to a module.
We will in a later section go into some of the consequences of these choices.
4.2 Reference Model
Effective matching of user needs and system functionality is only possible if the
functionality is documented in a form that is understandable to the users and can be
related to the processes and structures of the organization.
A reference model documents all the standard functionality of an enterprise system. It
is delivered as part of the enterprise system environment and specifies the total
capabilities of the application. In the first round, the project may compare the
reference models of different applications as part of the vendor selection process. As
the project proceeds, the model is used to
Surround package
with extra functionality
Surround package
with extra functionality
Tolerate mismatchTolerate mismatch
Modify business
processes
Modify business
processes
Customize
package
Customize
package
Map of
discrepancies
Prioritized
business
requirements
Capabilities
of the
standard
package
Unmet needs
Surplus to needs
Surround package
with extra functionality
Surround package
with extra functionality
Tolerate mismatchTolerate mismatch
Modify business
processes
Modify business
processes
Customize
package
Customize
package
Map of
discrepancies
Prioritized
business
requirements
Capabilities
of the
standard
package
Prioritized
business
requirements
Capabilities
of the
standard
package
Unmet needs
Surplus to needs
J. A. Gulla Introduction to Enterprise Systems
Page 23 of 42
Figure 15. Selecting the functionality needed (Rosemann 2003).
� select which modules and which transactions that are relevant
� identify missing transactions in the application
� verify how the transactions can be used as part of business processes.
� estimate and plan the customization and add-ons needed
The model to the left in Figure 15 is an Event Process Chain (EPC) model for a
particular sub-module in SAP. On the right-hand side, the project has analyzed
which parts of the model are relevant to this particular organization. Unnecessary
functionality is shown in white boxes. The subsequent customization must make
sure that the unnecessary parts are blocked or made unavailable to users. The
project may also introduce other changes, like including needed transactions that are
not delivered as part of the package or modifying the way the transactions are
chained together. This is part of the business reengineering activities of the project
and will be discussed in a later section.
4.3 Implementation Guide
The implementation guide serves three purposes:
� Detailed exploration of system’s standard functionality. The business models are
specified at a workflow level and do not reveal all the details of the package’s
capabilities. To understand fully the standard functionality offered, you have
to look at the customization tables and investigate the parameters that can be
set. This is done with the implementation guide, which structures all the
tables according to functional areas, explains the effect of each parameter, and
provides examples of customization. The main window of R/3’s
Co nd itions proc es sing( Pur ch asing)
Specify ad dress of
cus tomer
Add ress is spec ified
Interest c alculat ion issp ec ified
Plant pro cessing
Maintain ac count inginformat ion
Sold- to par ty to be
create d
Cust omer is als o vendor
Planning group isspecif ied
Cust omer- material- infoprocess ing [s tan dar d]
Mainta in account c ont rol
Maintain sa les data
Ship-t o p art y t o be
c reated
T rading partn er iss pec if ied
Clear ing betwe en
cus to mer/vend orspecif ied for automatic
payme nt s
Basic da ta pr ocessin g forlegal contr ols [st andar d]
Management of physicalsamp les
Payer to be cr eat ed
Spec ify company code
Company code isspecifie d
Ban k det ails arespecifie d
Possible p aymentmethods ar e specif ied
Cust omer volume r ebateagr eeme nt proces sin g
[ nor mal]
Cus tomer mas ter re co rdis t o be c reated
Specify payment
t ransact ion d ata
Manual sample r elea se
Det erm ine cu st omerfunct ion
Invoice r ec ipient is t o be
c reated
Account g roup with
inte rn al numberass ignmen t det erm ine d
Def ine cus tome r number
Cus tomer number isdet er mined
Payment c ard data isma int ained
Sales area dat a arema int ained
Main ta in paymentinfo rmat ion
Alt ernativ e payerspecif ic t o company
code spec ifie d
Cr eat e c ust omer
Cus tomer mas te r r ecord
is c reated
Mat erial list ing/ exclus ion[ st andard ]
Sales pe rs onnel isp ro cessed
Specify ac co unt gr oup
Mainta in cont rol da ta
Sample r eceive r to be
create d
Account gr oup with
ex ter nal numberassignme nt d eterm ined
Alter nat ive payer forc ust omer specif ied
Line it em sett lement isspecif ied
Produc t allocat ion [ st andard ]
Specify alt er nat ive pa yer
Maintain messages
Dece ntr alized pro cessingr equired
Cust omer to be c reated
f or st at is t ica l purposes
Alternat ive p ayer foritem allowed
Payment block iss pec if ied
Basic data pr ocess ing forlegal co ntr ols [st an dar d]
Maint ain par tnerfun ct ions
Check if decent ralized
ha ndling is d es ired
Cu stomer is a ss ort ment
cus tome r
Maintain ma rket ing data
Mar ke ting data ar emaintained
Dun ning procedu re isspecif ied
Sales deal p ro cessing[ sta ndard]
Decentr alized proces sin gn ot requir ed
Mainta in dunning da ta
Custome r is one-t im e
cust omer
Det erm ine foreign tra de
dat a
Fore ign trade da tadetermined
Dun ning block isspecifie d
Cust omer hierarchypr ocessin g [ st andar d]
Create un loading point
Main taincor respo ndence
Corr esp ondence ismaintained
Sales summa ryproc ess ing [s tan dar d]
Create re ceiv ing point
Re ce iving point has beencr eat ed
Ass ign re ceiv ing point toan unloading point
Cust omer unloading pntshave be en maint ained
Maintain c reditma nagement data
Cred it management datadet erm ined
Bat ch sea rch s tra tegyprocessing [s tanda rd]
Cre ate depar tment
Depar tment has beencrea ted
Ass ign depar tment to arec eiving point
Class if ica tion [ classific at ionsyste m] [s tandard ]
Maintain con tac t
persons
Cont act person dat a aremain tained
Plant proc ess ing Sale s Per sonnelmas ter process ing
( Tac it) depends on
f am iliarit y with custo mersand int eract ion with cust omers
Payment car d
Set up
Conditio ns processin g
( Pur chasing)
Spec ify add re ss of
cust omer
Addr ess is spec if ied
Inter est ca lcu lat ion iss pec if ied
Plant proc es sing
Maintain ac co unt inginformat ion
Sold-to part y to becreate d
Cust omer is also vendor
Planning gr oup isspecif ied
Cu stomer- material- info
pr ocessin g [ st andard]
Maint ain account con trol
Maintain sa les data
Ship- to pa rty t o becr ea ted
Trading part ne r isspec if ied
Clearing betwee n
cust omer/ vendo rspecif ied f or automatic
pay ment s
Basic dat a pr ocessing f or
legal c ont rols [ sta nd ard]
Management of phys icalsamples
Payer to be c reated
Spe cif y company code
Compan y code isspe cif ied
Ba nk details arespe cif ied
Poss ible paymentmethods are spec if ied
Cus tome r volume re bat eagreement processing
[norma l]
Cus tomer mas te r r ecordis to be cr ea ted
Spec ify payment
tr ansac t ion d ata
Manual sample r elease
Deter mine cus tomer
functio n
Invoice re cipient is to becr eat ed
Accoun t group wit h
int ern al numbe ras signment determ ined
Define c ust omer number
Customer numb er isdet erm ined
Payment car d dat a ismaintained
Sales ar ea data ar emaintained
Mainta in payme ntinformat ion
Alt ernat ive payerspec if ic to comp an y
code s pec if ied
Cr eat e cus tomer
Cust omer mas ter recor dis c rea ted
Mater ial lis ting/exclu sio n
[ sta ndard]
Sales per sonnel ispr ocesse d
Spec ify ac count gr oup
Main tain cont rol da ta
Sample receiver to bec rea ted
Account gr oup with
ex ter nal numberassignmen t det erm ine d
Alte rnat ive pa ye r f orcust omer spec if ied
Lin e item set t lement isspecif ied
Product allocat ion [ sta ndard]
Specify alt ernat ive payer
Mainta in messages
Decen tralized p ro cessing
req uired
Cus tomer t o b e createdfor st atis tical purposes
Alt ernativ e payer foritem allowe d
Pa yment blo ck isspecif ied
Bas ic d at a processing for
lega l contr ols [s ta ndard]
Maint ain pa rt nerfunct ions
Chec k if decentr aliz edhandling is des ired
Cu stomer is assort me ntcustomer
Maint ain market ing d at a
Mar ket ing da ta aremaint ained
Dunning pr oc edure iss pec if ied
Sales deal processing
[st and ard]
Decentra lized process ing
not required
Maint ain dun nin g dat a
Custome r is one- tim ecus tomer
Det erm ine foreign trade
dat a
Fo reign t rad e dat ad eterm ined
Dunning bloc k isspecif ied
Cust omer hierar chy
pr ocessin g [ st andard]
Cr eat e unloading p oint
Maint aincorresponde nc e
Corr esponden ce ismain tained
Sales s ummary
processing [s tandard]
Cr eat e receiv ing point
Receiv ing po int has beencr eat ed
Ass ign receiv ing po int toan unloa ding point
Cust omer un loading pntsha ve been maint ained
Ma int ain creditm anagement data
Credit m an ag ement datadeter min ed
Batc h sear ch st ra tegy
proc ess ing [s tan da rd]
Create de par tmen t
Depar tmen t has be encreat ed
As sign depar tment t o ar eceiving p oint
Classific at ion [ classif icat ion
sy stem] [ standard]
Maint ain cont act
persons
Co ntact per son data a remain tained
Plant pr ocess ing Sales Personn elmast er pr ocess ing
J. A. Gulla Introduction to Enterprise Systems
Page 24 of 42
implementation guide (IMG) lists all the tables in a hierarchical manner as
shown in Figure 16. If you double click on for example Set Tolerance Limits for
Price Variation under Purchase Order, you are taken to a new window that
allows you to specify to what extent the purchase order price may deviate
from the price set in the material’s master record.
� Customization of enterprise system. Setting a parameter in the implementation
guide immediately changes the behavior of the enterprise system. The project
can easily test different prototypes by varying the parameters on a separate
development machine. When the users are satisfied with the behavior of the
prototype, the parameters can be automatically exported from the
development machine to test machines and ultimately to the production
system.
� Design and implementation documentation. The implementation guide keeps track
of which parameters have been set at which date and by whom. It documents
the design of the solution’s standardized functionality and can later be
inspected or included in design or implementation documents.
Due to the serious and hard-to-understand consequences of changing system
parameters and the intricate dependencies of parameters, only enterprise system
experts are normally given the rights to change parameters in the implementation
guide.
Figure 16. SAP’s Implementation Guide (IMG).
J. A. Gulla Introduction to Enterprise Systems
Page 25 of 42
5. Reengineering Business Processes
Business activities can be improved and optimized at the level of departments or at
the level of processes carried out across departments. Enterprise systems focus on
process optimization, and we will now use a small example to show how this is
achieved.
5.1 GGI Corporation Case
Take a company called GGI Corporation (see Figure 17). It is a mid-size company
that develops and sells electronic devices to the fishing industry. Ted in Production is
worried about his production schedule, as he has still not received some materials he
ordered two weeks ago. Today another machine broke down, and he needs the belt
to get the production line started again. He had also requested some chips that they
needed for a new prototype they are working on.
Michael is the purchasing manager of GGI. When Ted calls him and asks about the
missing materials, he is somewhat surprised. He remembers that they ordered the
chips that Ted needs, and they should normally be delivered within a week. He calls
Nigel in the warehouse, and he confirms that they received the chips about a week
ago. He is not sure why they have not been handed over to Production, but
promises to check up on it and call him back.
Michael does not remember approving any a purchase order for belts, but he fears
that the requisition has been left on Patrick’s desk. Patrick is the purchaser that
normally takes care of these items, but he has been sick for more than a week now.
However, Michael does not find any requisition for belts there and start asking other
purchasers instead. After a while it turns out that Laurie has the requisition.
Michael had mistakenly given her the requisition as he had to run for a meeting, and
Laurie just left it at her table until Patrick would be back. Michael asks her to create
a purchase order for this requisition immediately and is quite pleased with solving at
least this problem.
Kumar from the management team calls and asks Michael to buy a larger white
board for the meeting room. Michael knows that this could easily take a couple of
weeks with the normal purchasing procedures, and Kumar needs it for an important
board meeting at the end of next week. Luckily, he knows that a colleague from the
sales department happens to be in the neighborhood of the company delivering
white boards today. He calls him on his mobile and asks if he could buy this white
board and bring it with him to GGI as soon as possible. The salesman, Jonathan, is
busy the whole day, but promises to buy it the next morning and deliver it at the
headquarters at the end of the day.
J. A. Gulla Introduction to Enterprise Systems
Page 26 of 42
Figure 17. GGI’s departments
Now that the immediate problems have been solved, Michael can start going
through the purchase orders on his desks. All purchase orders have to be approved
by him before being sent to vendors. If there is missing information about the
allocation of costs, he has to contact the accounting department that will check that
the costs are filled in correctly. Also, since the accounting department monitors the
vendors, he needs to check that the vendors have an acceptable delivery history.
Laurie comes by and hands him the purchase order for the belts. There was no
information about cost allocation, she says, so she left this field blank. Patrick
usually fills this out for the Production people, but he is not present today and
Michael does not have the time to check this with Production and Accounting. He
decides to approve and send the purchase order anyway and rather take it up with
Production when the goods arrive.
He now gets a call from the warehouse. Nigel tells him that the chips have been
reserved for periodical quality control. The good part is that the checks have already
been done, and there were no problems with the chips. But the quality control
people have not yet relabeled the goods, and it is against procedure to hand out
goods that are still labeled for quality inspection. Heather in the Quality
Management team could not promise to relabel them before at the end of the next
day, as they were busy inspecting several shipments these days. Michael phones Ted
about the news, though Ted is not very happy to hear that the goods are there but
can still not be used.
Nita from Accounting is then on the phone. Michael had sent over a purchase order
yesterday and asked them to verify that they could pay the vendor according to his
terms. Nita says that they do not want this vendor to be used any more, as they have
had some bad experience with him in the past. She has tried to find other vendors,
PLANT MAINTENANCE& PRODUCTION
Request material
Make production schedule
Reserve goods
PLANT MAINTENANCE& PRODUCTION
Request material
Make production schedule
Reserve goods
PURCHASING
Allocate costs
Create purchase order
Approve purchase order
Send purchase order
PURCHASING
Allocate costs
Create purchase order
Approve purchase order
Send purchase order
ACCOUNTING
Allocate costs
Verify invoice
Evaluate vendor
Evaluate customer
ACCOUNTING
Allocate costs
Verify invoice
Evaluate vendor
Evaluate customer
QUALITY INSPECTION
Reserve goods
Inspect goods
Release/reject goods
QUALITY INSPECTION
Reserve goods
Inspect goods
Release/reject goods
WAREHOUSE
Receive goods
Deliver goods
Deliver invoice
Return goods
WAREHOUSE
Receive goods
Deliver goods
Deliver invoice
Return goodsMANAGEMENT
invoice
material
label
label
document
document
document
PLANT MAINTENANCE& PRODUCTION
Request material
Make production schedule
Reserve goods
PLANT MAINTENANCE& PRODUCTION
Request material
Make production schedule
Reserve goods
PURCHASING
Allocate costs
Create purchase order
Approve purchase order
Send purchase order
PURCHASING
Allocate costs
Create purchase order
Approve purchase order
Send purchase order
ACCOUNTING
Allocate costs
Verify invoice
Evaluate vendor
Evaluate customer
ACCOUNTING
Allocate costs
Verify invoice
Evaluate vendor
Evaluate customer
QUALITY INSPECTION
Reserve goods
Inspect goods
Release/reject goods
QUALITY INSPECTION
Reserve goods
Inspect goods
Release/reject goods
WAREHOUSE
Receive goods
Deliver goods
Deliver invoice
Return goods
WAREHOUSE
Receive goods
Deliver goods
Deliver invoice
Return goodsMANAGEMENTMANAGEMENT
invoice
material
label
label
document
document
document
J. A. Gulla Introduction to Enterprise Systems
Page 27 of 42
but the description in the purchase order was too vague for her to find similar
products from other vendors. They agree that Michael should go back to Production
and check what kind of product they need.
But Nita also has another problem. They got an invoice for some cables, and the
amount was more than 25% lower than the amount in the cable purchase order that
Michael faxed them yesterday for control. Michael calls the warehouse, which says
that they did not get the complete delivery. However, they had already talked to
Production, and they said that they were happy with the delivery and it was not
necessary to get the rest of the cables. Michael is happy that this is now cleared up
and sends an email to Nita about it. He can now finally start planning the
purchasing of materials for the production schedule that Ted sent him last week.
To summarize, the purchasing procedures at GGI Corporation above suffers from at
least the following shortcomings:
� It is difficult to track missing materials in the supply chain.
� Information gets lost on its way.
� It is difficult to ensure that the information is correct.
� Important parts of the process, like using the phone to place and track orders, are
outside the system.
� Excessive time and resources are spent trying to understand what to do and what
is going on.
� Important knowledge is tacit in people’s heads.
GGI Corporation decides to replace their existing systems with a corporate-wide
enterprise system package. The question is to what extent they can and should try to
reengineer the business with the new enterprise system.
5.2 Resource optimization
As many business departments and government agencies enjoy a substantial amount
of autonomy, it seems natural to leave many IT decisions to the departments and
measure its performance isolated from other departments or agencies. As long as the
departmental tasks are strictly defined, the key performance indicators can address
aspects that are completely under the department’s control. This is often seen as
advantageous, as it gives the department the necessary means and authority to
change their procedures and optimize the work to improve their KPIs. Such an
optimization of resources at departmental levels is referred to as resource optimization.
However, departments rarely work independently of each other. The tasks from
different departments are linked together in business processes, and there are
interfaces between different departments that have to work smoothly and efficiently.
If each department’s focus is only on its own defined tasks, these interfaces may be
neglected and the total efficiency of the whole business process may suffer. What is
good for the department may not necessarily be good for the company. In recent
J. A. Gulla Introduction to Enterprise Systems
Page 28 of 42
years, thus, most companies have abandoned the resource optimization philosophy
for a more process-oriented view of their business.
Training is an activity that often suffers from resource optimization. In many
organizations the Human Resource department is responsible for all training and
career planning. The training costs are part of their budget and affect the overall
measured performance of the department. Since the HR department does not
generate revenues, its performance tends to be measured in terms of costs and
vaguely defined value creation. Since key performance indicators (KPIs) for HR
departments often include total training costs, the department’s performance may
increase by keeping training at the lowest possible level. There may be other KPIs
that address the competence profiles of employees, for example the number of
training days allocated to each employee per year or the completion of some
competence matrix for the whole staff. But the challenge is to make sure that these
indicators actually measure something relevant for the employees’ abilities to
perform their jobs at a superior level. To set up appropriate training programs for
employees, the HR department needs to coordinate their plans intimately with other
departments. It needs to make sure that the allocated training meets the needs of
upcoming projects. It also needs to verify that the given training keeps the employee
satisfied with their situation. However, what is desired from an individual’s own
perspective may not coincide with the future needs in projects or the strategies of the
organization as a whole. In sum, it is very difficult to measure the performance of HR
activities. If the HR department is not well coordinated with other departments, they
may come up with priorities that improves their own KPIs, but are damaging to
other departments or the organization’s overall strategies.
Another example of resource optimization is found in many old production plants
with no preventive plant maintenance. Critical parts are in these cases not replaced
before they break down and the production halts. It is then important that they can
either order the parts very fast or keep sufficient stocks of critical materials at the
plant. For the plant maintenance department itself, this may look like a good
strategy. They make full use of all parts, do not need any sophisticated IT support to
monitor the use of materials, and can simplify many procedures for maintenance and
repair. The costs of a larger inventory of spare parts are often attributed to the
warehouse department anyway. What is quite serious, however, is that the strategy
may lead to complete process stops if several parts break down simultaneously. The
production process gets less predictable, as there may be surprising break-downs in
critical phases of the process. The total process costs increase and may even lead to
situations in which promised deliveries deadlines are not met. What is good for the
plant maintenance department, thus, is not necessarily good for the company.
Resource optimization leads to improved performance at the departmental level, but
may not have a positive effect on the whole organization. Due to interface problems
between departments, the result is often additional costs or less efficiency at the
company level. What is advantageous for one department may create difficulties for
others. The solution to this problem is to analyze how departments work together to
create value.
J. A. Gulla Introduction to Enterprise Systems
Page 29 of 42
5.3 Process Optimization
Let us first have a look at some definitions of business processes:
� “A group of business activities undertaken by an organisation in pursuit of a common
goal. Typical business processes include receiving orders, marketing services, selling
products, delivering services, distributing products, invoicing for services, accounting for
money received. A business process usually depends upon several business functions for
support, e.g. IT, personnel, accommodation. A business process rarely operates in
isolation, i.e. other business processes will depend on it and it will depend on other
processes” (www.itil.co.uk/online_ordering/itil_glossary.htm).
� “A collection of related, structured activities--a chain of events--that produce a specific
service or product for a particular customer or customers”
(www.ichnet.org/glossary.htm).
� “We define a business process as a collection of activities that takes one or more kinds of
input and creates an output that is of value to the customer” (Hammer & Champy
1993).
� “A process is [...] a specific ordering of work activities across time and place, with a
beginning, an end, and clearly identified inputs and outputs” (Davenport 1993).
As shown in Figure 18, a successful business process usually requires a number of
activities to be well coordinated and executed. Several departments and a number of
employees may be involved in a single process. The activities are often carried out in
a sequential manner, though there may also be parallel activities or different paths of
activities depending on the status of the process.
The objective of business process optimization is to optimize the performance of
processes rather than departments. The efficiency of departmental work is important
also in the process optimization philosophy, but we now also have to take into
account the interfaces between departments and the way activities are grouped
together to create value. In the case of HR and training we now need to analyze how
training fits into the process of preparing employees for particular projects and
estimate the additional value of having better trained people in these projects. In the
plant maintenance case we must compare two production scenarios, with and
without preventive maintenance, and analyze the strengths and weaknesses of both
scenarios. Each scenario constitutes a possible business process that includes the
costs of both plant maintenance and production activities.
Figure 18. Structure of business processes
Value to
customer
People
Resources
Common goal:Collection of ordered activities:
Value to
customer
People
Resources
Common goal:Collection of ordered activities:
J. A. Gulla Introduction to Enterprise Systems
Page 30 of 42
Capability of IT Organizational impact of the capability
Transactional IT can transform unstructured business process into
standardized transactions
Geographical IT can transfer information with rapidity and ease across large
distances, making business process independent of locations
Automation IT can reduce human labor in certain process
Informational IT can bring vast volumes of detailed information into a
business process
Analytical IT can bring complex analytical methods to bear on a process
Sequential IT enables changes in the sequence of tasks in a process, often
allowing multiple tasks to be worked on simultaneously.
Knowledge Management IT allows the capture and dissemination of knowledge and
expertise to improve the process
Tracking IT allows detailed tracking of status, inputs and outputs
Reduction of intermediaries IT can be used to connect two parties within a process that
would otherwise communicate through intermediaries
Figure 19. Capabilities of IT in reengineering (Davenport and Short 1999)
Process optimization is usually carried out as part of business process reengineering
projects:
“Business Process Reengineering is the fundamental rethinking and radical redesign of business processes to achieve dramatic improvement in critical contemporary measures of performance such as cost, quality, service and speed” (Hammer & Champy 1993).
All aspect of business processes have to be questioned in these projects:
� What activities are needed in the process?
� How should the activities by performed?
� In what order or under which conditions should the activities be performed?
� Who is responsible for the process and the various activities?
� What resources are needed to carry out the activities?
Figure 19 shows how sophisticated enterprise systems can be used to improve the
processes in these projects. They allow the organization to do things differently or
more efficiently, like automating certain tasks or keeping tracks of important
activities. However, the systems themselves do not optimize an organization’s
business processes. They only enable companies to reengineer their structures and
processes (Hammer & Champy 1993). It is up to the project to define the business
processes and figure out how enterprise systems can contribute in these new
processes.
5.4 The Balance of Reengineering and Customization
The fundamental challenge in enterprise system projects is the balancing of
reengineering and customization. Limited customization will often necessitate
extensive process reengineering in the organization to adopt the best practice
J. A. Gulla Introduction to Enterprise Systems
Page 31 of 42
processes assumed by the system. The potential benefits, cheaper implementation
and more efficient business processes, make this an attractive approach. In Vogt
(2001) it is referred to as the comprehensive success model. As Figure 20 illustrates,
though, the organizational risks are also substantially higher. The best practice
processes may not be appropriate for this particular organization, it may abandon
processes that give them an competitive edge in their segment, it may not be able to
deal with the human aspects of the changes internally, and the additional complexity
of both introducing new information technology and radically redesigning the
organization may be more than what they can cope with. A less risk-oriented
approach is based on the technological success model. The enterprise system is mostly
used to automate existing routines without changing the way people do their job.
This is easier to deal with organizationally, as the processes and structures stay the
same, and the organization can remain focused on their business tasks during the
project period. It is usually a shorter and easier project to manage with less
organizational risks and more predictable results. However, it may mean that the
enterprise system has to undergo extensive customization to support the
organization’s existing processes. This introduces additional technological risks that
have to be taken into account. Implementation and maintenance get more expensive,
and the organization may lose the benefits of adopting more efficient business
processes. There are unfortunately few guidelines for how to balance business
process reengineering with systems customization, and each project must carefully
consider to what extent they should modify their existing processes and structures
and to what extent they should customize and program the enterprise system’s
functionality.
It is worth noting that there is often a conflict between organizational risks and IT
risks. Low organizational risks tend to lead to high IT risks, and vice versa.
Figure 20. Organizational risks and returns of enterprise system projects
Return
Risk
low high
low
high
Automation
Rationalization
Reengineering
Paradigm shift
Return
Risk
low high
low
high
Automation
Rationalization
Reengineering
Paradigm shift
J. A. Gulla Introduction to Enterprise Systems
Page 32 of 42
5.5 The Reengineered GGI Supply Chain
When GGI reengineered the supply chain process, they decided to install and
customize the SAP R/3 enterprise system with the following two goals in mind:
� One central database with up-to-date integrated business data
� Faster, more reliable and more predictable supply process
The company used the Event Process Chain (EPC) formalism to model and analyze
their process (see for example Scheer &. Habermann 2000). Figure 21 shows the most
important concepts of this formalism. The diamond box on top is the event
triggering the function of approving purchase requisitions. When a new purchase
requisition is created, thus, it has to go through an approval process before any
purchase is being made. The oval to the right of the function is the organizational
unit responsible for its execution. The two event/state symbols at the bottom of the
diagram shows the two possible outcomes of the function. The XOR logical operator
says that the purchase requisition can be either approved and released, or not
approved, but not both. AND operators and OR operators are also used in these
diagrams. Every function in an EPC diagram must have a number of events/states
that trigger its execution and a number of events/states that record the possible
outcomes.
The new GGI supply process is depicted in Figure 22. It only makes use of standard
enterprise system functionality and does not require much customization. This is the
comprehensive success model with low IT risks and substantial organizational risks.
The supply chain now involves the departments of plant maintenance/production,
purchasing, accounting, and warehouse, and all data from these departments are
harmonized and integrated in one database. The quality management group is
merged with the old warehouse department. No internal paper documents are
needed any more, as departments can access the necessary documents electronically
in the common enterprise systems.
GGI decided that all procurement needs had to be recorded as purchase requisitions
that are sent electronically to the purchasing department. This makes sure that all
purchasing needs are stored for later monitoring, forces the requester to fill out the
requisition completely, and simplifies the job for purchasers. Using the same
database for materials and vendors across departments and linking the records to the
correct financial accounts, GGI also ensures that data is consistent and automates
parts of the tasks of account assignment and vendor selection. The accounting
department does not need to be involved when purchase orders are created. Since
the purchase requisitions are now complete with material numbers and prices from
the master data records, they can move the approval procedure from purchase
orders to purchase requisitions and save themselves from creating purchase orders
that are later not approved.
All purchase orders created by the purchasing department have to refer to an
approved and released purchase requisition. GGI uses standard SAP transactions for
J. A. Gulla Introduction to Enterprise Systems
Page 33 of 42
creating and sending purchase orders, as well as for receiving the goods at the
warehouse (Goods receipt processing). If the warehouse does not reject the goods,
they are placed in stock and marked for quality inspection. All received materials
have to be inspected by the warehouse before they are accepted and released for use.
The other departments can at all times verify the status of the goods and see when
they are to be released. GGI also chose to include SAP’s functionality for stock
transfers to allow plants to source goods from each other. If the goods are not to be
used by the receiving plant, a stock transfer order is created that does all the
necessary financial postings and let the goods be physically transferred to another
stock. In the old systems they did not have any procedure for this operation.
GGI has a new procedure for invoice processing that in most cases does not involve
any people outside the accounting department. Invoices do not always contain
references to purchase orders, but this is not a serious problem, since the accounting
department can search for the correct purchase order in the system themselves. As
long as the amounts in the invoice is consistent with the corresponding numbers in
the purchase order, the invoice is automatically accepted and sent to the system’s
payment program.
If there is a discrepancy, the accountants can compare the invoice online with the
goods that were ordered (purchase order) and the actual goods delivered (goods
receipt). In most cases, they get all the information they need from the system,
enabling them immediately to decide whether the invoice should be paid or not.
Figure 21. Concepts in EPC models
Control flow
AccountingAccounting
XORXORXORXOR
Approve
Purchase
requisition
Purchase
Requisition
created
Purchasing
PR approved
And released
PR not
approved
Function
Organizational unit
State/event
Logical operator (XOR, AND, OR)
Control flow
AccountingAccounting
XORXORXORXOR
Approve
Purchase
requisition
Purchase
Requisition
created
Purchasing
PR approved
And released
PR not
approved
Function
Organizational unit
State/event
Logical operator (XOR, AND, OR)
Control flow
AccountingAccounting
XORXORXORXOR
Approve
Purchase
requisition
Purchase
Requisition
created
Purchasing
PR approved
And released
PR not
approved
Function
Organizational unit
State/event
Logical operator (XOR, AND, OR)
J. A. Gulla Introduction to Enterprise Systems
Page 34 of 42
Figure 22. GGI’s reengineered supply chain process in EPC
When comparing different possible business processes, we need to analyze each of
them with respect to dimensions like
� speed,
� costs,
� resource needs,
� quality,
� reliability, and
� organizational/cultural fit.
It has to be added that the reengineered process does not necessarily only lead to
improvements. In this particular case, there are constraints in the new system that
slow down parts of the supply process. As an example, it is now not possible to call
the purchasing department directly and ask for a material to be procured. This was
an important part of the old system, since it allowed them to order materials very
fast when critical parts broke down. Now all the purchasing has to be done with
reference to an approved and released purchase requisition. This gives us a uniform
Purchase orderis transmitted
Purchaseorder processfor stock mat.
Material arrived
AND OR
Goods receiptprocessing
Goods areto be returned
Material post.to stock inqual inspect
Material isplaced in stock
Transfer ordercreated
automatically
Materials is placedinto stock
Placement instorage processing
Qualityinspection.
Material isnot accepted
Material isaccepted
XOR
AND
XOR
XOR
AND
Assigned purchaserequisition
Warehouse
Purchasing
Warehouse
Purchase orderis transmitted
Purchaseorder processfor stock mat.
Material arrived
AND AND
Goods receiptprocessing
Goods areto be returned
Material post.to stock inqual inspect
Material isplaced in stock
Transfer ordercreated
automatically
Materials is placedinto stock
Placement instorage processing
Qualityinspection.
Material isnot accepted
Material isaccepted
XOR
AND
XOR
XOR
AND
InvoiceprocessingInvoice
processing
XOR
Invoice isnot accepted
Invoice postedand releasedfor payment
XOR
Invoice isnot accepted
Invoice postedand releasedfor payment
Assigned purchaserequisition
WarehouseWarehouseAccountingAccountingAccounting
PurchasingPurchasing
WarehouseWarehouse
Invoice withreferencehas arrived
Invoice withreferencehas arrived
Invoice w/oreferencehas arrived
XORPurchase orderis transmitted
Purchaseorder processfor stock mat.
Material arrived
AND OR
Goods receiptprocessing
Goods areto be returned
Material post.to stock inqual inspect
Material isplaced in stock
Transfer ordercreated
automatically
Materials is placedinto stock
Placement instorage processing
Qualityinspection.
Material isnot accepted
Material isaccepted
XOR
AND
XOR
XOR
AND
Assigned purchaserequisition
Warehouse
Purchasing
Warehouse
Purchase orderis transmitted
Purchaseorder processfor stock mat.
Material arrived
AND AND
Goods receiptprocessing
Goods areto be returned
Material post.to stock inqual inspect
Material isplaced in stock
Transfer ordercreated
automatically
Materials is placedinto stock
Placement instorage processing
Qualityinspection.
Material isnot accepted
Material isaccepted
XOR
AND
XOR
XOR
AND
InvoiceprocessingInvoice
processingInvoice
processingInvoice
processing
XOR
Invoice isnot accepted
Invoice postedand releasedfor payment
XOR
Invoice isnot accepted
Invoice postedand releasedfor payment
XOR
Invoice isnot accepted
Invoice postedand releasedfor payment
XOR
Invoice isnot accepted
Invoice postedand releasedfor payment
Assigned purchaserequisition
WarehouseWarehouseAccountingAccountingAccountingAccountingAccountingAccounting
PurchasingPurchasing
WarehouseWarehouse
Invoice withreferencehas arrived
Invoice withreferencehas arrived
Invoice withreferencehas arrived
Invoice withreferencehas arrived
Invoice w/oreferencehas arrived
Invoice w/oreferencehas arrived
XOR
J. A. Gulla Introduction to Enterprise Systems
Page 35 of 42
way of dealing with all procurement activities, but also takes some of the flexibility
out. Similarly, all requisitions now have to include an estimate of the price, since the
approval procedure uses this price to set the correct approval level. This can be
awkward for the production staff if they do not know the price and do not have the
time or resources to check it. For materials that are already in the material master,
this is of course not a problem. The prices of these materials are automatically
loaded into the requisition. But every now and then they will need materials that are
too rare or too new to be in the material master, and they will then need to manually
enter an estimate for the requisition to be taken over to the purchasing department.
6. Managing Change
Change management deals with the project’s impact on employees and their duties
and tasks. As seen in Figure 23, there are several aspects of enterprise systems
projects that need to be considered by a change management team. The strategic
objectives underlie the whole project and reflect the way the new system should help
the organization achieve their goals. But a change of strategy may also alter the
priorities and responsibilities of the employees. The situation for the employees is
also dependent on the new business processes defined by the project. New
responsibilities are defined, and they have to work according to new procedures and
standards. The enterprise system itself will of course also have an impact on the
employees. Technical skills are needed, and new routines for system maintenance,
support and upgrading are necessary.
All these changes affect the employees’ motivation and attitudes. It is quite common
that staff morale falls as comprehensive change programs are initiated. The
uncertainty of the new systems and the new business processes, often supplemented
with a lack of understanding of the employees’ situation, creates conflicts and
distrust in the organization. If these issues are not addressed as part of the enterprise
systems project and later followed up in an appropriate manner, the organization’s
productivity and morals may stay low for years after the project. The estimated
benefits of the new system and the new processes may not be enough to compensate
for the costs and problems of dissatisfied and disillusioned employees.
Figure 23. Human concerns in reengineering projects
Technology
People
Business
processes
Strategic
objectives
Technology
People
Business
processes
Strategic
objectives
J. A. Gulla Introduction to Enterprise Systems
Page 36 of 42
Figure 24. Managed and unmanaged change in reengineering projects
The idea of change management is to engage and enable individuals to take responsibility
for realizing the new vision of their organization and the development of their own potential.
Orianda’s more practical definition is to systematically and pro-actively address the
human and organizational issues affecting the success of an enterprise systems project
(Orianda 2000). Ultimately, this should help the organization to raise the employees’
morale and thereby increase their productivity (see Figure 24).
The change management issues fall into three categories:
� Attitudes and behaviors of individuals: The project needs to address and
control the expectations of the employees, take into account their experiences, and
try to motivate them for the changes to come.
� Organizational dynamics and structures: The corporate culture and
organizational structures must be prepared for and be able to adopt the changes.
The balance of power may shift as a result of the project, and the organizational
hierarchies are usually modified as part of the reengineering effort.
� Project leadership: The way the project is managed affects the employees’
attitude towards the project. Open communication and user participation are
often beneficial to the employees’ morale and commitment.
The objectives of change management are to reduce people’s fears of the new system,
increase their benefits, and make them committed to the success of the project (see
Figure 25). Collaboration and communication are central in this process, as the
consequences and results of these projects are hard to predict in detail and the
projects impose stress and financial uncertainty. However, there are also other
means to motivate and prepare the staff. As part of the change management
activities, new incentives and personnel development programs are introduced. Staff
that get a deeper understanding of the project and are rewarded generously for their
contributions, may find it easier to accept the new situation and reach the desired
level of commitment.
Change
introduction
Managed
change
Productivity/
Morale/
commitment
Time
Unmanaged
change
Change
introduction
Managed
change
Productivity/
Morale/
commitment
Time
Unmanaged
change
J. A. Gulla Introduction to Enterprise Systems
Page 37 of 42
Figure 25. Fears and benefits in change management
The individual jobs may change as a new enterprise system is put into operation.
Some jobs will be superfluous, like the maintenance of the replaced legacy systems.
Others are similar in spirit, but are now subject to closer monitoring and control. A
manager can use the reporting functionality of enterprise systems to check up on the
performance of the employees, like their productivity and error rate. On the other
hand, most enterprise systems projects lead to a flatter organizational hierarchy and
extended employee responsibilities. Empowerment implies that the employees are
more in charge of their own tasks and have more freedom in the way they organize
and carry out these tasks.
Better educated people and a deeper understanding of process-oriented
organizations are vital to the success of the project. Among the change management
activities, training the one that usually receives the most attention. An entire
organization needs to be trained to use the new enterprise system correctly and
according to the defined business processes. Extensive training programs are set up
in the later phases of the project, and a substantial share of the project budget is
devoted to training the staff and documenting the system to be used. In the
Raytheon Aircraft (see Figure 26), about 10% of the total project budget was spent on
training. 103 courses were prepared, and the employees devoted half their working
hours to training the last few months before the system went live.
Raytheon Aircraft (completed in 2000)
SAP Project:
� $2.7 billion subsidiary of Raytheon Co.
� Project duration 1 year
� Total cost of about $55 million
� Eliminated 30 legacy systems
� Integrated 4 manufacturing sites and 15
airport service stations
Training program:
� $5.5 million on training employees
� 5,000 employees trained for 20
hours/week months before go-live date
� 150 go-live managers worked full-time
on SAP before go-live date
� 103 courses
Figure 26. The Raytheon Aircraft project (Haigh 2000).
Knowledge
Intelligence
Acceptance
Commitment
People fears People benefits
Knowledge
Intelligence
Acceptance
Commitment
People fears People benefits
J. A. Gulla Introduction to Enterprise Systems
Page 38 of 42
7. Benefits and Problems
7.1 Benefits of Enterprise Systems
The potential benefits of enterprise systems depend on the way they are employed to
improve the business processes. As enablers of successful business reengineering
projects, they help the organizations
o save money
o keep their business data consist, current and available,
o speed up business processes, and
o improve the quality and reliability of the processes.
Detailed analyses of the financial consequences of these benefits are however rare.
7.2 Why Projects Fail
There have been numerous studies of failed ERP projects in recent years. The results
in Figure 27 are based on extensive interviews with CEOs of large companies. What
is clear from these graphs is the importance of change management and strong
leadership in enterprise systems projects. Employees’ resistance to change is the
single most important barrier to successful results. Another problem is that users
often have unrealistic expectations to the new enterprise system. But the interviews
also emphasize that the top management team needs to commit themselves properly
if the project is to succeed. Both this survey and others confirm that pure IT
problems rarely cause an enterprise system project to fail.
Figure 27. Top ten barriers to success (Deloitte & Touche Consulting Group 1995).
Vogt (2001) lists a number of potential problems in these projects:
� Reliability: After implementing an enterprise system, the organization may
completely depend on this one system. If the system goes down, the business
impact may be severe.
36
41
43
44
44
46
54
65
72
82
0 20 40 60 80 100
IT perspective not integrated
No horizontal process view
No change management program
Project team lacked skills
Scope expansion/uncertainty
Uncompelling change case
Poor project management
Unrealistic expectations
Lack of management commitment
Resistance to change
J. A. Gulla Introduction to Enterprise Systems
Page 39 of 42
� Big-bang seduction: Since enterprise systems are not built to co-exist with
competing systems, it is tempting to introduce the system in a single strike. These
so-called big-bang approaches are rarely successful, and a better strategy may be
to introduce the system in a number of waves, focusing on certain locations
and/or certain modules at each time.
� Overeager customization: Too much customization is expensive and often leads
to unstable and buggy software. It is usually preferable to keep customization to
a minimum and rather change the business processes to fit the standard software.
� Cultural hurdle: Even though there are many advantages with monolithic
systems, employees often find it difficult to accept the new system. They face a
changing environment, inconvenient re-training, and a sense of uncertainty.
The graph in Figure 29 illustrates the problem of overeager customization. With
extensive customization the total implementation costs rise dramatically. If the
extent of customization increases by 5%, the total implementation costs may easily
get 5 times higher.
Figure 28. Costs of customization (adapted from Laudon & Laudon 1998)
Vogt has also looked into costs that are often not very apparent when the project is
planned, but can cause problems later in the project or after the project is finished.
These are:
� Training: Employees must be retrained to use the new, different system as
efficiently as they used the old one.
� Transition: This involves data conversion from the old systems, population of
the new system, integration with other applications, and intensive systems tests.
� Prolonged schedule: Unanticipated difficulties are always encountered and can
sometimes lead to unexpected high consulting fees.
Extent of customization (% of total lines of code changed)
Total
implementation
costs
1
2
3
4
5
6
7
1 2
3
4 5
Extent of customization (% of total lines of code changed)
Total
implementation
costs
1
2
3
4
5
6
7
1 2
3
4 5
J. A. Gulla Introduction to Enterprise Systems
Page 40 of 42
� Sparing the best: It is necessary that the best people are assigned to the
enterprise systems project, even if that elite will not be available any more to
their usual work.
� Delayed ROI: Due to the complexities and uncertainties of the new system, the
employees are not going to use it efficiently until after several months of
deployment.
The costs of the issues above tend to be underestimated when new enterprise
systems projects are planned.
8. The Future of Enterprise Systems
The earliest enterprise systems, the pure ERP systems, only addressed the backbone
operations of the companies. It was common to employ third-party products or
internally developed software for parts of high strategic importance. The ERP
systems were isolated to the company alone and could only support processes that
were internal to the company. They also had a very strong focus on operative data
and were not always providing analyses that helped managers to make the right
decisions.
In recent years the enterprise systems have been extended to include more
components or facilities for
� decision support and
� extra-company collaboration.
A wide range of business intelligence (BI) products help the managers analyze
operative data from ERP systems and make the appropriate decisions. As ERP
systems structure business data according to transactional needs, many
organizations now employ data warehouses that reorganize the data according to
analytical needs. The data warehouses and other strategic components (like the
Strategic Enterprise Management component of SAP) supply the managers with up-
to-date analyses that reflect the way they want to monitor and control the business.
Balanced scorecard solutions are often delivered as part of these BI tools (see Kaplan
& Norton 1996).
An exciting development in this market is the shift from backbone operations to
open collaborative environments that help the company coordinate their tasks with
other companies or customers (see Figure 29). Business-to-business systems, market
places and portals all bring the company’s products and services to a wider audience
over the Internet.
As before, however, it is up to the organization to work out how these new
technologies can be exploited to give them a competitive advantage. The analysis of
business processes is today crucial in any enterprise system project.
J. A. Gulla Introduction to Enterprise Systems
Page 41 of 42
Figure 29. From backbone operations to collaboration
References
Accenture (2001). Accenture ERP Market Insight, July 2001.
Bancroft, N. H., H. Seip, and A. Sprengel (1998). Implementing SAP R/3: How to introduce a
large system into a large organization. Second edition. Manning Publications.
Carlsen, S. (1998). Action Port Model: A Mixed Paradigm Conceptual Workflow Modeling
Language. In Proceedings of the Third International Conference on Cooperative
Information Systems, August 1998, New York.
Curran, T. and G. Keller (1998). SAP R/3 Business Blueprint: Understanding the Business Process
Reference Model. Prentice Hall, 1998.
Davenport, T. H. (1993). Process Innovation: Reengineering Work Through Information
Technology. Harvard Business School Press. Ernst & Young.
Davenport, T. H. and E. J. Short (1999). The New Industrial Engineering: Information
Technology and Business Process Redesign. Sloan Management Review, Volume 31, No.
4, Summer 1999.
Deloitte & Touche Consulting Group (1995). The Top Ten Barriers to Success. Survey of
CIO’s.
Gulla, J. A. and T. Brasethvik (2000). On the Challenges of Business Modeling in Large-Scale
Reengineering Projects. In Proceedings of the 4th International Conference on Requirements
Engineering (RE’2000), Schaumburg, June, pp. 17-26.
Gulla, J. A. and R. Mollan (1999). Implementing SAP R/3 in a Multi-Cultural Organization.
Venice, 1999.
Haigh, D. (2004). Enterprise Resource Planning. The Pennsylvania State University.
Hammer, M. and J. Champy (1993). Reengineering the Corporation. A Manifesto for Business
Revolution. Harperbusiness.
Hiquet, B. D. and A. F. Kelly (1998). SAP R/3 Implementation Guide: A Manager’s Guide to
Understanding SAP. Macmillan Technical Publishing.
Accounting
WorldBusiness PartnersEnterprise group
Internet
Extranet
Intranet
Enterprise
Production
Logistics
Human Resources
Sales
Business warehouse
B2B procurement
Strategic Enterprise
Management
Customer Relationship
Management
Knowledge
warehouse
Collaborative engineering
E-recruiting
Electronic bill
presentment &
payment
Comprehensiv e-business
solution
Market places
Portals
Collaborative
forecasting
Collaboration
Accounting
WorldBusiness PartnersEnterprise group WorldBusiness PartnersEnterprise group
Internet
Extranet
Intranet
Enterprise
Production
Logistics
Human Resources
Sales
Business warehouse
B2B procurement
Strategic Enterprise
Management
Customer Relationship
Management
Knowledge
warehouse
Collaborative engineering
E-recruiting
Electronic bill
presentment &
payment
Comprehensiv e-business
solution
Market places
Portals
Collaborative
forecasting
Collaboration
J. A. Gulla Introduction to Enterprise Systems
Page 42 of 42
Kaplan, R. S. and D. P. Norton (1996). The Balanced Scorecard: Translating Strategy into
Action. Harvard Business School Press.
Kretschmer, R. and W. Weis (1996). Developing SAP’s R/3 Applications with ABAP/4. Sybex.
Laudon, K. C. and J. P. Laudon (1998). Management Information Systems: New Approaches to
Organization & Technology. Prentice Hall.
Lozinsky, S. (1998). Enterprise-Wide Software Solutions: Integration Strategies and Practices.
Addison-Wesley.
Mizrahi, I. (1998). Business Reengineering With Standard Software.
Orianda (2000). Change Management for ERP. www.orianda.com.
Robsen, W. (1997). Strategic Management & Information Systems. Second Edition. Financial
Times/Prentice Hall.
Rosemann, M. (2003). Configuration of Enterprise Systems Reference Models.
Scheer, A-W. and F. Habermann (2000). Making ERP a Success. Communications of the ACM,
April 2000, Vol. 43, No. 4, pp. 57-61.
Sonqini, M. L. (2004). ERP Users Bristle at Upgrade Pressure, Maintenance Costs.
ComputerWorld, February 16, 2004
Stein, A. and P. Hawking (2002). Business Improvement and ERP System. ERP Research Group,
Victoria University, Australia.
van Erdingen, Y. M., J. van Hillegersberg, and E. Waarts (2000). ERP Adoption by European
Midsize Companies. Communications of the ACM, April 2000, Vol. 43, No. 4, pp. 27–31.
Vogt, C. (2001). Intractable ERP: A Comprehensive Analysis of Failed Enterprise-Resource-
Planning Projects.