Introduction to Enterprise Systems

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: Jon.Atle.Gulla@idi.ntnu.no 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 Page 1 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 Page 2 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 onethird 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). Page 3 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 errorprone 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. Page 4 of 42

Warehouse Warehouse system system 1 2 Sales Sales system system 1 2 4 1: product/material master information 2: customer master information 3: vendor master information 4: financial master information 5: organizational master information Fullfilment Fullfilment system system 1 2 4 Manufacturing Manufacturing system system 1 3 4 5 Purchasing Purchasing system system 1 3 4 A/R system A/R system 1 2 4 G/L system G/L system 1 4 5 A/P system A/P system 1 3 Asset system Asset system 1 5 Reporting system Reporting system 1 4 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. Sales Warehouse Manufacturing Fullfilment 1 Purchasing 5 2 1: product/material master information 2: customer master information 3: vendor master information 4: financial master information 5: organizational master information A/R 4 3 A/P Asset management G/L Reporting Figure 3. An integrated data-driven enterprise system (adapted from Bancroft et al. 1998) Page 5 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. Page 6 of 42

Company data (at end of project): Chemical industry sector Revenues 39.7 billion NOK ($$$$) 6,400 employees Represented in 9 countries End-user training: 245 instructors trained 3,971 end-users trained 1,421 user procedures 58 training courses Project data: Solution: SAP R/3 v3.0f (10 modules) $ 126 million budget Duration 4 years More than 500 people involved 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. Page 7 of 42

60000 50000 40000 $M 30000 20000 10000 0 1999 2000 2001 2002 2003 2004 Implementation Consulting Operations management Support Training 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 Page 8 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 Page 9 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. Client Client Charts of Charts of accounts accounts Controlling Controlling area area Business Business area area Company Company code code Profit center/ Profit center/ Cost center Cost center Sales Sales organization organization Plant Plant Purchasing Purchasing organization organization Distribution Distribution channel channel Purchasing Purchasing group group Division Division Figure 7. Some organizational concepts in SAP R/3 Page 10 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 Page 11 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. Page 12 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 Page 13 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 userdeveloped 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. Tier 1 Tier 2 Tier 3 Clients Client/server Server run program part runs program part runs program part USER INTERFACE APPLICATION DATABASE User requests from PC: Show report of customer #4711 User requests from PC: Show record of customer ACME Customer database USER INTERFACE request USER INTERFACE request customer data from APPLICATION customer data from APPLICATION APPLICATION requests retrieval APPLICATION requests retrieval of customer data from DATABASE of customer data from DATABASE APPLICATION processes data and APPLICATION processes data and delivers result to USER INTERFACE delivers result to USER INTERFACE DATABASE delivers data to DATABASE delivers data to APPLICATION APPLICATION 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. Page 14 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. Page 15 of 42

Master Master System Master data data tables data tables configuration data tables tables Master Master Control Master data data tables data data tables tables tables R/3 Applications Master Master Master Master data data tables data data tables tables data tables Master Master Transaction Master data data tables data data tables tables data tables 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. Legal range of object values Job (profile) Generic Generic Generic tasks tasks tasks Transaction Transaction codes codes codes Figure 10. User authorization objects 3.4 Implementation Environment Page 16 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. Page 17 of 42

Application level (real world) Model level (Process model) Implementation level (software) 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. Page 18 of 42

Reserve object Development system Test object Release object Transport if OK Test system Production system Use object Transport if OK 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. Page 19 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. Fit analysis HAE business processes Harmonized purchasing Harmonized purchasing process in HAE: process in HAE: - best practice processes - best practice processes - key performance indicators - key performance indicators - responsibilities - responsibilities - legal considerations - legal considerations HAE site organization Rostock Rostock purchasing purchasing organization organization Job analysis Job Tasks HRO HRO Rostock Rostock purchasing purchasing Purchasing Purchasing Purchasing contracts Purchasing contracts Create/change/display Create/change/display purchase order purchase order CCM CCM HRO1 HRO1 Purchasing analysis Purchasing analysis RSK2 RSK2 RSK1 RSK1 Request for quotation Request for quotation Creation/rel. requisition Creation/rel. requisition SAP transactions SAP organizational structure Approval of requisition Approval of requisition Stock overview Stock overview Figure 13. Analyzing jobs, processes and organizational structures Page 20 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). Page 21 of 42

Surplus to needs Tolerate Tolerate mismatch mismatch Prioritized business requirements Capabilities of the standard package Map of discrepancies Modify business Modify business processes processes Customize Customize package package Unmet needs Surround package Surround package with extra functionality with extra functionality 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 Page 22 of 42

( Tac it) depends on Specify address of f amiliarit y with custo mers customer and int eract ion with cust om ers Conditions proc es sing ( Pur chasing) Address is spec ified Interest c alculat ion is sp ec ified Plant pro cessing Maintain ac count ing informat ion Sold- to par ty to be create d Cust omer is als ovendor Planninggroup is specified Cust omer- material- info process ing [standar d] Mainta inaccount c ont rol Maintain sales data Ship-t o p art y t o be created Trading partner is s pecified Clear ing between cus to mer/vend or specif ied for automatic payment s Basic data pr ocessing for legal contr ols [st andar d] M anagem ent of physical samp les Payer to be cr eat ed Spec ify company code Company code is specifie d Ban k det ails are specifie d Possible p aym ent methods ar e specif ied Cust omer volume r ebate agr eem e nt proces sin g [ nor mal] Plant proc essing Cus tom er m as ter re co rd is t obe created Specify payment t ransaction data Manual sample r elease Det ermine cust omer funct ion Invoicer ecipient is t obe c reated Account g roup with inte rn al num ber assignmen t det ermine d Def ine customer number Cus tomer number is det er mined Payment c ard data is maint ained Sales area dat a are maint ained M ain ta inpaym ent info rmat ion Alt ernativ epayer specif ic t o company code spec ifie d Cr eat e c ust omer Cus tomer mas ter r ecord is created Mat erial list ing/ exclus ion [ st andard ] Sale s Per sonnel m as ter process ing Sales pers onnelis p ro cessed Specify ac count gr oup Payment car d Set up Mainta incont rolda ta Sampler eceiver to be create d Account gr oup with exter nal number assignme nt d eterm ined Alter nat ive payer for c ust omer specif ied Line it em settlement is specif ied Produc t alocation [ st andard ] Specify alt er nat ive pa yer Maintain messages Decentr alized processing r equired Cust omer to be c reated f or st atistica lpurposes Alternative p ayer for item alowed Payment block is s pecified Basic data pr ocessing for legal contr ols [st andar d] Maint ain par tner fun ctions Check if decent ralized handling is des ired Cu stomer is a ss ort ment custom e r Maintain marketing data M ar ke ting data ar e m aintained Dunning procedure is specif ied Sales dealprocessing [ sta ndard] Decentr alized proces sing n ot requir ed Maintaindunning data Customer is one-time cust omer Det ermine foreign tra de Maintain contact Create unloading point Create receiving point Create depar tment dat a persons Foreign trade data determined Dunning block is specifie d M ain tain cor respo ndence Receiving point has been Depar tment has been cr eat ed crea ted Assign receiving point Ass toign depar tment Cont to act person dat a are an unloading point rec eiving point m ain tained Cust omer unloading pnts have been maint ained M aintain c redit ma nagement data Corr espondence Credit is management data m aintained det ermined Cust omer hierarchy Sales summary Bat ch sea rch stra Classification tegy [ classific ation pr ocessin g[ st andar proc d] essing [standar processing d] [standard] syste m] [standard ] Specify address of cust omer Addr ess is specified Inter est calculation is s pecified Conditions processing Plant proc es sing ( Pur chasing) Maintain ac co unt ing informat ion Sold-to part y to be create d Cust omer is also vendor Planning gr oup is specif ied Cu stomer- material- info pr ocessin g[ st andard] Maint ain account con trol Maintain sales data Ship- to pa rty t o be cr eated Trading part ner is specified Clearing betwee n cust omer/ vendor specified f or automatic pay ment s Basic dat a pr ocessing f or legalc ont rols [ sta nd ard] M anage ment of physical samples Payer to be created Specif y company code Com pan y code is spe cified Bank details are spe cified Possible payment methods are specified Custome r volume re bat e agreem ent processing [norm a l] Plant pr ocessing Cus tom er m as te r r ecord is to be cr ea ted Spec ify payment tr ansaction data Manual sample r elease Deter mine cus tomer functio n Invoice recipient is to be cr eat ed Accoun t group wit h int ern alnumbe r as signment determ ined Define c ust omer number Custo m er numb er is det ermined Payment car d dat a is maintained Sales ar ea data ar e maintained Mainta inpayme nt informat ion Alt ernat ive payer specific to company code s pecified Cr eat e customer Cust omer master recor d is crea ted Mater iallis ting/exclu sio n [ sta ndard] Sales Personnel mast er pr ocess ing Sales per sonnelis pr ocesse d Specify ac count gr oup Main tain cont rol da ta Sample receiver to be crea ted Account gr oup with exter nal number assignmen t det ermine d Alte rnative pa ye r f or cust omer specified Lin e item set tlem ent is specified Product alocation [ standard] Specify alt ernat ive payer Mainta inm essages Decen tralized p ro cessing req uired Cus tomer t o b e created for st atis ticalpurposes Alt ernativ epayer for item alowed Payment block is specif ied Basic dat aprocessing for legalcontr ols [s tandard] M aint ain pa rt ner functions Chec k if decentr aliz ed handling is desired Cu stomer is assort me nt custom er Maint ain marketing d at a Mar ket ing da ta are maint ained Dunning pr oc edure is s pecified Sales dealprocessing [st and ard] Decentralized process ing not required Maint ain dun nin gdat a Customer is one- time custom er Det ermine foreign trade M aint ain cont act Cr eat e unloading p Cr oint eat e receiving point Create depar tment dat a persons Fo reign t rad e dat a d eterm ined Receiving point has been Depar tmen t has be en cr eat ed creat ed Maint ain Maint ain credit corresponde nc em anage ment data Dunning bloc k is Corr espondence Credit is management data specif ied m ain tained deter min ed Ass ign receiving point As sign to depar tm ent Contact t o a per son data are an unloading point r eceiving p oint m ain tained Cust omer un loading pnts have been maint ained Cust omer hierar chy Sales s ummary Batc hsear ch st Classific rategy ation [ classif ication pr ocessin g[ st andard] processing [standard] proc essing [standard] sy stem] [ standard] J. A. Gulla Introduction to Enterprise Systems 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 Page 23 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). Page 24 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. Page 25 of 42

PLANT MAINTENANCE PLANT MAINTENANCE & PRODUCTION & PRODUCTION Request material Request material Make production schedule Make production schedule Reserve goods Reserve goods document PURCHASING PURCHASING Allocate costs Allocate costs Create purchase order Create purchase order Approve purchase order Approve purchase order Send purchase order Send purchase order document ACCOUNTING ACCOUNTING Allocate costs Allocate costs Verify invoice Verify invoice Evaluate vendor Evaluate vendor Evaluate customer Evaluate customer document invoice material MANAGEMENT WAREHOUSE WAREHOUSE Receive goods Receive goods Deliver goods Deliver goods Deliver invoice Deliver invoice Return goods Return goods label label QUALITY INSPECTION QUALITY INSPECTION Reserve goods Reserve goods Inspect goods Inspect goods Release/reject goods Release/reject goods 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, Page 26 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 Page 27 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. Page 28 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. Collection of ordered activities: People Common goal: Value to customer Resources Figure 18. Structure of business processes Page 29 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 Page 30 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. Risk high Paradigm shift Reengineering Rationalization Automation low Return low high Figure 20. Organizational risks and returns of enterprise system projects Page 31 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 Page 32 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. Control flow Purchase Requisition created State/event Organizational unit Function Approve Purchase requisition XOR Purchasing Accounting Logical operator (XOR, AND, OR) PR not approved PR approved And released Figure 21. Concepts in EPC models Page 33 of 42

Assigned purchase requisition Invoice with reference has arrived Invoice w/o reference has arrived Purchase order process for stock mat. Purchasing XOR Purchase order is transmitted Material arrived AND AND AND OR Invoice processing Accounting Goods receipt processing Warehouse XOR AND Goods are to be returned XOR XOR Invoice is not accepted Invoice posted and released for payment Material post. to stock in qual inspect Material is placed in stock Transfer order created automatically Quality inspection. Warehouse Placement in storage processing XOR Material is not accepted Material is accepted Materials is placed into stock 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 Page 34 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. People Strategic objectives Technology Business processes Figure 23. Human concerns in reengineering projects Page 35 of 42

Productivity/ Morale/ commitment Change introduction Managed change Unmanaged change 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: Time 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. Page 36 of 42

People fears People benefits Commitment Acceptance Intelligence Knowledge 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. 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 Raytheon Aircraft (completed in 2000) 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). Page 37 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. Resistance to change Lack of management commitment Unrealistic expectations Poor project management Uncompelling change case Scope expansion/uncertainty Project team lacked skills No change management program No horizontal process view IT perspective not integrated 46 44 44 43 41 36 54 65 72 82 0 20 40 60 80 100 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. Page 38 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. Total implementation costs 7 6 5 4 3 2 1 1 2 Extent of customization (% of total lines of code changed) 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: 3 4 5 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. Page 39 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 upto-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. Page 40 of 42

Collaboration Internet Comprehensiv e-business solution Portals Extranet Customer Relationship Management Business warehouse Market places Collaborative engineering B2B procurement E-recruiting Intranet Sales Human Resources Logistics Accounting Production Strategic Enterprise Management Knowledge warehouse Electronic bill presentment & payment Collaborative forecasting Enterprise Enterprise group Business Partners World 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 4 th 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. Page 41 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. Page 42 of 42