Ea Article

Computers in Industry 40 Ž1999. 155–171 www.elsevier.nlrlocatercompind

Enterprise Integration—Business Processes Integrated Management: a proposal for a methodology to develop Enterprise Integration Programs Angel Ortiz ) , Francisco Lario, Lorenzo Ros Grupo de Gestion de Valencia, ´ e Ingenierıa ´ de la Produccion ´ (GIP), Departamento de Organizacion ´ de Empresas, UniÕersidad Politecnica ´ Camino de Vera s r n, E-46021 Valencia, Spain

Abstract An approach to develop Enterprise Integration Programs to assist enterprises in their migration path towards integration is proposed. It is called IE—GIP ŽEnterprise Integration—Business Processes Integrated Management, acronyms in Spanish.. The topic is very important in industrial engineering nowadays because of the growing need to improve existing industrial systems and to organise such complex systems faster, better, and in a more systematic way. The contribution to the field of Enterprise Integration is mostly a methodological one. More specifically, it is based on the integration of Purdue Enterprise Reference Architecture ŽPERA. and Open System Architecture for Computer Integrated Manufacturing ŽCIMOSA. principles to propose an integration approach for industrial enterprises. Starting from existing leading proposals ŽCIMOSA, PERA, GERAM., a methodology has been defined and some extension to an architecture and supporting computer tools are discussed. The proposal covers the life cycle of an Enterprise Integration Program in a top-down approach. The approach is centred on the business process concept, but is based on a visionrprocessrpeoplertechnology view of the enterprise. The methodology divides the work into two major phases before system construction: master planning and CIM programme development. The method adapts the system life cycle of PERA but uses, whenever possible, the CIMOSA architecture with its business process approach. New CIMOSA-like constructs are introduced to be used in activities along with the methodology when necessary. To support the modelling phases of the proposal and to provide guidance to users of the methodology, computer supported tools have been developed in the course of this work. q 1999 Elsevier Science B.V. All rights reserved. Keywords: Enterprise Integration; Methodology; Enterprise reference architectures; Business processes; CIMOSA; PERA

1. Introduction Various approaches have been proposed for Enterprise Integration w2,5,9,10,20,21x. The current need for enterprise-wide integration of business organisa-

)

Corresponding author. E-mail: [email protected]

tion can be explained by several reasons. In the authors’ opinion, some of the most relevant ones are: - The need to keep business operations aligned with strategy. - The need to share enterprise information, Ždata used for decision making.. - The need to interoperate, i.e., the need for the different systems that exist in the enterprise to be

0166-3615r99r$ - see front matter q 1999 Elsevier Science B.V. All rights reserved. PII: S 0 1 6 6 - 3 6 1 5 Ž 9 9 . 0 0 0 2 1 - 4

156

A. Ortiz et al.r Computers in Industry 40 (1999) 155–171

able to work with each other, even across organisation boundaries Žextended and virtual enterprises.. - The need to generate models and tools which let the users estimate the impact of the decisions taken in view of the globalisation of markets and the need for fast and effective response of enterprises The evolution in this field has gone through several phases: the initial objectives aimed to build the physical level integration; then the focus was on the integration of applications; the integration of the business level and finally of the full enterprise operations were addressed ŽFig. 1.. In the present work, a new definition is introduced for Enterprise Integration based on previous definitions w2,3x: Enterprise Integration ŽEI. consists in facilitating the material, information, decision and control flows throughout the organisation, linking functions with information, resources, applications and people, with the aim of improving communication, cooperation and coordination in the enterprise, in order to manage the enterprise to behave as a whole and operate according to the strategy of the enterprise w4x. To reach these objectives, all levels of enterprises must be considered, from the most strategic to the most operative ones. They must evolve in a coherent framework, which enables that actions and decisions made at each of the levels of the enterprise are taken into account.

Fig. 1. Enterprise Integration evolution w1x.

A good assessment of the importance and advances reached recently can be found in the two ICEIMT initiatives developed in 1992 w11x and 1997 w12x. Most of these proposals focus on the modelling of one or several aspects of the enterprise Žfunction, decision, information, etc... From the analysis of the different proposals, it can be observed that several relevant issues were not addressed: Ži. Most of the proposals do not cover fully the handling of the enterprise strategy Žmission, vision, values, critical success factors, business strategies.. It should go beyond a simple definition prospective, and should make the strategy relevant in the development of the whole Enterprise Integration Program w13x. Žii. The necessities in terms of model languages adapted for management levels Ži.e., userfriendly, simple and easy-to-use. have not been adequately addressed. In these management levels, the emphasis is on simple models with information centred on the parameters which allow management to make decisions. But these models have to reflect reality, they should aggregate relevant information especially on resources capabilities to allow predictions on time behaviour of any model to support decisions. Žiii. Often, the availability of methodologies and tools in order to operate the models has been disregarded. Živ. The impact of Enterprise Integration Programs on the human resources of the enterprise has not been sufficiently studied. Neither has been studied, the effect of human resources on the development of these proposals. The observed shortcomings have led to the development of a proposal, in which it is understood that, to progress towards EI, it is necessary to take into account aspects relating to enterprise strategy and business processes, as well as to the modelling, construction and execution of these processes. Additionally, the consequences of the program on the human resources and the impact of the human resources on the success possibilities of the program must not be ignored. To cover these aspects and make a step forward on the path towards EI in a coherent and effective way, it is necessary to provide the enterprises with three necessary elements: a methodology, an architecture and tools. Therefore, these three elements are the ones which make up the current proposal ŽFig. 2..

A. Ortiz et al.r Computers in Industry 40 (1999) 155–171

157

Fig. 2. Proposal framework.

The methodology is defined as the union of w14x: Ži. a global and generic reference procedure which shows the structure of the existing and projected system and Žii. the description and control of the activities which lead, step by step, from the existing system to the future one; it takes into account the evolution and specific limitations and presents evaluation criteria about the behaviour of the system in relation with several prospects Žeconomy, quality, etc... The architecture w3x is a finite set of interrelated components put together to form a consistent whole defined by its functionality. Tools are the elements that allow users to apply both the methodology and the architecture in a more efficient and easy way. In Enterprise Integration Programs where the amount of aspects to be analysed is large, computerised tools are really necessary in order for the user to be able to create, manage and reuse the generated models.

2. Development framework The approach presented is based on the necessity to cover the whole life cycle of a business entity, from its identification to its disposal: - Taking into account the strategy of the enterprise Žvision., - Applying it to the business processes, as they are the ones which provide the higher congruency and

integration between the activities developed in the enterprise w15–17x, - Using structured techniques, - Developing enterprise applications, and - Keeping in mind the role played by humans and enterprise technologies. One possibility to develop this vision was to create these elements from scratch. But this would have been a major mistake as it would have discarded all the existing work and know-how developed by numerous R & D projects. Therefore, our position was to try to combine the most interesting aspects of the existing proposals in terms of methodological, architectural and tool dimensions, and to add the necessary elements whenever required, i.e., whenever the aspects concerned are not correctly or completely covered by the considered proposals. Several studies in which the different existing EI approaches are analysed can be found in Refs. w18,19x. Another very interesting survey is the one carried out by the IFACrIFIP Task Force on architectures for EI w20x. In this work, a complete study of the main EI architectures ŽOpen System Architecture for Computer Integrated Manufacturing—CIMOSA, GRAI, Purdue Enterprise Reference Architecture— PERA. was carried out, and brought important information about the advantages, drawbacks and pending areas in order to progress towards EI. As a result of this work, the GERAM proposal emerged w21x. GERAM has evolved from a comparison grid to become a complete framework for comparing and checking the completeness of proposals and advances in the EI research field. Therefore,

158

A. Ortiz et al.r Computers in Industry 40 (1999) 155–171

GERAM is not a proposal which can be directly applied Žit has no constructs and no methodology of its own. in an enterprise. Merging the most relevant aspects of each of these EI proposals was still a pending issue. This was the rationale for the current proposal.

3. Basis of the proposal As a starting point, we defined the objectives to be fulfilled in the development of the proposal, and amongst which the following can be highlighted Žsome of them are addressed by existing proposals but no proposal matches all of them.: - To provide enterprises with an adequate approach to develop Enterprise Integration Programs and re-engineering projects centred on business processes. - To support the complete life cycle for the considered business entity, from its identification and the identification of its strategic concepts, to its operation, and finally its disposal. - To deal with the aspects related with the human resources of the enterprise in the framework of EI. It was considered that the two existing proposals that best suited the desired objectives were, from the methodological point of view, the PERA proposal and, from the architectural point of view, the CIMOSA proposal. Therefore, they were adopted as the main ‘baseline’ of our proposal. Other authors have also addressed this perspective, but they developed their approach under different considerations. Either they are related with a mapping between CIMOSA and PERA w20x, or they explain the concepts of one ŽCIMOSA. using the ones of the other ŽPERA. w22x, or either combine both although under a different point of view w23x from the one developed here. In this proposal, we decided to follow the methodological framework of PERA but introducing a process-based approach. This led to the modification of some of the aspects of PERA and the development of new aspects. In terms of the architectural framework, the CIMOSA proposal was used wherever adequate. New CIMOSA-like building blocks were defined to complete the approach. Consequently, we managed to integrate in a unique pro-

posal the most relevant aspects of both proposals, introducing new elements whenever necessary. 3.1. The Purdue Enterprise Reference Architecture PERA w24,25x is based on a detailed and pragmatic methodology covering the whole life cycle of an industrial project from inception to operation and even system disposal ŽFig. 3.. From our perspective, the most relevant aspects of this proposal are located in the quality of its methodology, broad-range and refined in diverse industrial applications w26x. 3.2. The Open System Architecture for Computer Integrated Manufacturing CIMOSA w5,6x is an Open Systems Architecture for EI which includes a powerful language for enterprise modelling ŽFig. 4. and is aimed at model-based integration w27,28x. It provides a life cycle, but it does not cover the complete life cycle of a business entity as it starts with the Requirements Definition

Fig. 3. PERA phases and architecture.

A. Ortiz et al.r Computers in Industry 40 (1999) 155–171

159

Table 1 Basic characteristics of the proposal levels Level

Main characteristics

Macro

Developed in a short time Techniques adapted to managers Generates AS-IS and TO-BE at a macro level Establishes the Management of Change Moderated use of resources both economic and human Detailed The emphasis is on models Data-centred Design and build Higher use of resources, but on a more secure level

Fig. 4. CIMOSA constructs Žwithout organisation view..

phase and ends with the phase of Implementation Description. The CIMOSA cube provides a consistent and adequately structured modelling framework which is extended in GERAM into one which covers the full life cycle of enterprise entities. After presenting the basis of the proposal, we briefly describe its main phases.

enterprises usually, these two levels must be distinguished because of economic aspects, aspects relating to decision levels, and even aspects relating to the culture of the people involved in each one of the two levels w4x. The differences between both levels will be explained next. The macro level comprises four phases ŽFig. 5.: - Identification, - Conceptualisation, - Process Definition, - Master Planning.

4. Proposal As mentioned earlier, the methodological aspects of IE—GIP are based on the PERA proposal, and from the architectural point of view, the CIMOSA proposal was adopted whenever possible. On one hand, the life cycle concept of the PERA proposal and several aspects related with human teams, strategic approaches and master planning issues, have been adapted to the business process perspective of IE—GIP. On the other hand, CIMOSA plays a key role in the lower level phases from the Requirements Definition phase to the Build phase. The proposal has been divided into two major levels, the macro level and the detailed level ŽTable 1.. The main reason for this division is that within

Fig. 5. Methodology phases.

160

A. Ortiz et al.r Computers in Industry 40 (1999) 155–171

The main characteristics of these phases of the methodology are: Ž1. They can be developed in a short period of time in comparison with the usual duration of an Enterprise Integration Program, and with a moderated consumption of resources. Ž2. They use a language and tools comprehensible by managers and decision-makers, because the main objective is that managers design and analyse the business processes without a high level of detail, but linking them with the strategy of the enterprise, and the parameters they must use to measure performance. Ž3. They generate the AS-IS and TO-BE coarse models of the business processes of the enterprise. Ž4. They establish the guidelines to go from one model to the other, both at the technical and human level. Ž5. They develop all their work with a moderated consumption of resources, as it must be taken in account that they represent an overload for managers. The detailed level comprises six phases ŽFig. 5.: - Requirements Definition, - Design Specifications, - Implementation Description, - Build, - Operation, - Disposal. The detailed level is only carried out when the program has been accepted and validated at the end of the macro level. This means that management has a good knowledge of the objectives to fulfil and has given a strong support to the program Žgorno-go decision according to budget, priorities, risk, etc... The basic characteristics of this level are: 1. It focuses on the detailed construction of the models of the processes to be restructured and designed. 2. It is data-centred, i.e., a considerable amount of data has to be introduced in the process models. 3. The processes are modelled with the required Žhigh. level of details and are then built and operated 4. The cost Žhuman, economic, etc.. to develop the phases is much higher, but the work is being developed on a much more secure level as management has already adopted the program. In addition, the last phase of the system life cycle is the disposal of the business entity. Table 1 summarises these characteristics.

The proposal consists of three components: a methodology, an architecture, and tools. They are described in more detail in the following sections. 4.1. Methodology The methodology represents a users guideline for the development of Enterprise Integration Programs. We will describe each step of the proposed methodology, distinguishing between the macro level and the detailed level. However, the methodology can be used to support re-engineering programs as well. There can and should exist constant iteration between the different steps of the methodology. 4.1.1. Macro leÕel 4.1.1.1. Identification of the business entity. This first step consists of the identification of the scope of the Enterprise Integration Program to be developed. This scope must be clearly defined: it can be the whole enterprise, a part of it, or even the enterprise and some of its suppliers andror clients Žcustomer– supplier chain.. In this phase, the human labour necessary for the development of the first phases of the program will also be defined ŽTable 2.. The human teams are to be composed of the Program Leader, the Program Sponsor, the Steering Committee ŽSC., the Enterprise Integration Team ŽEIT. and Žexternal. Consultants. The sequence of activities for this phase is the following: Ži. The Program Leader identifies and documents the necessity and convenience of the development of an Enterprise Integration Program. Žii. The Program Leader involves the Program Sponsor and convinces himrher that this is the adequate working line. Žiii. The Sponsor and the Leader define the initial business entity where the program will be developed. The Program Leader helped by the people hershe selects must carry out a preliminary analysis that evaluates the costs of the program and its potential benefits in the business entity. Only if this analysis reveals that the application of the program is due to produce significant benefits will the program go on in the business entity. Otherwise, another one will be chosen. Živ. Once the business entity is defined, the Steering Committee will be created and will be in charge of the definition of

A. Ortiz et al.r Computers in Industry 40 (1999) 155–171

161

Table 2 Functions and capabilities for people and teams Human roles

Functions and capabilities

Leader

Must identify the potential advantages of the program, the business opportunities, the critical enterprise problems and how they can be solved by the application of enterprise integration. Must be capable to identify the critical success factors for the enterprise that justify the support to the program, and explain it with the suitable language to management, so that they know, understand and support the program. Must act as a coordinating person for the program and support it in all its phases. Must know enterprise integration and its advantages. Must show self-initiative to promote programs in the enterprise. Must have the capacity to bring the information to the management of the enterprise. Must know which are the success factors for the enterprise, as well as the critical necessities and understand how enterprise integration can deal with them. Must be capable in the first phases to convince the others participants of the interest of the program. Must be capable to identify the relations of the studied entity with other areas of the enterprise and with the environment. Must be a member of the management of the enterprise who believes in the principles defined by the Program Leader, and involves himrherself strongly in the development of the program. Must have an important role in the enterprise, both on the formal and informal environment, as hershe will be in charge of most of the work in the initial phases of the program. Must be formed by members of the management of the enterprise. Should have defined Žor will have to define. the strategy of the enterprise. Must transmit the plans generated to EI Team. Must be capable to define the relations of the studied entity with other parts of the enterprise and with the environment. Must be formed by people who have high level responsibilities in the business entity targeted by the program. Must be aware of all the elements developed at the management level in the business entity. Must be actively involved in the enterprise integration program, and see themselves as potential beneficiaries of the development of the program. At least till the end of the Master Plan ŽPhase IV., the members of this team may have to spend half of their time in the completion of the activities of the program. Must be capable to link the strategy of the entity Žas defined by the Steering Committee. with the operations carried out within it. Mainly in the SME, the staff of the enterprise is not enough to cover all the required aspects. Therefore, external consultants must be involved in and must support some activities. Often, external people must participate with the EIT, and must help to define correctly the relations between strategy and operations.

Sponsor

Steering Committee ŽSponsor included.

Enterprise Integration Team ŽLeader and Sponsor included.

Consultants

more concrete aspects for the selected entity Žas for example, the relationships between the entity and other parts of the enterprise or other elements.. It will also be in charge of the establishment of the importance of the entity in the whole enterprise. Žv. The EIT is created with this information. The results of the first phase of the proposal must be: Ži. The definition of the business entity where the

program will be developed. Žii. The acceptance by the enterprise of the Enterprise Integration Program in the selected business entity. Žiii. The definition of the relation with the entity’s environment. Živ. The creation of the working teams ŽLeader, Sponsor, Steering Committee, and EIT.. Žv. The identification of the strategic level of the business entity for the enterprise. Žvi. The clear establishment of the conse-

162

A. Ortiz et al.r Computers in Industry 40 (1999) 155–171

quences the program will have on the human resources of the enterprise. It must be taken into account that even in this preliminary phase, the impact in terms of training and learning programs, new roles, effects on the staff of the enterprise, etc. must be analysed. Even though the first phases of the methodology are carried out mainly by the high level staff of the company, it is obvious that the program is due to fail without the adequate involvement of intermediate and operative level of the enterprise. 4.1.1.2. Conceptualisation. In this second step, the strategic framework in which the business entity defined in the previous step evolves, will be established. It is important to note that this step is developed within the defined business entity. For instance, if the program is developed in an area of an enterprise, the strategic framework will be defined in the scope of the strategy of the enterprise. If the business entity is formed by the union of the enterprise and a supplier Žextended business entity if the union is stable or virtual business entity if the union exists only during a limited period., the concepts will be developed for the union. The strategy defined here is used as a guideline for the remaining steps of the methodology, so that any action developed in any activity of the enterprise must be oriented towards the covering of the strategic objectives. Thus, for example, if the enterprise strategy to be developed for the business entity focuses on being leaders in prices, all the actions developed in the activities of the processes within this business entity must tend to gain this strategic position. The sequence of activities for this phase is the following: Ži. The Steering Committee must generate documentation for all the strategic concepts related with the enterprise Žmission, vision, strategies, critical success factors, etc... Žii. With the EIT, the Steering Committee must define all the strategic concepts for the selected business entity, so that a consistency can be reached between both the enterprise level and the business entity level. Results of Phase II: Ži. The documentation that will be used as a reference to reach the objectives of the Enterprise Integration Program applied to the business entity. Žii. A key point is the establishment of a measure procedure in order to measure ‘how

well Žor how bad. things are being done’. It is necessary to measure the fulfilment of objectives, goals, and how the critical success factors are evolving. The elements to be measured can vary from one enterprise to another. The members of the Steering Committee and the EIT must decide which parameters should be measured and how, based on their extensive knowledge of both the enterprise and the business entity. Žiii. Because of the importance of the information generated in this phase, it is essential for the documents produced to be validated by the management of the enterprise. 4.1.1.3. Process definition. The objective of this phase is the description of the business processes currently existing and to be developed in the business entity targeted by the program. It deals with the macro level description of these processes. The EIT and the owners of the processes defined are responsible for the execution of this phase. The sequence of activities has two parts, one related with the generation of the AS-IS model, and the other one with the generation of the TO-BE model. Ž1. If the AS-IS model is dealt with first, the EIT must identify the processes existing within the business entity and define the owners of the processes. Then the model will be defined. Its analysis will only be carried out once Phase II has been completed. Ž2. If the TO-BE model is dealt with, once the Conceptualisation phase is completed, the EIT and the external staff must identify and design these TO-BE processes. No fixed chronological order has been established for the sequence of generation of the AS-IS and TO-BE models. We assume that this sequence depends on several factors and in each concrete case, we will have to cope with it differently. For instance, sometimes it is known that the current processes are not valid and an important change is needed. In this case, the sequence of definition should be first TOBE, and then AS-IS. It may happen that the current processes are not completely known and it is known that the change must be progressive. In this case, the sequence should be first AS-IS, then TO-BE. Results of Phase III: Ø The AS-IS model, Ø The list of the processes existing in the entity, Ø The identification of the current objectives,

A. Ortiz et al.r Computers in Industry 40 (1999) 155–171

Ø The definition of how each process support the strategy of the entity, Ø The classification of processes distinguishing between strategic, fundamental ŽKey and Key Critical., support w4x, Ø The identification of the parameters that enable to measure the results of a process Žefficiency, flexibility, etc.., Ø The macro level graphical representation of the processes, identifying the activities carried out in each one of them, as well as inputs, outputs, events and relationships, Ø The list of the deficiencies of the analysed processes, Ø A first approach towards the acceptance Žor rejection. of each process in the framework of the entity, Ø The TO-BE model, Ø The definition of the processes which will lead to the fulfilment of the objectives of the entity, Ø The definition of the objectives of each process, Ø The graphical representation of the processes identifying the activities to be developed in each one of them, as well as inputs, outputs, events and relationships, Ø The definition of how each process supports the strategy of the entity Žand how this one supports the strategy of the enterprise., Ø The definition of the parameters that will enable to measure the results and the evolution of the processes. It is necessary to insist on the point that each one of the processes does not have to be studied in depth. The objective is to reach a macro level description Žusually based on a graphical tool. of the AS-IS and TO-BE models. Generally, other significant data that helps in the identification, documentation and analysis of processes is added to the graphical models. Therefore, this will be the point that will link the Conceptualisation with the Operation, or as defined in w13x the point that will link strategy with operational effectiveness. 4.1.1.4. Action Plan deÕelopment. Once the processes affected by the Enterprise Integration Program Žboth in the AS-IS and TO-BE models. have been described, it is now time to establish a Master Plan w7x to cope with the transition between the two

163

models. The aim of this plan is to define an adequate action framework that enables to describe how the training of the staff, the culture of the enterprise, the opportunity, etc., should be. The steps that have to be carried out in this phase are: Ži. Checking of the different processes of the AS-IS and TO-BE model based on the strategic objectives, and identification of the differences between them. Žii. Proposal of different migration paths. Žiii. Identification of the potential benefits of each path, Živ. Selection of the path and establishment of priorities, taking into account the type of each process, as well as the resources they consume, the Action Plan that will be followed Ževolutionary or revolutionary. and other additional concepts that may appear. The development of an adequate plan is essential for the good development of the program. This plan can establish on which processes we wish to make a re-engineering program, and on which a continuous engineering one. It can determine the exact sequence of actuation on the processes, first of all acting on the ones considered to be more important and then on the others, or on all of them in parallel, and so on. Žv. Once the establishment of priorities has been carried out, the Process Teams, i.e., the people that will be in charge of the transition from one model to the other, are defined. The Process Owner is also defined; hershe will be the person that assumes the responsibility of the process. It is important to define the Process Teams after identifying the actuation line, as the requirements for the people adapted to carry out an evolutionary approach are different from those adapted to a revolutionary one. Žvi. Once the teams have been defined, it is necessary to define the Management of Change. It deals mainly with the development of training courses for the staff and stresses the necessity for the enterprise to define organisational and cultural changes in order to adapt itself to the circumstances configured by the Enterprise Integration Program. Žvii. Definition of the standards the enterprise decides to use. Žviii. Development of the Action Plan Document. This document is used to finish Phase IV and gathers all the information and aspects that have been generated from the beginning of the program. Therefore, it must define for the management of the enterprise ŽSteering Committee. which are the selected approaches in order to reach the

164

A. Ortiz et al.r Computers in Industry 40 (1999) 155–171

integration of the entity. Žix. This phase ends with the delivery of the Action Plan Document to the management of the enterprise. Then management can choose one of the three following paths: Ø Adopt the proposal. In this case, the remaining phases will be developed. Ø Reject the proposal. In this case, the Enterprise Integration Program will be stopped either temporarily or forever. Ø Request more information. The Steering Committee may not be sure of the decision to take and may therefore request further information to take a decision. In this case, the requested information must be given, until one of the two other decisions is taken. Results of Phase IV: the generation of the Action Plan Document. This document is used to define the ‘current state of the problem’, what solutions are proposed and what do each solution imply. Moreover, it is used as a framework to do all the successive phases. This introduces a key element for the success of the program: for the first time, the management of the enterprise has a real quantification of the problem. Based on it, management can involve itself with the program after its state of analysis is sufficiently advanced to understand the real problems, and before the cost generated by the program becomes unaffordable if the program is to be stopped. 4.1.2. Detailed leÕel For the Requirements Definition, Design Specifications and Implementation Description phases, it was decided to use the methodology provided by CIMOSA. Therefore, only an overview will be given; a more detailed description can be found in Ref. w28x. 4.1.2.1. Requirements Definition. This phase focuses on the definition by the user of the characteristics of each one of the activities of each one of the processes. At this level, the user structures all the information in order to develop a model of the activity, taking into account both the functional, informational, resource and organisational aspects. Although this phase is mainly centred on ‘technical’ aspects, it is important to note that in the Require-

ments Definition, other aspects related for instance with the learning and training needs can and should be introduced by the user. The activities to be developed in this phase are those introduced by CIMOSA w6,28x: Ø Domain Establishment, Ø Behaviour Analysis, Ø Operational Analysis, Ø Information Analysis, Ø Resource Analysis, Ø Organisational Analysis, Ø Consistency Checking. The results of the Requirements Definition phase are: Ži. The model that represents the definition of the processes ŽDomain Processes. according to the vision of the user of the system is built. This model is a detailed one, but does not have to be complete, nor does it have to be able to be directly implemented, as it corresponds to the vision of the user Žthese design and implementation issues are posed in the next phases.. Nevertheless, it is an integrated model in which each activity of the entity has been defined based on four aspects Žfunction, information, resources and organisation.. The interaction of the activity with the other activities has also been analysed. Žii. In this phase, within our work, we have stressed on the necessity to Ž1. train the user in the aspects related with CIMOSA and Ž2. assist himrher in the application of the methodology. For the first issue, two learning tools ŽCILT and VR-CILT. have been developed in order to teach the concepts and procedures of the CIMOSA approach to the user. For the second one, we developed the GIPMODEL tool. All these tools will be describe later Žsee Section 4.3. 4.1.2.2. Design Specifications. This phase deals with the identification and design Žif the current systems are not adequate. of the systems that will be capable to cover the requirements defined by the user in the previous phase. Two aspects are desired in this phase: the generation of the models in an independent format Ži.e., without taking into account concrete aspects, as for instance the exact type of machine used to carry out an activity. and that the result can be processed by a computer Žas it can contain alternative paths, which can be evaluated by simulation techniques.. Similarly, in this phase, actions that lead to the improvement of the working conditions,

A. Ortiz et al.r Computers in Industry 40 (1999) 155–171

165

design of courses, creation of maintenance teams, creation of quality teams, etc., can be defined. The steps to be carried out in this phase are: Ø Requirement Definition phase Consolidation, Ø Behaviour Design, Ø Operational Design, Ø Information System Design, Ø Resource System Design, Ø Organisational System Design, Ø Information Technology System Design, Ø Design Verification. The result of this phase is the design of one or more models that will cover the expectations of the users of the system and will thus, reach the established objectives. The models can be simulated in order to see how they operate and the best one has to be selected. A modelling tool and simulator based on the CIMOSA concepts and called qFirstSTEP is available commercially. We think that an interesting and efficient issue could be the definition of an interface between the data in the GIPMODEL tool and qFirstSTEP, so that data can be exported from one tool to the other in an automated way. Currently, this issue is under development and it will help us to link the modelling and simulation environments in a straightforward way. Additionally, the schemas for databases, information systems, etc., necessary for the entity are generated.

have to deal with their installation in the enterprise. Information systems will be installed, activities will be located and assigned to persons, machinery will be set-up, etc. In order to define the temporal plans for the build of the entity, any traditional technique for the management and control of projects ŽPERT, CPM, etc.. can be used. It will be necessary to check that everything that has been defined in the Design Specification phase Žand updated with the information of the Implementation Description phase. is being carried out according to the expected scheduling. The development of new software tools, the acquisition of material, its installation and relocation, will be controlled. Another important issue is to provide users with the courses and instructions to perform their work correctly.

4.1.2.3. Implementation Description. This phase deals with the selection of the most adequate current products and techniques to provide in an integrated and effective way, the elements being able to execute the processes Žas they were defined by the users in the Requirements Definition phase.. The result of this phase will be a model that will represent all the elements chosen to operate the business entity for which the Enterprise Integration Program has been developed. This model will integrate all the aspects defined in the proposal. Moreover, mechanisms have been established in order for the technological elements to work according to standards, and for the human resources to be adequately prepared Žthanks to the training and learning programs, and motivation actions..

4.1.2.6. Disposal. In this phase, the actuation criteria is established in order to decide when the business entity and some of its processes are no longer useful for the enterprise and must therefore be eliminated. This aspect is especially important for new enterprise paradigms like virtual enterprises. For virtual enterprises, a fast set-up of the business entity is one of the basic requirements for success: similarly, the same condition is true for the disposal of this business entity. The completion of these phases will lead to an adequate development of the Enterprise Integration Program in the enterprise. The architecture used in the proposal will be described next.

4.1.2.4. Build. Once the adequate elements have been selected to comply with the requirements, we

4.1.2.5. Operation. In order to reach the objectives defined for the business entity, this phase includes carrying out all the activities that have been specified with the resources that have been installed in the previous phase. In this phase is where change and improvement actions will be initiated. Therefore, from this phase, Enterprise Integration sub-programs will be launched, which will lead to the re-execution of some of the steps of the methodology.

4.2. Architecture The methodology explains how to cope with and develop in a way that is adequate for the enterprise, Enterprise Integration Programs. Additionally, next

166

A. Ortiz et al.r Computers in Industry 40 (1999) 155–171

to the methodology, it is necessary to have an architecture that provides the elements to structure and represent the enterprise from the Enterprise Integration perspective w8x. As mentioned earlier, it was decided to adopt the architectural point of view posed by CIMOSA, which is based on building blocks w29x, i.e., a construct used to describe any kind of element of the enterprise in a consistent and semi-formal way. This approach presents several advantages: Ži. It generates a common and finite language that enables a coherent and intelligible communication inside the whole enterprise and between enterprises. Thus, once the enterprise staff has been ‘educated’ in the use of this language, many problems derived from the bad communication produced by the use of different languages disappear. Žii. It facilitates the reusability and redesign. Indeed, once a set of building blocks has been generated, it is quite easy to redesign or reuse it. This aspect will lead to a diminution of design, set-up and release times because usually, many activities often appear in more than one enterprise process and because when processes change, they usually do not change completely and a part of them still remains unchanged. Žiii. The definition of three particularisation levels within the building blocks ŽGeneric, Partial and Particular Levels. leads to a progressive enrichment, which leads from the Generic building blocks to the Particular Enterprise Models Ževentually, through the Partial Models.. Therefore, an initial base Žthe Generic Blocks or Partial Blocks when a particularisation has already

been made. is available which helps to apply the proposal to concrete enterprises efficiently. Živ. From the Partial Architectures, it is possible to configure libraries of enterprise sectors, which can bring extremely valuable information to face projects in a faster and less expensive way. However, the architecture provided by CIMOSA does not cover all the phases Žfrom the identification of the business entity to its disposal. defined in the methodology of the proposal. It does not cover neither some aspects introduced in the proposal, such as definition of strategies, policies, efficiency parameters, learning programs, master plans, actions for the continuous improvement of processes, etc. Although some of the CIMOSA constructs can be used to describe elements that appear in phases of the life cycle of the proposal for which they were not specifically designed Že.g., Identification, Conceptualisation, etc.. w23x, in our proposal, we have preferred to use another approach. We decided to use the CIMOSA constructs exclusively for what they were designed, i.e. in the phases covered by the CIMOSA approach Ži.e., Requirements Definition, Design Specifications and Implementation Description.. For the other phases, we have defined either CIMOSA-like building blocks, or additional mechanisms Že.g., the checklists.. Furthermore, we have defined the mechanisms necessary to feed in a coherent way, the CIMOSA constructs with the information generated in the macro level. Thanks to this, we provide a clearer and more structured approach to the users.

Fig. 6. Building block Conceptualisation phase.

A. Ortiz et al.r Computers in Industry 40 (1999) 155–171

Let us consider an example in order to understand better the approach. In Fig. 6, we show one part of the building block designed for the Phase II of the proposal ŽConceptualisation.. For each one of the represented items, we must annex one or more documents, as for instance, the strategy to be followed by the business entity where the Enterprise Integration Program is being developed. These strategic concepts that have to be covered by the business entity will be derived in successive phases of the proposal and will be integrated in the ObjectivesrRestrictions building block ŽFig. 7. provided by CIMOSA in the Requirements Definition phase. Similarly, the constructs used for the high level modelling of business processes in the macro level can derive into the related CIMOSA constructs used in the detailed level, adding more detailed information whenever necessary. Based on this approach, we manage to enhance the scope maintaining a structure coherent with the current CIMOSA proposal. This approach has been followed both for the strategic phases and for the operative ones, generating two architectural extensions, which enables an adequate application of the

167

architecture to the phases of the methodology ŽFig. 8.. 4.3. Tools The other element introduced by the proposal are the tools. For the application of the methodology and architecture that reach the integration of the enterprise, it is necessary to have the required tools that: Ž1. Support the concepts, constructs and mechanisms, Ž2. Facilitate both the application of concepts and the management and maintenance of the models being developed in the real world application of the described proposal. Moreover, it is necessary to build learning tools that provide a comprehensive description of the concepts to be used. These tools must take into account the requirements and profiles of the users of the enterprise at the different levels of use of the methodology and the architecture. If this kind of tools is not provided, the Enterprise Integration Program will have little success chances, as the user must be involved actively in its development w30,31x.

Fig. 7. Link between new building block and CIMOSA building block.

168

A. Ortiz et al.r Computers in Industry 40 (1999) 155–171

Fig. 8. Architectural proposal. CIMOSA extension.

It was decided to focus only on the tools that deal with the detailed level of the methodologies. No tools were developed to support the macro level. Several reasons justify this decision: - In the first phases Žmacro level. of the methodology, the amount of information with which one works is small, and is mainly descriptive. - The generation of Process Flow Diagrams in the macro level can be carried out with common commercial tools Že.g., qABC Flowchart, qFirstSTEP, qVisio, etc... Therefore, it is not necessary to develop similar tools. - In the detailed level phases Ži.e., from Phase V., the amount of information to collect or generate is much bigger, and needs computer support. - In the detailed level, more users are involved in the program. Therefore, a computer support will contribute to the efficient completion of the phases and will add ease of use for the users. In order to cover these aspects in the detailed level phases, a computer tool called GIPMODEL ŽGestion ´ Integrada de Procesos-Modelizacion; ´ in english Modelling and Management of Integrated Processes. has been developed. This tools aims to give a computer-assisted modelling support to the applica-

tion of the proposal. Apart from providing the support for the building of enterprise models, it guides the user in the use of the proposed methodology, therefore reaching several of the defined objectives. As we have said, additionally and in order to involve the user in the application of the proposal, tools were developed to describe and teach himrher the concepts and aspects of the proposal. We focused on presenting them in a friendly way, and motivating the user to be more involved in the Enterprise Integration Program. Two computer multimedia and virtual reality based computer tools called CILT ŽCIMOSA Learning Tool. and VR-CILT ŽVirtual Reality-CIMOSA Learning Tool. were developed. However, it is important to point out that the objective is not computerisation. It is the integration of the enterprise. The computerisation will only be important as long as it supports adequately, the integration process. As we have said, the tools do not cover all the phases of the methodology and architecture. In Fig. 9, we can observe the areas they cover. We can note that, although GIPMODEL also supports data related with concepts generated in other phases Žobjectives, teams, etc.., it acts mainly in the detailed modelling

A. Ortiz et al.r Computers in Industry 40 (1999) 155–171

169

Fig. 9. Tools supporting the proposal.

phase ŽRequirements Definition and Design Specification. of the processes defined in the previous phases of the methodology. Additionally, it provides data for the successive phases of the proposal. The CILT and VR-CILT tools cover the conceptual aspects related with the CIMOSA proposal ŽRequirements Definition, Design Specification and Implementation Description phases..

5. Conclusion In this work, we have introduced a proposal that combines the most positive aspects of CIMOSA and PERA, two of the most well-known and important proposals in the field of EI, providing additional elements whenever necessary, in order to make the approach consistent, complete and effective. It was stated that it is necessary to cover at least the aspects related with vision, enterprise processes, people and technologies in an Enterprise Integration Program. For this purpose, we defined a methodology, architecture and tools, that adequately integrate users with these topics in order to develop a program in an enterprise. This proposal covers the whole life

cycle of a program following a top-down iterative approach based on a Business Process point of view. Two major levels were defined, each one of them divided into phases. The first level is related with strategic, analysis, and process design aspects from a management perspective. It includes the description of the AS-IS and TO-BE models, the description of the different migration paths, and ends with the Master Plan, which defines the action lines for the remaining phases. The second level deals with the detailed modelling of the processes defined in the previous phases, as well as with the build and management of the operation of the system. In the proposal w4x, all the phases and their supporting architectural constructs are described in a detailed way. Tools are also provided both for the modelling activities and for the integration of the involved staff with the concepts and techniques used. The proposal has been applied in several enterprises both industrial Žtiles enterprise w32x. and service Žcomputer components distribution.. The results achieved so far provide a first validation of the usefulness of the proposal. Several new pilots are currently in project. They will help to further refine and validate the approach in order to enhance and emphasise some of its aspects.

170

A. Ortiz et al.r Computers in Industry 40 (1999) 155–171

In order to enhance the applicability of the proposal, several future R & D topics must be also addressed, mainly: - The definition and management of capabilities, fundamentally from a human perspective, - The adequate management of change. The work carried out must be consistent with future proposals developed by the main Enterprise Integration Programs ŽCIMOSA Association e. V, PERA Users Consortium, IFACrIFIP Task Force on EI, ISO, CEN, etc...

w10x

w11x w12x

w13x

Acknowledgements This work has been developed in the framework of a Project funded by the Comision ´ Interministerial de Ciencia y Tecnologıa ´ ŽCICYT., titled ‘‘Software de Integracion ´ de la Gestion ´ de Empresas Industriales, adaptacion ´ de las Arquitecturas de Sistemas Abiertos y a las Metodologıas ´ GRAI e IMPACS. Aplicacion ´ a las PYMES’s Valencianas’’. Ref. TAP95-0880.

w14x

w15x w16x w17x w18x

w19x

References w1x K. Kosanke, Enterprise Integration—international consensus: a Europe–USA initiative, in: K. Kosanke, J.G. Nell ŽEds.., ´ ICEIMT97, International Conference on Enterprise Integration and Modelling Technology, Springer-Verlag, Torino, Italy, October 1997, pp. 64–74. w2x T.J. Williams, PERA Methodology: I. International Workshop In Business Integration, Valencia, Spain, July 1997. w3x F.B. Vernadat, Enterprise Modelling and Integration: Principles and Application, Chapman and Hall, London, 1996. w4x A. Ortiz, Propuesta para el Desarrollo de Programas de Integracion ´ Empresarial. Aplicacion ´ a una Empresa del Sector Ceramico, PhD Thesis, Valencia, Spain, 1998. ´ w5x Esprit Consortium AMICE ŽEds.., CIMOSA: Open System Architecture for CIM, Springer-Verlag, Berlin, 1993. w6x CIMOSA Association e.V., CIMOSA. Open System Architecture for CIM. Technical Baseline, Boblingen, Germany, ¨ 1996, private publication. w7x T.J. Williams, ŽEd.., Guide to master planning and implementation for enterprise integration programs, Technical Report 157, Purdue Laboratory for Applied Industrial Control, Purdue University, West Lafayette, IN, June 1994. w8x D. Shorter ŽEd.., An evaluation of CIM-modelling constructs —evaluation report of constructs for views according to ENV 40 003, Computers in Industry 24 Ž2–3., 1994, pp. 159–236. w9x G. Doumeingts, Methode GRAI: Methode de Conception des

w20x w21x w22x

w23x

w24x

w25x w26x

Systemes de Productique, These d’Etat en Automatique, Universite de Bordeaux 1, Bordeaux, France, 1984. R. Jochem, K. Mertins, W. Sussenguth, An object oriented ¨ method for integrated enterprise modelling as a basis for enterprise coordination, in:. C.J. Petrie ŽEd.., Enterprise Integration Modelling. Proceedings of the First International Conference, MIT Press, 1992, pp. 249–258. C.J. Petrie ŽEd.., Enterprise Integration modelling, Proceedings of the First International Conference, MIT Press, 1992. K. Kosanke, J.G. Nell ŽEds.., Enterprise engineering and integration: building international consensus, Proceedings of ICEIMT International Conference, Springer-Verlag, Berlin, 1997. M. Porter, What is strategy?, Harvard Business Review. November–December 1996. T.J. Williams, The needs of the field of integration, Architectures for Enterprise Integration, Chap. 3, Chapman and Hall, London, 1996. M. Hammer, J. Champy, Re-engineering de Corporation, Harper Collins, 1993. J. Harrington, Business Process Improvement, McGraw-Hill, New York, 1993. T. Davenport, Process Innovation, Harvard Business School Press, 1993. F. Vernadat, Enterprise modelling languages, in: K. Kosanke, ´ J.G. Nell ŽEds.., ICEIMT97, International Conference on Enterprise Integration and Modelling Technology, SpringerVerlag, Torino, Italy, October 1997, pp. 212–224. K. Kosanke, Enterprise integration and standardisation, in: K. ´ International ConferKosanke, J.G. Nell ŽEds.., ICEIMT97, ence on Enterprise Integration and Modelling Technology, Springer-Verlag, Torino, Italy, October 1997, pp. 613–623. P. Bernus, L. Nemes, T.J. Williams, Architectures for Enterprise Integration, Chapman and Hall, London, 1996. IFIP-IFAC Task Force, GERAM, The Generalised Enterprise Reference Architecture, Version 1.3, 1997. K. Kosanke, Process oriented presentation of modelling methodologies, modelling and methodologies for Enterprise Integration., in: Modelling and Methodologies for Enterprise Integration, Proceedings of the IFIP TC5 Working Conference on Models and Methodologies for Enterprise Integration, Queensland, Australia, November 1995, Chapman and Hall, London, 1996, pp. 45–55. K. Kosanke, F.B. Vernadat, T.J. Williams, Manufacturing enterprise modelling with PERA and CIMOSA, Proc. Manufacturing Systems: Manufacturing Modelling, Management ´ ., Vienna, Austria, 5–7 February, 1997. and Control ŽMIM97 T.J. Williams, The Purdue Enterprise Reference Architecture, Instrument Society of America, Research Triangle Park, NC, 1992. T.J. Williams, The Purdue Enterprise Reference Architecture, Computers in Industry 24 Ž2 to 3. Ž1994. 141–158. G.A. Rathwell, T.J. Williams, Use of the Purdue Enterprise Reference Architecture and methodology in industry Žthe Fluor Daniel example., Modelling and Methodologies for Enterprise Integration, Chapman and Hall, London, 1996, pp. 12–44.

A. Ortiz et al.r Computers in Industry 40 (1999) 155–171 w27x F. Vernadat, CIMOSA: enterprise modelling and Enterprise Integration using a process-based approach, in: H. Yoshikawa, J. Goossenaerts ŽEds.., Information Infrastructure Systems for Manufacturing, North-Holland, Amsterdam, 1993, pp. 65–84. w28x M. Zelm, F. Vernadat, K. Kosanke, The CIMOSA business modelling process, Computers in Industry 27 Ž1995. 123– 142. w29x H.R. Jorysz, F. Vernadat, CIMOSA: Part 2. Information View, International Journal of Computer Integrated Manufacturing 3 Ž3. Ž1990. 157–167. w30x R.E. Giachetti, A. Kusiak, K.T.K. Toh, M. Zelm, A human factors taxonomy and human modelling in enterprises, Workshop 1, Working Group 1., in: K. Kosanke, J.G. Nell ŽEds.., ´ ICEIMT97, International Conference on Enterprise Integration and Modelling Technology, Springer-Verlag, Torino, Italy, October 1997, pp. 75–81. w31x H.T. Goranson, M. Fox, B. Katzy, T.J. Williams, D. Wisnosky, Human factors and Enterprise Integration, Workshop 1, Working Group 2, in: K. Kosanke, J.G. Nell ŽEds.., ´ ICEIMT97, International Conference on Enterprise Integration and Modelling Technology, Springer-Verlag, Torino, Italy, October 1997, pp. 82–88. w32x A. Ortiz, et al., Building a production planning process with an approach based on CIMOSA and workflow management systems, Computers in Industry, this issue. Lario Esteban, Francisco-Cruz is a professor in operations management and operations research at the Higher School of industrial engineering, Head of the Research Group on Management and Manufacturing Engineering ŽGIP. and is the head of the Business Management Department at the Polytechnic University of Valencia. He has received his PhD in industrial engineering from Polytechnic University of Cataluna, ˜ Barcelona. He was professor at the MBA EGEI and its director, at the MBA Ford Espana-Anglia Univer˜ sity-UPV and member of its executive committee. He is a formal member of the Spanish Centre for Logistics, the Spanish committee of the IFAC and the SEIO. He has published several papers in: FUCAM, INRIArIEEE, EUROIV, EUROSIM, AUGRAI, EURO-INFORMS. He is a Project leader of the TAP 92-0543, ŽManufacturing management system in the metal mechanic industry. Group technology application on planning and programming in manufacturing, using simulation to evaluate the performance of the system., and the TAP-95-0880: ŽIntegration software for management industrial companies, updated to the open architectures and methodologies GRAI and IMPACS., funded by the Spanish Government, and is responsible of the UPV group that is member of the Project ESPRIT SCHUMANN ŽSupply Chain Uncertainty Management Network Optimisation.. His research interests include production planning and control systems, business integration, supply chain management, group technology and hierarchical and methodology for the SMEs companies.

171

Ortiz Bas, Angel is an Assistant Professor in operations management and operations research at the Higher School of Industrial Engineering, and member of the Research Group on Management and Manufacturing Engineering ŽGIP.. He is an industrial engineer and he received his doctoral degree in industrial engineering from Universidad Politecnica de ´ Valencia in 1998. He works as consultant in several projects about Production Management, Information Systems and Enterprise Modelling and Integration in Metal Mechanic, Ceramic and Automotive Enterprises. He is a member of the GIP Research Group. He works as a Researcher in three Spanish Government Projects ŽCICYT. and one ESPRIT Project. He is a teacher in the Polytechnic University of Valencia and in the FORD Spain Industrial Engineer School. He also teaches in several Masters ŽMBA.. His major research interests areas are Production Planning and Control, Enterprise Integration, Information Management, Business Process Modelling. He has several papers in books and conferences in these fields. Ros Mcdonnell, Lorenzo is a lecturer in management information systems at the Higher School of Computer Engineering and director of Master Program in Health management Systems ŽMISA.. He received his PhD in industrial engineering from Polytechnic University of Valencia, and is member of the Association and College of Industrial Engineers. He has been active for several years as professional manufacturing engineer in both industrial and consulting firms, and has been involved in the development of computer integrated manufacturing systems in SMEs. He has published a number or papers in computer science and production engineering areas. His research interests include the application of production planning and control systems to manufacturing industry.