Introduction to Enterprise Systems

(1)

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

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

(2)

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

(3)

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

(4)

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.

(5)

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 system Warehouse system 1 2 Fullfilment system Fullfilment system 1 2 4 A/R system A/R system 1 2 4 G/L system G/L system 1 4 5 Reporting system Reporting system 1 4 5 Sales system Sales system 1 2 4 Purchasing system Purchasing system 1 3 4 A/P system A/P system 1 3 Asset system Asset system 1 5 Manufacturing system Manufacturing 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 system Warehouse system 1 2 Fullfilment system Fullfilment system 1 2 4 A/R system A/R system 1 2 4 G/L system G/L system 1 4 5 Reporting system Reporting system 1 4 5 Sales system Sales system 1 2 4 Purchasing system Purchasing system 1 3 4 A/P system A/P system 1 3 Asset system Asset system 1 5 Manufacturing system Manufacturing system 1 3 4 5

1: product/material master information 2: customer master information 3: vendor master information 4: financial master information 5: organizational master information

5 2 3 1 4 Sales Manufacturing Warehouse Fullfilment A/R Asset management G/L Purchasing Reporting A/P

(6)

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.

(7)

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.

(8)

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

(9)

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

(10)

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 Plant Plant Purchasing group Purchasing group Purchasing organization Purchasing organization Sales organization Sales organization Distribution channel Distribution channel Division Division Client Client Business area Business

area Profit center/

Cost center Profit center/ Cost center Controlling area Controlling area Charts of accounts Charts of accounts Company code Company code Plant Plant Purchasing group Purchasing group Purchasing organization Purchasing organization Sales organization Sales organization Distribution channel Distribution channel Division Division Client Client Business area Business

area Profit center/

Cost center Profit center/ Cost center Controlling area Controlling area

(11)

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

(12)

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.

(13)

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

(14)

information or run a transaction in the system, he sends a request to the application server. When the application server has carried out the request, it returns the results to the user interface part.

Application server: The application server at tier 2 runs all the modules of the

enterprise system. Transactions like Create purchase order in MM and Post invoice in FI are run on this server, but access the underlying data from the database server. Requests to the database server are sent, and the results are processed and prepared for being sent to the user interface part. Third party- or user-developed software can be added at this tier, as long as it is written according to the standards of the enterprise system environment. In SAP’s case it means that it must be written in ABAP/4 and use the BAPI interfaces defined.

Database server: The database server is accessed and updated constantly and is

often distributed among multiple machines. The logical mapping of data between application modules and database is supported by a sophisticated data dictionary.

Smaller enterprise systems installations can be implemented in a two-tier environment. Very large and complex installations may use separate application servers for separate groups of modules. Whereas financial accounting runs on one applications server, for example, another server is used for logistics and human resources.

Figure 8. A three-tier enterprise system architecture

3.2 Data Repository

All the data in an enterprise system is arranged in accordance with a central data dictionary that defines all the system’s entities and their attributes and relationships.

User requests from PC: Show report of customer #4711

User requests from PC: Show record of customer ACME

Customer database Clients

run program part USER INTERFACE

Client/server runs program part

APPLICATION

Server runs program part

DATABASE

USER INTERFACE request customer data from APPLICATION

APPLICATION processes data and delivers result to USER INTERFACE

APPLICATION processes data and

delivers result to USER INTERFACE DATABASE delivers data to

APPLICATION

DATABASE delivers data to APPLICATION

APPLICATION requests retrieval of customer data from DATABASE

Tier 1 Tier 2 Tier 3

User requests from PC: Show report of customer #4711

User requests from PC: Show record of customer ACME

User requests from PC: Show record of customer ACME Customer database Customer database Clients

run program part USER INTERFACE

Client/server runs program part

APPLICATION

Server runs program part

DATABASE

USER INTERFACE request customer data from APPLICATION

APPLICATION processes data and delivers result to USER INTERFACE

APPLICATION processes data and

delivers result to USER INTERFACE DATABASE delivers data to

APPLICATION

DATABASE delivers data to APPLICATION

APPLICATION requests retrieval of customer data from DATABASE

(15)

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.

(16)

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 tables Transaction

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 tables Transaction

data tables Master data tablesMaster data tablesMaster data tablesMaster data tables Transaction

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 tasks Generic tasks

Generic tasks Transaction codesTransaction codesTransaction codes Legal range of

object values Job (profile)

Generic tasks Generic tasks Generic tasksGeneric tasksGeneric tasks

Generic tasks Transaction codesTransaction codesTransaction codesTransaction codesTransaction codesTransaction codes Legal range of

(17)

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.

(18)

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) Implementation level (software) Model level (Process model) Application level (real world) Implementation level (software) Model level (Process model)

(19)

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 Development system Test system Production system Use object Transport if OK Transport if OK Release object Reserve object Test object Development system Test system Production system Use object Transport if OK Transport if OK

(20)

4.1 Fit Analysis

It is important to understand that enterprise system projects do not specify system requirements as independently as many other projects. In the requirements engineering phase we investigate how to map the desired processes and structures of the company onto the functionality offered by the enterprise system. Ideally, all the needs can be identified and fulfilled simply by customizing the modules that are needed. In most cases, however, the needs are not clear and it is not obvious how to relate them to the enterprise system functionality.

From an enterprise system’s point of view, an organization can be described in terms of processes, organizational structures and jobs. Figure 13 shows how each of these parts are involved in a fit analysis process that tries to work out an optimal match of wanted and offered functionality. The example data used in the figure comes from a fertilizer plant in Rostock, Germany, which is part of a pan-European fertilizer company. When the system is to be customized to the needs of the organization, the project needs to examine how the desired business processes can be supported by the transactions available in the enterprise system. In our example from Rostock, the desired overall business processes had already been specified beforehand as the result of a reengineering activity in the company. These took into account best practice reports from the industry, key performance indicators needed by the management, and various other organizational and legal constraints. The challenge of the project was to decide which transactions to use, and how these were to be customized or possibly changed. If the needs were not covered by the system, the project had to decide whether the requirements had to be modified or additional programming was called for.

Figure 13. Analyzing jobs, processes and organizational structures

Harmonized purchasing process in HAE: - best practice processes - key performance indicators - responsibilities

- legal considerations

Harmonized purchasing process in HAE: - best practice processes - key performance indicators - responsibilities - legal considerations Rostock purchasing organization Rostock purchasing organization Create/change/display purchase order Create/change/display purchase order HRO HRO RSK1 RSK1 CCM CCM HRO1_HRO1 RSK2 RSK2

SAP organizational structure SAP transactions

HAE site organization HAE business processes

Purchasing Purchasing contracts Purchasing analysis Request for quotation Creation/rel. – requisition Approval of requisition Stock overview Purchasing Purchasing contracts Purchasing analysis Request for quotation Creation/rel. – requisition Approval of requisition Stock overview Tasks Job Rostock purchasing Rostock purchasing Fit analysis Job analysis Harmonized purchasing process in HAE: - best practice processes - key performance indicators - responsibilities

- legal considerations

Harmonized purchasing process in HAE: - best practice processes - key performance indicators - responsibilities - legal considerations Rostock purchasing organization Rostock purchasing organization Create/change/display purchase order Create/change/display purchase order HRO HRO RSK1 RSK1 CCM CCM HRO1_HRO1 RSK2 RSK2 HRO HRO RSK1 RSK1 CCM CCM HRO1_HRO1 RSK2 RSK2

SAP organizational structure SAP transactions

HAE site organization HAE business processes

Purchasing Purchasing contracts Purchasing analysis Request for quotation Creation/rel. – requisition Approval of requisition Stock overview Purchasing Purchasing contracts Purchasing analysis Request for quotation Creation/rel. – requisition Approval of requisition Stock overview Tasks Job Rostock purchasing Rostock purchasing Fit analysis Job analysis

(21)

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

(22)

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

Tolerate mismatch Tolerate mismatch Modify business processes Modify business processes Customize package Customize package Map of discrepancies Prioritized business requirements Capabilities of the standard package Unmet needs Surplus to needs Surround package with extra functionality

Surround package with extra functionality

Tolerate mismatch Tolerate 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

(23)

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) Specif y ad dress of

cus t omer

Add res s is s pec ified

I nt erest c alculat ion issp ec ified

Plant pro ces sing M aint ain ac count ing

inf orm at ion Sold- t o par t y t o be

create d

Cust om er is als o v endor

Planning group isspecif ied

Cust om er- m aterial- info proc ess ing [ s t an dar d] M ainta in account c ont rol

M aint ain sa les dat a Ship-t o p art y t o be

c reat ed

T rading partn er is s pec if ied

Clear ing bet we en cus to mer/ v end or specif ied for aut om aticpay me nt s

Basic da ta pr ocessin g forlegal cont r ols [ st andar d] M anagem ent of physic al

samp les Payer t o be cr eat ed

Spec ify company code

Com pany code isspecifie d

Ban k det ails are specifie d

Pos sible p aym ent m et hods ar e specif ied

Cust omer volum e r ebat e agr eem e nt proces sin g[ nor mal] Cus tom er m as ter re co rdis t o be c reated

Specify paym ent t ransact ion d ata

M anual sa mple r elea se Det erm ine cu st om erf unct ion

I nvoice r ec ipient is t o be c reat ed

Acc ount g roup with inte rn al num ber ass ignm en t det erm ine d

Def ine cus t ome r num ber Cus tom er num ber is det er mined

Paym ent c ard dat a is ma int ained

Sales area dat a are ma int ained

M ain ta in paym ent info rm at ion

Alt ernativ e pay er specif ic t o c om pany code s pec ifie d

Cr eat e c ust om er Cus to mer m as te r r ecord

is c reat ed

M at erial list ing/ ex clus ion[ st andard ] Sales pe rs onnel isp ro ces sed

Specif y ac co unt gr oup

M ainta in c ont rol da ta Sam ple r ec eive r to be

create d

Ac count gr oup wit h ex ter nal num ber as signme nt d eterm ined

Alt er nat ive payer f or c ust om er specif ied

Line it em sett lem ent isspecif ied

Produc t alloc at ion [ st andard ] Specify alt er nat ive pa yer

M aint ain m ess ages

Dece ntr alized pro ces sing r equired

Cust om er t o be c reat ed f or st at is t ica l purposes

Alternat iv e p ayer f or it em allowed

Paym ent block iss pec if ied

Basic data pr oc ess ing for legal co ntr ols [ st an dar d] Maint ain par tner

f un ct ions

Check if dec ent raliz ed ha ndling is d es ired

Cu st omer is a ss ort ment cus t om e r

Maint ain ma rket ing data

M ar ke ting dat a ar e m aint ained

Dun ning proc edu re isspecif ied

Sales deal p ro ces sing[ sta ndard] Decent r aliz ed proces sin g

n ot requir ed

M ainta in dunning da ta Cust ome r is one-t im e

c ust om er

Det erm ine f oreign t ra de dat a

Fore ign t rade da ta det ermined

Dun ning block iss pecifie d

Cust om er hierarchy pr ocessin g [ st andar d] Creat e un loading point

M ain tain cor respo ndenc e

Corr esp ondence ism aint ained

Sales s um ma ry proc ess ing [ s t an dar d]

Creat e re ceiv ing point Re ce iving point has beencr eat ed Ass ign re ceiv ing point t o an unloading point

Cust om er unloading pnt s have be en m aint ained

M aint ain c redit ma nagem ent dat a

Cred it managem ent datadet erm ined

Bat ch sea rch s t ra tegy proces sing [ s t anda rd] Cre ate depar tm ent Depar t m ent has beenc rea ted Ass ign depar t m ent t o a rec eiving point

Class if ica tion [ clas sific ationsy ste m] [ s t andard ] Maint ain con tac t

pers ons

Cont act pers on dat a are m ain tained Plant proc ess ing m as ter proc ess ingSale s Per sonnel

( Tac it) depends on f am iliarit y wit h custo mers and int eract ion wit h c ust om ers

Paym ent car d Set up

Conditio ns processin g ( Pur chasing) Spec if y add re ss of

cust om er

Addr ess is spec if ied

I nter est ca lcu lation is s pec if ied

Plant proc es sing M aint ain ac co unt inginf orm at ion

Sold-t o part y t o be create d

Cust om er is also v endor

Planning gr oup is specif ied

Cu st omer- mat erial- info pr ocessin g [ st andard] Maint ain acc ount con trol

M aint ain sa les dat a Ship- t o pa rt y t o be

cr ea ted

Trading part ne r iss pec if ied

Clearing betwee n c ust om er/ vendo r specif ied f or aut omat icpay m ent s

Basic dat a pr ocessing f or legal c ont rols [ sta nd ard] M anage ment of phys icals amples

Payer to be c reat ed

Spe cif y c om pany code

Com pan y c ode is spe cif ied

Ba nk det ails arespe cif ied

Poss ible pay m ent m et hods are s pec if ied

Cus t om e r v olume re bat e agreem ent proc es sing[ norm a l] Cus tom er m as te r r ecord

is t o be cr ea ted

Spec ify paym ent t r ans ac t ion d ata

M anual sam ple r elease Det er mine c us tom er

f unctio n

Inv oice re cipient is to be cr eat ed

Acc oun t group wit h int ern al num be r as signment det erm ined

Def ine c ust om er number Custo m er numb er isdet erm ined

Paym ent car d dat a ismaint ained

Sales ar ea dat a ar e maint ained

Mainta in pay me ntinform at ion

Alt ernat ive payer s pec if ic to comp an ycode s pec if ied

Cr eat e cus t omer Cust om er m as t er recor dis c rea ted

Mat er ial lis ting/ exclu sio n [ sta ndard]

Sales per sonnel is pr ocesse d

Spec if y ac count gr oup

M ain tain cont rol da ta Sam ple receiv er to be

c rea ted

Ac count gr oup wit h ex t er nal num ber assignm en t det erm ine d

Alte rnat ive pa ye r f orc ust om er spec if ied

Lin e item s et t lem ent is s pecif ied

Product allocat ion [ sta ndard] Specif y alt ernat ive pay er

Mainta in m essages

Decen tralized p ro ces sing req uired

Cus tom er t o b e creat ed for st atis tical purpos es

Alt ernativ e pay er f oritem allowe d

Pa ym ent blo ck is specif ied

Bas ic d at a proces sing f or lega l cont r ols [s ta ndard] M aint ain pa rt nerfunct ions

Chec k if decentr aliz ed handling is des ired Cu st om er is ass ort me nt

cust om er

M aint ain mark et ing d at a

M ar ket ing da ta arem aint ained

Dunning pr oc edure is s pec if ied

Sales deal proces sing [ st and ard] Decent ra lized proc ess ing

not required

M aint ain dun nin g dat a Cust ome r is one- tim e

c us t om er

Det erm ine f oreign t rade dat a

Fo reign t rad e dat ad eterm ined

Dunning bloc k is specif ied

Cust om er hierar chy pr ocessin g [ st andard] Cr eat e unloading p oint

M aint ain corresponde nc e

Corr esponden ce is m ain tained

Sales s um mary proces sing [ s t andard]

Cr eat e rec eiv ing point Receiv ing po int has been cr eat ed Ass ign receiv ing po int t oan unloa ding point

Cust om er un loading pnt sha ve been m aint ained

Ma int ain credit m anage ment dat a

Credit m an ag em ent data det er min ed

Batc h s ear ch st ra tegy proc ess ing [ s t an da rd] Creat e de par t m en t Depar t m en t has be en creat ed As sign depar tm ent t o ar ec eiving p oint

Clas sific ation [ classif icat ion sy st em] [ standard] M aint ain cont act

pers ons

Co ntact per son data a rem ain tained Plant pr ocess ing Sales Pers onn el

(24)

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.