Improve Business Processes Based on ERP and Post-ERP Applications

1. Objective

More and more organizations use standard business application software packages, such as Enterprise Resource Planning (ERP), Supply Chain Management (SCM) or Customer Relationship Management (CRM) systems, to support their working processes. This is a trend that is expected to stay stable during the coming years [1] [2]. Especially CRM and SCM systems will become more and more important. These systems are referred to as "Post-ERP Applications."

The implementation of such standard software systems ties up substantial corporate resources (e.g. personnel or financial assets) for a relatively long period of time, sometimes up to several years. Therefore, a company can generally not afford to have a project fail. Efficient planning and execution of the implementation and, consequently, a head start over the competition, can become an important factor in achieving competitive advantage.

The following will present a business driven approach of implementing ERP and Post-ERP systems in an efficient and effective way. The session will seek to answer the following questions, among others:

• How should such an implementation be structured, and what are the major tasks?
• How do I implement a business project and not an IT project in order to reach my business goals?
• Which methods and tools should be used?
• How can continuous process improvement be prepared during the implementation?

2. Business Processes as Guideline

To achieve business goals, more and more organizations structure themselves according to their business processes to enable a flexible reaction to market needs. The increasing orientation of business organizations towards their business processes requires a Business process-oriented Implementation of Standard software (BIS) of ERP and Post-ERP Systems. The resulting business-driven approach ensures the realization of an organization's business goals. The implementation becomes a business project, not just an installation of new IT products. Current ERP and Post-ERP system architectures make such process-oriented procedures possible because of the integration of the software systems. However, their function-oriented structures require a special implementation approach to realize business processes: the "BIS approach." This is especially true if complete processes must be improved across several organizations, i.e. in the supply chain management or the customer relationship management arenas.

The following will discuss the need for BIS as well as its methodological framework.

2.1. Need for Business Process Orientation

Business organizations must deal with increasingly tough competition at home and abroad by creating lean, flexible, market-oriented structures. Business operations must be optimized to attain goals such as reduced cycle times, reduced costs, increased flexibility, and improved product and service quality. Because of the large quantity of functions to be performed by an organization, as well as the large number of work activities in the form of output items to be generated or managed, introducing changes to achieve those goals can be very complex [3]. Designing appropriate organizational structures that permit the definition and coordination of subtasks in the company can reduce this complexity. The structures can be oriented towards individual functions, i.e. sales or manufacturing of all the products of a business, or towards "objects," for example, a product or another kind of "result," and all the functions which apply to it.

This object-oriented view serves as the basis for a process-oriented organization. Such an organization is not focused on individual functions, but on the results of multiple functions, which fully support a higher-level task. This task results in value to an external or internal customer; i.e. order processing, from the receipt of a customer's order through to the shipment of the corresponding product, i.e. the entire supply chain. There is increasing agreement that process orientation should be the dominant factor in the design of organizational structure [4]. The focus of consideration is not on individual functions, but rather on complete business processes, which ensure complete results. These results provide value to customers. Business process orientation ensures that the whole organization is aligned to achieve business results.

Optimization of business processes usually takes place on the basis of information technology, which is in many ways the prime factor in making more efficient and more effective business operations possible. In this respect, the use of standard business application software (i.e. ERP and Post-ERP packages for SCM or CRM) has numerous advantages over custom software, and is therefore gaining increased acceptance. Implementation of standard software in an organization becomes the central component in determining the form of the organization. It must therefore be geared to business processes, and not to the structure of the software, which is usually functional. Here it should be observed that even integrated software systems such as SAP R/3, Baan, Peoplesoft, or Oracle are largely function-oriented in their structure; even their module names indicate this. Integration of functional areas does allow the support of business processes, but requires an implementation designed for this purpose [5], namely a special approach to BIS.

2.2 Methodological Framework

The Business process-oriented Implementation of Standard software (BIS) requires numerous activities, from the initial design of the business processes to the configuration of the standard software (customizing). Most of these activities can be supported by software tools or the standard software being implemented. The architecture developed by Scheer for support of business processes, i.e. "ARIS - House of Business Engineering" (HoBE), can be used to structure the activities and tools to be used [6]. This architecture classifies the tasks and products necessary for building and running business processes into four levels:

• Level I: Process Design
• Level II: Process Management
• Level III: Process Workflow
• Level IV: Process Application

For BIS, this means that the business processes must first be designed. Once the software is operational, this design is the fundamental basis for the management of the processes and also for their ongoing improvement. The standard software provides for control of processes by means of (at least partially) a predefined sequence of the functions. If it should become necessary during process definition to depart from this predefined sequence of functions, or to make the definition of such a sequence, then special workflow systems should be used. These may either be available as special modules of the standard software, e.g. as for SAP R/3, or else procurable externally. External workflow systems are especially useful when modules of various software systems are to be connected with them. The standard software modules are then configured on the process application level according to the design guidelines (developed on the design level).

The process design level is of essential importance for the actual implementation. Here, the structures of the business processes are determined, and the detailed implementation of the business operations using the standard software is defined. Thus the path leading from the business goal to the standard software configuration is predetermined here. The transition from these guidelines to the process application level, or the workflow level, is a decisive factor. This ensures that henceforth, the tasks will be processed according to the design.

Two basic software implementation problems frequently arise on the process design level:

• It frequently happens that the future processes are described in great detail, which can be very time-consuming. Many of the results which are obtained are not used at all, or are used only partially in the following implementation steps. These days, fewer and fewer organizations can afford this time.
• Some organizations avoid this problem by largely omitting a process design and installing the standard software based on results of "informal discussions." However, this often results in incomplete satisfaction of business requirements, since these requirements are not sufficiently understood by the software configuration personnel and the subsequent users. The expected benefits of the software implementation do not materialize.

These problems can be solved with the "Architecture of Integrated Information Systems" (ARIS), also developed by Scheer [6][7]. ARIS can be used as a framework to describe business processes efficiently, but nonetheless completely. Using ARIS, a process can be considered from five different views (see Fig. 1: ARIS Information System Views):

• Organization view (Who takes part in the process?)
• Function view (What is done in this process?)
• Data view (What information is produced or needed?)
• Control view (How do the three other views interact? Who works on which functions using which data and in which operational logic?)
• Output (Result) view (Which outputs/results are produced?)

3. Phases of a Business Process-Oriented Implementation

In the following, the phases of BIS which are based on HoBE and the ARIS architecture will be presented. A more detailed description is available in the specialized literature [5].

BIS can be divided into the following phases:

• Strategy-based Business Process Optimization Concept (BPO Concept)
• Standard Software-based BPO Concept
• BPO Implementation
• Optimizing Business Processes After Going Live ("Continuous Process Improvement" - CPI)

These phases can be used as a procedure for business-driven ERP and Post-ERP implementations in general. The approach is not focused on specific application software systems. But it points out where software specifics have to be included. BIS is especially useful in the logistics area, especially if processes have to be implemented across different organizations, i.e. in the field of supply chain management or customer relationship management.

3.1 Strategy-based BPO Concept

The purpose of the strategy-based BPO Concept is to orient the implementation activities towards the realization of business goals. Steps will be taken to ensure that the BIS becomes a business process optimization project, and not a purely technical project shaped by the structure of a software package. In this phase, a software-independent framework for the following phases of the BIS, which will be oriented toward the application software package and its specifics, is established.

The main steps of the strategy-based BPO Concept are:

• Determination of the target system
• Elaboration of a product model and a market model
• Definition of the business processes

To determine the target system, the critical success factors are derived from the competitive strategy, and then operational goals are defined on this basis. To establish the competitive strategy, the following three basic strategies can be distinguished [9]:

• Differentiation
• Cost leadership
• Focusing, i.e. concentration on market niches

Critical success factors are derived from these by identifying which results must be obtained for each case in order to put the competitive strategy into practice [10]. As a rule, critical success factors are in general focusing on increasing flexibility and quality, as well as cost reduction (i.e. reduce service cost or increase number of manufactured product types).

Operational goals are then determined on the basis of the success factors. Such goals, which may pertain to one or several success factors, are characterized by [11]:

• Substance of the goal (i.e. reduction of cycle time required for processing of a customer order)
• Scope of the goal (i.e. reduction by 60%)
• Time period for reaching the goal (i.e. six months)

Using these goals, project activities can be directed according to the business strategy on the one hand, and on the other hand the business success of an implementation can be measured. An implementation does not become a success simply because it creates hundreds of colored computer screens, but rather because it reaches the defined business goals. This should be a prime consideration, in particular, for large-scale and costly ERP and Post-ERP implementation projects.

Goals, thus defined, are reached when products (i.e., products in an extended sense; i.e. including goods and services) are "produced" and sold [12]. To define the resulting business processes, therefore, products and markets should be examined in detail as a basis for the process definition. This is done by elaborating product and market models [13] [14].

The product model describes the market output of an organization; thus it makes part of the output (result) view of ARIS. It contains:

• All goods and services offered on the market,
• Those product components (including services) which significantly influence a customer's decision, and
• The essential relations between the specified elements.

In the first step of generating a product model, the elements of the model are identified using creative techniques (e.g. the Metaplan technique). In choosing the elements to be considered, it should be kept in mind that the purpose is not to map complete i.e. bills of material, recipes, or other such product descriptions. Only the final products (or better product categories) and elements relevant to customer decision making should be included in the model.

The second step is to place these elements in relation to each other. Here it is important to include only relationships that are particularly significant to position the products on the market. Such concentration on the essentials ensures efficient utilization of the model in subsequent project phases.

For representing these elements and relationships, the method of entity relationship models (ERM) [6] is well suited. The advantages of these models over less formalized methods (i.e. representation via text) are:

• Systematic identification of all relevant elements of the product model
• Compact representation capability (often only one page for a model)
• Widely-accepted use

Formal requirements for the various versions of the ERM-method should, however, be held to a minimum. In this way, the analyst can refrain from specifying cardinalities without any loss of essential meaning. A simple and clearly understandable representation is essential for wide acceptance of these results. Purely methodological aspects should be kept in the background.

Figure 2 shows an example of a product model. In addition to a vehicle as a primary product, vehicle components, e.g. the drive mechanism, are also offered as products on the market. The range of products is enhanced by services, which may pertain to products (i.e. a vehicle), or may be offered independently on the market. Examples of this are engineering, service and project management.

Figure 2: Example of a Product Model

The market model describes the central aspects of the organization's field of activity, especially the product market. It contains:

• Elements which decisively characterize the market, particularly the product market,
• Elements which decisively support market actions, and the
• Essential relationships between the specified elements.

Generation of the market model proceeds similarly to that of the product model.

After the product model and the market model have been generated, both models must be coordinated with each other. Here the analyst should take particular note of whether the market needs described in the market model are consistent with the goods and services listed in the product model. If necessary, one or both models should be modified.

The market model and the product model then serve as the basis for defining the business processes. The resulting process models contain:

• The core business processes of an organization,
• The most important subprocesses that shape the structure of the core business processes
• The central logical dependencies between the subprocesses and also between the core processes.

The use of the market model and the product model ensures a business process definition that is properly oriented to products and to the market.

The first step in deriving business processes is to cluster the elements of the market model and the product model. The results are core information objects. The clustering flows partly from the relationships between the elements of the models. However, the determining factor is semantic-content consistency, in other words, an appraisal from the standpoint of business considerations. Some typical clusters of market models are the needs of various customer groups (i.e. domestic and international customers), or elements of processing, such as quotations and orders. In the product model, some of the things that could be included are: services, complete goods (i.e. complete systems) and components (i.e., components, sold as products). The technique of clustering according to the degree of standardization of products has also proved itself in practice.

Core business processes can be defined based on the core information objects. These core business processes result from the tasks, which must be performed in connection with the information objects. Some examples of this are order processing for complete systems from pre-sales activities through shipment, order processing of components from pre-sales activities through shipment, product development from market research through release of a product for serial production, or customer service from the sale of a product up to its replacement.

The structure of the core business processes is now determined by using the elements from the product and market models. This means that the essential functions needed for processing the elements assigned to a core process must be defined. Here it is helpful to use industry reference models (available e.g. through consulting companies), which can facilitate organization-independent identification of the relevant functions. The creative work can then concentrate on an organization-specific adaptation. The use of reference models can speed up the process definition tremendously.

The last step is to outline the logical dependencies between the subprocesses/functions and also between the core business processes. These specify which function triggers which other function. To preserve clarity, data flows should not be specified.

The product model and the market model are tools for process definition. A strictly formal derivation of the processes is impossible. This is rather an important creative management activity of businesspersons, and not just a simple formal procedure [8].

Value-added chain diagrams are proven methods for representing process definition [7]. However, the symbols should be limited to representation of functions (subprocesses) and their logical dependencies. This ensures that central business management factors, namely the defined business processes and the operational logic of their functions, remain in the foreground.

An example of business process definition in the form of a value-added chain diagram is shown in Figure 3: "Example of a Business Process Definition." The core business processes "Locomotives," "Components," "Customer Service," and "Engineering" are structurally represented. For example, one important aspect is the fact that the "Locomotive Project Management" triggers not only "Vehicles Engineering" and "Operative Purchasing," but also "Offer and Order Processing" of "Customer Service." This is the way internal transactions originate, for example between profit centers.

The business processes thus defined now form the framework for further ERP and Post-ERP implementation activities. Functions that are relevant to provide competitive advantage must be detailed in case the corresponding considerations are not sufficiently described in the process definition. This is necessary to make sure they will be properly taken into account later.

The business processes and the included functions should also be assigned to organizational units to define, how a process will run through the organization. Here it is very often useful to use abstract organization levels instead of concrete department names to avoid political discussions at this early stage of the implementation.

If the relevant ERP or Post-ERP software does not cover all areas of the business processes that should be implemented [15], a decision to acquire additional software or to use legacy systems should be made before performing any more implementation steps, because the following phases of BIS depend on the software used.

The business process definition can be used as the basis for project planning of further BIS activities. This ensures a process-oriented project structure.

3.2 Standard Software-based BPO Concept

The business processes that have been defined will now be specified, based on the capabilities of the specific ERP or Post-ERP system (and possibly other software products being used). The primary tools here are software specific reference models, e.g. the SAP R/3 reference model [16] [5].

The generation of the Standard Software-based BPO Concept comprises the following main steps:

• Selecting the relevant sections from the reference model
• Detailing the process description on the transaction level
• Assigning organizational units to the processes

Standard software reference models represent a formal description of the processes to be supported using the software. They show how working processes can be designed using the standard software system. Since software packages, such as an ERP system like SAP R/3, cover many functional areas of an organization, they use hundreds of individual process models (i.e. more than 600 individual process models for R/3). The relevant processes must now be selected from the reference model, based on the business process definition of the strategy-based BPO Concept. These processes are normally modeled on the "transaction level;" i.e. a software transaction is assigned to each function. Thus a connection can be established later directly between the process model and the relevant entry screens in the ERP system. The individual processes, very often represented in event-driven process chains (EPC, sequences of events and functions describing the process), can be explained by means of additional information models of the reference model [17] as well as by using the software documentation which is normally accessible from the reference model (i.e. the case with the SAP R/3 reference model). A section of a process representation from the R/3 reference model is shown in Figure 4: "Section of a Software Reference Model."

The roughly defined business processes of the Strategy-based BPO Concept are now detailed with the aid of the relevant sections from the software reference model. This means that irrelevant process sections of the reference model are eliminated, missing sections are added. When extensions to the model are defined, a check should be made as to whether they can be supported using the ERP system. This check is generally made by appropriate tests using the software. If a solution cannot be reached within the standard-software functionality, then appropriate organizational measures should be defined, or additional software must be acquired, or a software add-on programming must be defined.

The appropriate organizational units are now assigned to the individual functions of the process models on the transaction level. These units are either taken from existing organization charts, or defined as new units on the basis of the business process definition, which has been performed. Also, an assignment of the most important input and output data to the individual functions is frequently useful for describing the functions adequately (these data can mostly be taken from information models of the reference model).

This complete representation of the processes is frequently carried out in the form of extend event driven process chains (eEPC). A section from a process representation in the form of an eEPC is shown in Fig. 5: "Section of an standard software based process, eEPC Representation." It describes which organizational unit performs which function using which data and which software (here i.e. SAP R/3) transaction.

Complex process sections can be further detailed, down to the screen level. This means that exactly one software screen is assigned to each function. In this way, future users can be led through the system step by step. The software reference model does generally not handle this degree of detail in process description. In this case an organization-specific description of the detailed operations on screen level must be performed.

The process models will later be the basis for end user training. This ensures that the design ideas will really be implemented.

The process description forms the foundation for the derivation of the "Software organization elements" (i.e. the SAP R/3 hierarchy elements). These "organization elements," which may be used to control reporting or function access capabilities, are normally also described as part of the software package reference model. The design specific to the organization takes place by appropriate mapping of the business organization structure to the software organization elements. Here the analyst should be careful to adequately generate core software organizational units (i.e. clients, controlling areas, or plants in the case of SAP R/3) before performing any configuration activities to avoid subsequent costly revisions.

3.3 BPO Implementation

Using the models of the BPO Concept based on the application software system, we now continue to implement this design. This activity overlaps the just described development of the design activities; i.e. while some processes are still being designed, the implementation activities are already in progress for some others. This permits an efficient implementation on the one hand, and on the other hand ensures ongoing feedback between the design and realization.

BPO implementation activities may be divided into:

• IT measures
• Organizational measures
• Live start

The IT measures involve software, data (i.e. data transfer), hardware, and tests. Customizing the standard software [18], i.e. the configuration of various parameters specific to the organization, assumes a central role. This is derived from the Standard Software based BPO Concept.

Using appropriate software tools, it is now very often possible to go directly from the relevant function representations of the application software reference model to the corresponding customizing menus of the software [5]. This permits the customizing to be carried out in accordance with business design considerations. However, there are then still many individual interactive activities to be carried out [19]. This is essentially due to the fact that a complete automation of the customizing would require excessively costly detailing of the reference models which would therefore become much to complex.

Some organizational measures are: Implementation activities from the standpoints of personnel, organization structure and operation, and also work space. Here, training activities as part of the personnel-oriented steps occupy a paramount position. User training must be distinguished from technical system maintenance training.

Successful training of the users is especially critical for BPO implementation. For this the following procedure in four phases makes sense (see Figure 6: Business Process-oriented Training):

• Basic training - business processes: Here the future users of the ERP system are given a view of their new, possibly modified tasks from a business standpoint. Any dependencies of tasks within a business process are also demonstrated.
• Basic Training - ERP system: The software is presented as a tool (screen structure, help functions, ... ).
• Process training: This is the central training phase, which concerns the way in which the software as a "tool" is to be used for the business tasks to be performed, i.e. how the future business processes will look like. The training proceeds on the basis of the models from the Standard Software based BPO Concept, and ensures that this design is put into practice.
• "Kick-off" training: Here, special issues of the initial operational phase and their solutions are discussed.

The training classes can be conducted at the planners' discretion either before the other design implementation steps or concurrently with them. On the one hand, they should be started early enough to be able to prepare the future software users very thoroughly, but on the other hand, the time interval between training and live start with the system should not be so great that the trainees forget the training contents.

As mentioned above, it is important to base the training on the documentation generated during the design, in order to ensure a business driven ERP implementation.

The live start is the transition of the processes from the "build-time" phase to the "run-time" phase. It includes bringing the ERP system online and the activation of all IT- and organizational measures, as well as the initial operational support of the future users.

3.4 Optimizing Business Processes after Going Live

After going live with the ERP system, management should make sure that the defined project goals are being met. This requires ongoing supervision and corrective measures, if necessary. This means that after going live with the application software, the implementation passes directly to Continuous Process Improvement (CPI). This phase can also be looked at as part of the BPO implementation, but should be emphasized as an independent implementation step of BIS, because of its great importance to the ultimate success of the project.

The essential activities of CPI are:

• Review the BIS frame conditions
• Review whether strategic goals have been reached,
• Refitting the BPO implementation
• Refitting the BPO Concepts

If the environmental state, which was present when the strategy-based and standard software-based BPO Concept were worked out, has changed (i.e. new products included or new standard software release), then all design and implementation activities, that are affected by this change, should be reviewed and corrective measures should be defined, if necessary. In particular, changes fundamentally affecting the business can lead to considerable work to make up resulting deficiencies. They should therefore be accounted for as much as possible in advance during the implementation.

Progress toward reaching goals must be checked depending on the individual time periods for reaching these goals. If goals are not met as expected, it is to be checked whether this is because of faulty design or implementation activities, or whether the goal definition was unrealistic. In the first case, corrective measures must be defined again, and in the second, the goals should be adjusted.

If goals cannot be reached by optimizing the implementation measures, the standard software-based BPO Concept, or even the strategy-based BPO Concept should be adapted accordingly. New steps for implementing the design are then derived from this.

4. Business Process-Oriented Implementation in Practice

In closing, some experiences with BIS as a framework for the ERP implementation approach will be discussed. In particular the discussion will center on the use of software tools for implementation. Finally, a brief description of past experience in ERP and Post-ERP implementation projects will be given.

4.1 Use of Tools

Since the entire procedure is based on the ARIS architecture as the general framework, it is helpful to use the ARIS Toolset, which supports this architecture [5], as an example. The tool supports consistent and efficient generation and processing of the information models which have been introduced. The universally applicable meta structure, on which the tool is based, also allows project-specific deviations from or enhancements to the presented methods.

Software tool support may appear at first glance to be unnecessary for the strategy-based BPO Concept, since the data volume of the models to be handled may be relatively small. However, practical experience has shown that it is precisely during this phase that many changes are necessary before a stable model version is achieved. Here, appropriate tool support provides gains in efficiency as well as a simpler weighing and inclusion of alternatives. If more complex industry reference models (which may be obtained, for example, from consulting firms) are used, i.e. as checklists [20], then appropriate tool support becomes indispensable.

The latter is especially true for developing the standard software based BPO Concept. Models such as the R/3 reference model (available e.g. in the ARIS Toolset) [21] cannot be processed in the manner described without appropriate tool support. As a result, SAP as well as more and more other ERP vendors (i.e. Baan) offer models, mostly available in proprietary tools integrated into the application software [22] [23]. Sometimes different standard software packages have to be used within one company. It then becomes necessary to avoid proprietary implementation tools and to start using tools of wider scope that are independent of specific software products. Thus, for example, ARIS Toolset can be used as a company-wide "Process Warehouse," [24], which serves as a basis for configuring different standard software systems (i.e. an ERP system of one vendor and an SCM or a CRM system of another vendor). It can also be used for generating process-oriented reports spanning the entire organization (i.e. for ISO 9000), independent form the used application software.

In the course of BPO implementation, it can make sense that the configuration-relevant information in the models which have been created are transferred to the software, in order to work with software-specific tools, i.e. the Implementation Guide (IMG) [25] of the SAP R/3 system. As a consequence, implementation tools must have interfaces to the relevant standard software packages.

As previously discussed, the information models generated in the strategy based and in the standard software based BPO Concept should also be used as training aids. On one hand, this will ensure implementation of the designs, and on the other, will serve to validate them. The used software tool can support that, i.e. by offering special presentation or animation features.

4.2 Practical Experience

Results from multiple application software implementations (mostly SAP R/3 implementations [26] [27]) have shown that the process-oriented implementation of standard software packages yields efficient and effective results. One difficulty, which arises during such large-scale implementation projects, is that of keeping the focus on the business side of the implementation, on the business goals. Precisely with such large-scale and often relatively flexible software systems as ERP, CRM or SCM systems, there is a serious risk that technical considerations such as setting parameters to appropriate values or developing interfaces will dominate project activity, and that the project goals originally defined will fade into the background. This can be avoided by consistently keeping all implementation activities geared to the business-oriented information models, especially the process models.

A large-scale process-oriented software implementation brings about changes in many business operations. This leads to job changes for many of the organization's employees. Therefore activities for change management, i.e. through information, communication, and especially training, play a primary role in software implementation [28].

A broad consensus and understanding of project goals and procedures are important prerequisites for the implementation, and particularly for initiating continuous process improvement. Ongoing information, communication and training activities should be integrated in the implementation project from the very beginning.

Project management [29] and project controlling [30] also play a decisive role in large standard software implementations. Deadlines, costs and tangible goals should be continually reviewed to ensure smooth progress of the implementation. Project structure, project structural organization, and project scheduling should be coordinated with the process-oriented approach, with the business process definition as a central feature of the structuring.

Also software vendors develop frameworks to ensure that their software gets implemented in and efficient way. An example is SAP's Accelerated SAP (ASAP) [31], which ensures a very efficient SAP R/3 implementation. ASAP can be used to specify two of the above-described phases (which represent an implementation framework): "Standard Software-based BPO Concept" and "BPO Implementation", thus the software oriented implementation phases. "Strategy-based BPO Concept" and "Continuous Process Improvement" have to be added, because they are in that case not included in the software related approach of the vendor.

It is to be expected that the continually improving use of tools in the context of a standard-software implementation project will facilitate further concentration on the business issues and change management activities of the implementation. The implementation becomes an independent business process by itself, which should receive long-term support in an organization, so that the use of standard software packages in the organization can be adapted to new market requirements or enhanced software capabilities arising from new software releases. This enables a continuous improvement of the defined business processes.

5. Bibliography

[1] cf. E.g. AMR Research (Publ.): AMR Research predicts ERP market will reach $52 billion by 2002. Press Release, Boston, 1998.

[2] cf. E.g. AMR Research (Publ.): AMR Research predicts Supply Chain Management market to Grow 50% in 1999. Press Release, Boston, 1999.

[3] cf. e.g. Scheer, A.-W.: ARIS - Architektur integrierter Informationssysteme. In: Scheer, A.-W. (Publ.): Handbuch Informationsmanagement: Aufgaben - Konzepte - Praxisloesungen. Wiesbaden 1993, pp. 81-112.

[4] cf. e.g. Hammer, M., Champy, J.: Business Reengineering. 2nd edition, Frankfurt, New York, 1994.

[5] cf. Kirchmer, M.: Business Process Oriented Implementation of Standard Software - How to Achieve Competitive Advantage Efficiently and Effectively. 2nd edition, Berlin, New York and others 1999.

[6] cf. Scheer, A.-W.: ARIS - Business Process Frameworks. 2nd edition, Berlin, New York and others 1998.

[7] cf. Scheer, A.-W.: ARIS - Business Process Modeling. 2nd edition, Berlin, New York and others 1998.

[8] cf. Nickols, Fred: The Difficult Process of Identifying Processes. In: Knowledge and Process Management, Volume 5 Number 1, 1998.

[9] cf. Porter, M. E.: Wettbewerbsstrategie: Methode zur Analyse von Branchen und Konkurrenten. 6. Auflage, Frankfurt, New York 1990, p. 62.

[10] cf. Rockart, J. F.: Current uses of the critical success factors process. In: Proceedings of the fourteenth annual conference of the Society for Information Management. o.O. 1982, p. 17.

[11] cf. e.g. Spang, S.: Informationsmodellierung im Investitionsguetermarketing. Wiesbaden 1993, pp. 103 - 105.

[12] cf. e.g. Gutzwiller, T. A.: Implementierung von Geschaeftsprozessen mittels SAP R/3: Unmoeglichkeit oder Koenigsweg?. In: Wenzel, P. (Publ.): Geschaeftsprozessoptimierung mit SAP R/3. Braunschweig, Wiesbaden 1995, pp. 1 - 13.

[13] cf. Kirchmer, M.: Markt- und produktgerechte Definition von Geschaeftsprozessen. In: Mangement & Computer, 4/1995, pp. 267 - 273.

[14] cf. Kirchmer, M.: Market- and Product-Oriented Definition of Business Processes. In: Elzina, D.J., Gulledge, T.R., Lee, C.-Y.: Business Engineering. Norwell 1999, p. 131-144.

[15] cf. e.g. Schilling, S.: Integration von Fremdprodukten in R/3 - Vorteile der funktionalen Kopplung. In: Wenzel, P. (Publ.): Geschaeftsprozessoptimierung mit SAP R/3. Braunschweig, Wiesbaden 1995, 176-192.

[16] Bancrof, N.: Implementing SAP R/3 - How to introduce a large system into a large organization. Greenwich 1996, pp. 36-39.

[17] cf. e.g. Rosemann, M., Rotthowe, T., Schuette, R.: Modellbasierte Organisations- und Informationssystemgestaltung unter Verwendung der R/3-Referenzmodelle. In: Wenzel, P. (Publ.): Geschaeftsprozessoptimierung mit SAP R/3. Braunschweig, Wiesbaden 1995, pp. 15-42.

[18] cf. e.g. Wenzel, P. (Hrsg): Betriebswirtschatliche Anwendungen des integrierten Systems SAP R/3. Braunschweig, Wiesbaden 1995, pp. 31-89.

[19] cf. e.g. Crowley, A.: Waiting to exhale. In: PC Week, October 7, 1996.

[20] cf. e.g. Brombacher, R., Hars, A., Scheer, A.-W.: Informationsmodellierung. In: Scheer, A.-W. (Publ.): Handbuch Informationsmanagement: Aufgaben - Konzepte - Praxiserfahrungen. Wiesbaden 1993, pp. 173-188.

[21] cf. e.g. Keller, G., Meinhardt, S.: SAP R/3-Analyzer - Optimierung von Geschaeftsprozessen auf Basis des R/3-Referenzmodells. In: SAP AG (Publ.): SAP R/3-Analyzer. Walldorf 1994.

[22] cf. e.g. Gormley, J. T. III, Woodring, S. D.: Package Application strategies. In: Forrester Research, Inc. (Publ.): The Forrester Brief. February 13, 1997.

[23] cf. e.g. SAP America, Inc. (Publ.): R/3 System Business Engineer. 1997.

[24] cf. e.g. The Yankee Group (Publ.): IDS Prof. Scheer, Inc. starts to build mind share. In: The Yankee Group (Publ.): Yankee Research Notes. Boston February 4, 1997.

[25] cf. e.g. SAP AG (Publ.): Customizing Vorgehensmodell R/3. Walldorf, July 1993.

[26] cf. e.g. Kirchmer, M., Lameter, F.: Geschaeftsprozessoptimierung - Kernaufgabe der SAP-Einfuehrung. In: Scheer, A.-W. (Publ.): Rechnungswesen und EDV, 15. Arbeitstagung, Saarbruecken 1994, pp. 497-520.

[27] cf. e.g. IDS Prof. Scheer GmbH (Publ.): Most comprehensive complete R/3 Implementation: ABB Hochspannungstechnik AG. In: IDS Prof. Scheer GmbH (Publ.): Scheer Magazine 1/97. Saarbruecken 1997, pp. 22-24.

[28] cf. e.g. Wildemann, H.: Einfuehrungsstrategien fuer die computerintegrierte Produktion (CIM). Muenchen 1990, pp. 198-201.

[29] cf. e.g. Page-Jones, M.: Praktisches DV-Projektmanagement. Muenchen, Wien 1991.

[30] cf. e.g. Scholz, K.: Ansaetze fuer ein Controlling zur Sicherung einer erfolgreichen Standardsoftwareeinfuehrung. Frankfurt u.a. 1995.

[31] cf. SAP AG (editor): The Efficient R/3 Implementation Roadmap& ASAP. 1997.