Introduction to Enterprise Systems - NTNU · J. A. Gulla Introduction to Enterprise Systems Page 2...

J. A. Gulla Introduction to Enterprise Systems

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


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


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


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.


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






5 2

3

1

4

Sales

ManufacturingWarehouse

Fullfilment

A/R

Asset

management

G/L

Purchasing

Reporting

A/P






5 2

3

1

4

Sales

ManufacturingWarehouse

Fullfilment

A/R

Asset

management

G/L

Purchasing

Reporting

A/P







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.


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.


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


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


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


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


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.


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


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


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



APPLICATION processes data and

delivers result to USER INTERFACE


delivers result to USER INTERFACEDATABASE delivers data to

APPLICATION

DATABASE delivers data to

APPLICATION

APPLICATION requests retrieval

of customer data from DATABASE



Tier 1 Tier 2 Tier 3



#4711



#4711



ACME



ACME

Customer

database

Customer

database

Clientsrun program partUSER INTERFACE

Client/serverruns program partAPPLICATION

Serverruns program part

DATABASE






delivers result to USER INTERFACE


delivers result to USER INTERFACEDATABASE delivers data to

APPLICATION

DATABASE delivers data to

APPLICATION





Tier 1 Tier 2 Tier 3


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.


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 tables

Master

data tablesMaster

data tablesMaster

data tablesMaster


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


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.


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)


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


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


process in HAE:



- responsibilities


Rostock

purchasing

organization

Rostock

purchasing

organization

Create/change/display

purchase order


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 analysis




Stock overview

TasksJob

Rostock

purchasing

Rostock

purchasing

Fit analysis

Job analysis


process in HAE:



- responsibilities



process in HAE:



- responsibilities


Rostock

purchasing

organization

Rostock

purchasing

organization


purchase order


purchase order

HROHRO

RSK1RSK1

CCMCCM

HRO1HRO1

RSK2RSK2

HROHRO

RSK1RSK1

CCMCCM

HRO1HRO1

RSK2RSK2

SAP organizational structureSAP transactions

HAE site organizationHAE business processes

Purchasing


Purchasing analysis




Stock overview

Purchasing


Purchasing analysis




Stock overview

TasksJob

Rostock

purchasing

Rostock

purchasing

Fit analysis

Job analysis


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


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


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


Surround package


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


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


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


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.


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


Request material


Reserve goods

PURCHASING

Allocate costs

Create purchase order

Approve purchase order

Send purchase order

PURCHASING

Allocate costs



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


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


Request material


Reserve goods


Request material


Reserve goods

PURCHASING

Allocate costs



Send purchase order

PURCHASING

Allocate costs



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


QUALITY INSPECTION

Reserve goods

Inspect 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


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


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.


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:


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


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


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


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


XORXORXORXOR

Approve

Purchase

requisition

Purchase

Requisition

created

Purchasing

PR approved

And released

PR not

approved

Function

Organizational unit

State/event


Control flow


XORXORXORXOR

Approve

Purchase

requisition

Purchase

Requisition

created

Purchasing

PR approved

And released

PR not

approved

Function

Organizational unit

State/event



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



Material arrived

AND AND






automatically



Qualityinspection.


Material isaccepted

XOR

AND

XOR

XOR

AND

InvoiceprocessingInvoice

processing

XOR

Invoice isnot accepted

Invoice postedand releasedfor payment

XOR




WarehouseWarehouseAccountingAccountingAccounting

PurchasingPurchasing

WarehouseWarehouse

Invoice withreferencehas arrived


Invoice w/oreferencehas arrived

XORPurchase orderis transmitted


Material arrived

AND OR






automatically



Qualityinspection.


Material isaccepted

XOR

AND

XOR

XOR

AND


Warehouse

Purchasing

Warehouse



Material arrived

AND AND






automatically



Qualityinspection.


Material isaccepted

XOR

AND

XOR

XOR

AND

InvoiceprocessingInvoice

processingInvoice

processingInvoice

processing

XOR



XOR



XOR



XOR




WarehouseWarehouseAccountingAccountingAccountingAccountingAccountingAccounting

PurchasingPurchasing

WarehouseWarehouse







XOR


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


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


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


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


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


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.


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


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.

Introduction to Enterprise Systems - NTNU · J. A. Gulla Introduction to Enterprise Systems Page 2...

Documents

Transcript of Introduction to Enterprise Systems - NTNU · J. A. Gulla Introduction to Enterprise Systems Page 2...