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
´ e Ingenierıa
Grupo de Gestion ´ (GIP), Departamento de Organizacion
´ de la Produccion ´ de Empresas, UniÕersidad Politecnica
´ de Valencia,
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 tion can be explained by several reasons. In the

authors’ opinion, some of the most relevant ones are:
Various approaches have been proposed for En- - The need to keep business operations aligned
terprise Integration w2,5,9,10,20,21x. The current need with strategy.
for enterprise-wide integration of business organisa- - The need to share enterprise information, Ždata
used for decision making..
- The need to interoperate, i.e., the need for the
)
Corresponding author. E-mail: [email protected] 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 organi- A good assessment of the importance and ad-
sation boundaries Žextended and virtual enter- vances reached recently can be found in the two
prises.. ICEIMT initiatives developed in 1992 w11x and 1997
- The need to generate models and tools which let w12x. Most of these proposals focus on the modelling
the users estimate the impact of the decisions of one or several aspects of the enterprise Žfunction,
taken in view of the globalisation of markets and decision, information, etc...
the need for fast and effective response of enter- From the analysis of the different proposals, it can
prises be observed that several relevant issues were not
The evolution in this field has gone through sev- addressed: Ži. Most of the proposals do not cover
eral phases: the initial objectives aimed to build the fully the handling of the enterprise strategy Žmission,
physical level integration; then the focus was on the vision, values, critical success factors, business
integration of applications; the integration of the strategies.. It should go beyond a simple definition
business level and finally of the full enterprise opera- prospective, and should make the strategy relevant in
tions were addressed ŽFig. 1.. the development of the whole Enterprise Integration
In the present work, a new definition is intro- Program w13x. Žii. The necessities in terms of model
duced for Enterprise Integration based on previous languages adapted for management levels Ži.e., user-
definitions w2,3x: friendly, simple and easy-to-use. have not been ade-
quately addressed. In these management levels, the
Enterprise Integration ŽEI. consists in facilitating emphasis is on simple models with information cen-
the material, information, decision and control tred on the parameters which allow management to
flows throughout the organisation, linking func- make decisions. But these models have to reflect
tions with information, resources, applications and reality, they should aggregate relevant information
people, with the aim of improving communica- especially on resources capabilities to allow predic-
tion, cooperation and coordination in the enter- tions on time behaviour of any model to support
prise, in order to manage the enterprise to behave decisions. Žiii. Often, the availability of methodolo-
as a whole and operate according to the strategy gies and tools in order to operate the models has
of the enterprise w4x. been disregarded. Živ. The impact of Enterprise Inte-
gration Programs on the human resources of the
To reach these objectives, all levels of enterprises enterprise has not been sufficiently studied. Neither
must be considered, from the most strategic to the has been studied, the effect of human resources on
most operative ones. They must evolve in a coherent the development of these proposals.
framework, which enables that actions and decisions The observed shortcomings have led to the devel-
made at each of the levels of the enterprise are taken opment of a proposal, in which it is understood that,
into account. 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. Addi-
tionally, the consequences of the program on the
human resources and the impact of the human re-
sources 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 archi-
tecture and tools. Therefore, these three elements
are the ones which make up the current proposal
Fig. 1. Enterprise Integration evolution w1x. Ž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: integration between the activities developed in the
Ži. a global and generic reference procedure which enterprise w15–17x,
shows the structure of the existing and projected - Using structured techniques,
system and Žii. the description and control of the - Developing enterprise applications, and
activities which lead, step by step, from the existing - Keeping in mind the role played by humans and
system to the future one; it takes into account the enterprise technologies.
evolution and specific limitations and presents evalu- One possibility to develop this vision was to
ation criteria about the behaviour of the system in create these elements from scratch. But this would
relation with several prospects Žeconomy, quality, have been a major mistake as it would have dis-
etc... carded all the existing work and know-how devel-
The architecture w3x is a finite set of interrelated oped by numerous R & D projects. Therefore, our
components put together to form a consistent whole position was to try to combine the most interesting
defined by its functionality. aspects of the existing proposals in terms of method-
Tools are the elements that allow users to apply ological, architectural and tool dimensions, and to
both the methodology and the architecture in a more add the necessary elements whenever required, i.e.,
efficient and easy way. In Enterprise Integration whenever the aspects concerned are not correctly or
Programs where the amount of aspects to be anal- completely covered by the considered proposals.
ysed is large, computerised tools are really necessary Several studies in which the different existing EI
in order for the user to be able to create, manage and approaches are analysed can be found in Refs.
reuse the generated models. w18,19x. Another very interesting survey is the one
carried out by the IFACrIFIP Task Force on archi-
tectures for EI w20x. In this work, a complete study of
the main EI architectures ŽOpen System Architecture
for Computer Integrated Manufacturing—CIMOSA,
2. Development framework
GRAI, Purdue Enterprise Reference Architecture—
PERA. was carried out, and brought important infor-
The approach presented is based on the necessity mation about the advantages, drawbacks and pending
to cover the whole life cycle of a business entity, areas in order to progress towards EI.
from its identification to its disposal: As a result of this work, the GERAM proposal
- Taking into account the strategy of the enterprise emerged w21x. GERAM has evolved from a compari-
Žvision., son grid to become a complete framework for com-
- Applying it to the business processes, as they are paring and checking the completeness of proposals
the ones which provide the higher congruency and 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 posal the most relevant aspects of both proposals,
applied Žit has no constructs and no methodology of introducing new elements whenever necessary.
its own. in an enterprise.
Merging the most relevant aspects of each of 3.1. The Purdue Enterprise Reference Architecture
these EI proposals was still a pending issue. This
was the rationale for the current proposal. PERA w24,25x is based on a detailed and prag-
matic methodology covering the whole life cycle of
an industrial project from inception to operation and
3. Basis of the proposal even system disposal ŽFig. 3.. From our perspective,
the most relevant aspects of this proposal are located
As a starting point, we defined the objectives to in the quality of its methodology, broad-range and
be fulfilled in the development of the proposal, and refined in diverse industrial applications w26x.
amongst which the following can be highlighted
Žsome of them are addressed by existing proposals 3.2. The Open System Architecture for Computer
but no proposal matches all of them.: Integrated Manufacturing
- To provide enterprises with an adequate ap-
proach to develop Enterprise Integration Programs CIMOSA w5,6x is an Open Systems Architecture
and re-engineering projects centred on business for EI which includes a powerful language for enter-
processes. prise modelling ŽFig. 4. and is aimed at model-based
- To support the complete life cycle for the con- integration w27,28x. It provides a life cycle, but it
sidered business entity, from its identification and does not cover the complete life cycle of a business
the identification of its strategic concepts, to its entity as it starts with the Requirements Definition
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 perspec-
tive, but they developed their approach under differ-
ent 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 modifica-
tion of some of the aspects of PERA and the devel-
opment of new aspects. In terms of the architectural
framework, the CIMOSA proposal was used wher-
ever adequate. New CIMOSA-like building blocks
were defined to complete the approach. Conse-
quently, we managed to integrate in a unique pro- 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

enterprises usually, these two levels must be distin-

guished because of economic aspects, aspects relat-
ing 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,
Fig. 4. CIMOSA constructs Žwithout organisation view.. - Conceptualisation,
- Process Definition,
- Master Planning.
phase and ends with the phase of Implementation
Description. The CIMOSA cube provides a consis-
tent 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.

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, strate-
gic 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 The proposal consists of three components: a
methodology are: Ž1. They can be developed in a methodology, an architecture, and tools. They are
short period of time in comparison with the usual described in more detail in the following sections.
duration of an Enterprise Integration Program, and
with a moderated consumption of resources. Ž2. They 4.1. Methodology
use a language and tools comprehensible by man-
agers and decision-makers, because the main objec- The methodology represents a users guideline for
tive is that managers design and analyse the business the development of Enterprise Integration Programs.
processes without a high level of detail, but linking We will describe each step of the proposed method-
them with the strategy of the enterprise, and the ology, distinguishing between the macro level and
parameters they must use to measure performance. the detailed level. However, the methodology can be
Ž3. They generate the AS-IS and TO-BE coarse used to support re-engineering programs as well.
models of the business processes of the enterprise. There can and should exist constant iteration be-
Ž4. They establish the guidelines to go from one tween the different steps of the methodology.
model to the other, both at the technical and human
level. Ž5. They develop all their work with a moder- 4.1.1. Macro leÕel
ated consumption of resources, as it must be taken in
account that they represent an overload for man- 4.1.1.1. Identification of the business entity. This
agers. first step consists of the identification of the scope of
The detailed level comprises six phases ŽFig. 5.: the Enterprise Integration Program to be developed.
- Requirements Definition, This scope must be clearly defined: it can be the
- Design Specifications, whole enterprise, a part of it, or even the enterprise
- Implementation Description, and some of its suppliers andror clients Žcustomer–
- Build, supplier chain..
- Operation, In this phase, the human labour necessary for the
- Disposal. development of the first phases of the program will
The detailed level is only carried out when the also be defined ŽTable 2.. The human teams are to be
program has been accepted and validated at the end composed of the Program Leader, the Program Spon-
of the macro level. This means that management has sor, the Steering Committee ŽSC., the Enterprise
a good knowledge of the objectives to fulfil and has Integration Team ŽEIT. and Žexternal. Consultants.
given a strong support to the program Žgorno-go The sequence of activities for this phase is the
decision according to budget, priorities, risk, etc... following: Ži. The Program Leader identifies and
The basic characteristics of this level are: documents the necessity and convenience of the
1. It focuses on the detailed construction of the development of an Enterprise Integration Program.
models of the processes to be restructured and Žii. The Program Leader involves the Program Spon-
designed. sor and convinces himrher that this is the adequate
2. It is data-centred, i.e., a considerable amount of working line. Žiii. The Sponsor and the Leader define
data has to be introduced in the process models. the initial business entity where the program will be
3. The processes are modelled with the required developed. The Program Leader helped by the peo-
Žhigh. level of details and are then built and ple hershe selects must carry out a preliminary
operated analysis that evaluates the costs of the program and
4. The cost Žhuman, economic, etc.. to develop the its potential benefits in the business entity. Only if
phases is much higher, but the work is being this analysis reveals that the application of the pro-
developed on a much more secure level as man- gram is due to produce significant benefits will the
agement has already adopted the program. program go on in the business entity. Otherwise,
In addition, the last phase of the system life cycle another one will be chosen. Živ. Once the business
is the disposal of the business entity. Table 1 sum- entity is defined, the Steering Committee will be
marises these characteristics. 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.
Sponsor 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.
Steering Committee Must be formed by members of the management of the enterprise.
ŽSponsor included. 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.
Enterprise Integration Must be formed by people who have high level responsibilities in the business
Team ŽLeader and Sponsor entity targeted by the program.
included. 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.
Consultants 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.

more concrete aspects for the selected entity Žas for program will be developed. Žii. The acceptance by
example, the relationships between the entity and the enterprise of the Enterprise Integration Program
other parts of the enterprise or other elements.. It in the selected business entity. Žiii. The definition of
will also be in charge of the establishment of the the relation with the entity’s environment. Živ. The
importance of the entity in the whole enterprise. Žv. creation of the working teams ŽLeader, Sponsor,
The EIT is created with this information. Steering Committee, and EIT.. Žv. The identification
The results of the first phase of the proposal must of the strategic level of the business entity for the
be: Ži. The definition of the business entity where 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 re- well Žor how bad. things are being done’. It is
sources of the enterprise. It must be taken into necessary to measure the fulfilment of objectives,
account that even in this preliminary phase, the goals, and how the critical success factors are evolv-
impact in terms of training and learning programs, ing. The elements to be measured can vary from one
new roles, effects on the staff of the enterprise, etc. enterprise to another. The members of the Steering
must be analysed. Even though the first phases of the Committee and the EIT must decide which parame-
methodology are carried out mainly by the high level ters should be measured and how, based on their
staff of the company, it is obvious that the program extensive knowledge of both the enterprise and the
is due to fail without the adequate involvement of business entity. Žiii. Because of the importance of the
intermediate and operative level of the enterprise. information generated in this phase, it is essential for
the documents produced to be validated by the man-
4.1.1.2. Conceptualisation. In this second step, the agement of the enterprise.
strategic framework in which the business entity
defined in the previous step evolves, will be estab- 4.1.1.3. Process definition. The objective of this
lished. It is important to note that this step is devel- phase is the description of the business processes
oped within the defined business entity. For instance, currently existing and to be developed in the busi-
if the program is developed in an area of an enter- ness entity targeted by the program. It deals with the
prise, the strategic framework will be defined in the macro level description of these processes. The EIT
scope of the strategy of the enterprise. If the business and the owners of the processes defined are responsi-
entity is formed by the union of the enterprise and a ble for the execution of this phase.
supplier Žextended business entity if the union is The sequence of activities has two parts, one
stable or virtual business entity if the union exists related with the generation of the AS-IS model, and
only during a limited period., the concepts will be the other one with the generation of the TO-BE
developed for the union. model. Ž1. If the AS-IS model is dealt with first, the
The strategy defined here is used as a guideline EIT must identify the processes existing within the
for the remaining steps of the methodology, so that business entity and define the owners of the pro-
any action developed in any activity of the enterprise cesses. Then the model will be defined. Its analysis
must be oriented towards the covering of the strate- will only be carried out once Phase II has been
gic objectives. Thus, for example, if the enterprise completed. Ž2. If the TO-BE model is dealt with,
strategy to be developed for the business entity once the Conceptualisation phase is completed, the
focuses on being leaders in prices, all the actions EIT and the external staff must identify and design
developed in the activities of the processes within these TO-BE processes.
this business entity must tend to gain this strategic No fixed chronological order has been established
position. for the sequence of generation of the AS-IS and
The sequence of activities for this phase is the TO-BE models. We assume that this sequence de-
following: Ži. The Steering Committee must generate pends on several factors and in each concrete case,
documentation for all the strategic concepts related we will have to cope with it differently. For instance,
with the enterprise Žmission, vision, strategies, criti- sometimes it is known that the current processes are
cal success factors, etc... Žii. With the EIT, the not valid and an important change is needed. In this
Steering Committee must define all the strategic case, the sequence of definition should be first TO-
concepts for the selected business entity, so that a BE, and then AS-IS. It may happen that the current
consistency can be reached between both the enter- processes are not completely known and it is known
prise level and the business entity level. that the change must be progressive. In this case, the
Results of Phase II: Ži. The documentation that sequence should be first AS-IS, then TO-BE.
will be used as a reference to reach the objectives of Results of Phase III:
the Enterprise Integration Program applied to the Ø The AS-IS model,
business entity. Žii. A key point is the establishment Ø The list of the processes existing in the entity,
of a measure procedure in order to measure ‘how Ø The identification of the current objectives,
 A. Ortiz et al.r Computers in Industry 40 (1999) 155–171 163

Ø The definition of how each process support the models. The aim of this plan is to define an adequate
strategy of the entity, action framework that enables to describe how the
Ø The classification of processes distinguishing be- training of the staff, the culture of the enterprise, the
tween strategic, fundamental ŽKey and Key Criti- opportunity, etc., should be.
cal., support w4x, The steps that have to be carried out in this phase
Ø The identification of the parameters that enable to are: Ži. Checking of the different processes of the
measure the results of a process Žefficiency, flexi- AS-IS and TO-BE model based on the strategic
bility, etc.., objectives, and identification of the differences be-
Ø The macro level graphical representation of the tween them. Žii. Proposal of different migration paths.
processes, identifying the activities carried out in Žiii. Identification of the potential benefits of each
each one of them, as well as inputs, outputs, path, Živ. Selection of the path and establishment of
events and relationships, priorities, taking into account the type of each pro-
Ø The list of the deficiencies of the analysed pro- cess, as well as the resources they consume, the
cesses, Action Plan that will be followed Ževolutionary or
Ø A first approach towards the acceptance Žor rejec- revolutionary. and other additional concepts that may
tion. of each process in the framework of the appear. The development of an adequate plan is
entity, essential for the good development of the program.
Ø The TO-BE model, This plan can establish on which processes we wish
Ø The definition of the processes which will lead to to make a re-engineering program, and on which a
the fulfilment of the objectives of the entity, continuous engineering one. It can determine the
Ø The definition of the objectives of each process, exact sequence of actuation on the processes, first of
Ø The graphical representation of the processes all acting on the ones considered to be more impor-
identifying the activities to be developed in each tant and then on the others, or on all of them in
one of them, as well as inputs, outputs, events parallel, and so on. Žv. Once the establishment of
and relationships, priorities has been carried out, the Process Teams,
Ø The definition of how each process supports the i.e., the people that will be in charge of the transition
strategy of the entity Žand how this one supports from one model to the other, are defined. The Pro-
the strategy of the enterprise., cess Owner is also defined; hershe will be the
Ø The definition of the parameters that will enable person that assumes the responsibility of the process.
to measure the results and the evolution of the It is important to define the Process Teams after
processes. identifying the actuation line, as the requirements for
It is necessary to insist on the point that each one the people adapted to carry out an evolutionary
of the processes does not have to be studied in depth. approach are different from those adapted to a revo-
The objective is to reach a macro level description lutionary one. Žvi. Once the teams have been de-
Žusually based on a graphical tool. of the AS-IS and fined, it is necessary to define the Management of
TO-BE models. Generally, other significant data that Change. It deals mainly with the development of
helps in the identification, documentation and analy- training courses for the staff and stresses the neces-
sis of processes is added to the graphical models. sity for the enterprise to define organisational and
Therefore, this will be the point that will link the cultural changes in order to adapt itself to the cir-
Conceptualisation with the Operation, or as defined cumstances configured by the Enterprise Integration
in w13x the point that will link strategy with opera- Program. Žvii. Definition of the standards the enter-
tional effectiveness. prise decides to use. Žviii. Development of the Ac-
tion Plan Document. This document is used to finish
4.1.1.4. Action Plan deÕelopment. Once the pro- Phase IV and gathers all the information and aspects
cesses affected by the Enterprise Integration Program that have been generated from the beginning of the
Žboth in the AS-IS and TO-BE models. have been program. Therefore, it must define for the manage-
described, it is now time to establish a Master Plan ment of the enterprise ŽSteering Committee. which
w7x to cope with the transition between the two 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 ments Definition, other aspects related for instance
the delivery of the Action Plan Document to the with the learning and training needs can and should
management of the enterprise. be introduced by the user.
Then management can choose one of the three The activities to be developed in this phase are
following paths: those introduced by CIMOSA w6,28x:
Ø Adopt the proposal. In this case, the remaining Ø Domain Establishment,
phases will be developed. Ø Behaviour Analysis,
Ø Reject the proposal. In this case, the Enterprise Ø Operational Analysis,
Integration Program will be stopped either tem- Ø Information Analysis,
porarily or forever. Ø Resource Analysis,
Ø Request more information. The Steering Commit- Ø Organisational Analysis,
tee may not be sure of the decision to take and Ø Consistency Checking.
may therefore request further information to take The results of the Requirements Definition phase
a decision. In this case, the requested information are: Ži. The model that represents the definition of
must be given, until one of the two other deci- the processes ŽDomain Processes. according to the
sions is taken. vision of the user of the system is built. This model
Results of Phase IV: the generation of the Action is a detailed one, but does not have to be complete,
Plan Document. This document is used to define the nor does it have to be able to be directly imple-
‘current state of the problem’, what solutions are mented, as it corresponds to the vision of the user
proposed and what do each solution imply. More- Žthese design and implementation issues are posed in
over, it is used as a framework to do all the succes- the next phases.. Nevertheless, it is an integrated
sive phases. This introduces a key element for the model in which each activity of the entity has been
success of the program: for the first time, the man- defined based on four aspects Žfunction, information,
agement of the enterprise has a real quantification of resources and organisation.. The interaction of the
the problem. Based on it, management can involve activity with the other activities has also been anal-
itself with the program after its state of analysis is ysed. Žii. In this phase, within our work, we have
sufficiently advanced to understand the real prob- stressed on the necessity to Ž1. train the user in the
lems, and before the cost generated by the program aspects related with CIMOSA and Ž2. assist himrher
becomes unaffordable if the program is to be stop- in the application of the methodology. For the first
ped. issue, two learning tools ŽCILT and VR-CILT. have
been developed in order to teach the concepts and
4.1.2. Detailed leÕel procedures of the CIMOSA approach to the user. For
For the Requirements Definition, Design Specifi- the second one, we developed the GIPMODEL tool.
cations and Implementation Description phases, it All these tools will be describe later Žsee Section 4.3.
was decided to use the methodology provided by
CIMOSA. Therefore, only an overview will be given; 4.1.2.2. Design Specifications. This phase deals with
a more detailed description can be found in Ref. the identification and design Žif the current systems
w28x. are not adequate. of the systems that will be capable
to cover the requirements defined by the user in the
4.1.2.1. Requirements Definition. This phase focuses previous phase. Two aspects are desired in this
on the definition by the user of the characteristics of phase: the generation of the models in an indepen-
each one of the activities of each one of the pro- dent format Ži.e., without taking into account con-
cesses. At this level, the user structures all the crete aspects, as for instance the exact type of ma-
information in order to develop a model of the chine used to carry out an activity. and that the result
activity, taking into account both the functional, can be processed by a computer Žas it can contain
informational, resource and organisational aspects. alternative paths, which can be evaluated by simula-
Although this phase is mainly centred on ‘technical’ tion techniques.. Similarly, in this phase, actions that
aspects, it is important to note that in the Require- 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, have to deal with their installation in the enterprise.
creation of quality teams, etc., can be defined. Information systems will be installed, activities will
The steps to be carried out in this phase are: be located and assigned to persons, machinery will
Ø Requirement Definition phase Consolidation, be set-up, etc.
Ø Behaviour Design, In order to define the temporal plans for the build
Ø Operational Design, of the entity, any traditional technique for the man-
Ø Information System Design, agement and control of projects ŽPERT, CPM, etc..
Ø Resource System Design, can be used. It will be necessary to check that
Ø Organisational System Design, everything that has been defined in the Design Spec-
Ø Information Technology System Design, ification phase Žand updated with the information of
Ø Design Verification. the Implementation Description phase. is being car-
The result of this phase is the design of one or ried out according to the expected scheduling. The
more models that will cover the expectations of the development of new software tools, the acquisition
users of the system and will thus, reach the estab- of material, its installation and relocation, will be
lished objectives. The models can be simulated in controlled. Another important issue is to provide
order to see how they operate and the best one has to users with the courses and instructions to perform
be selected. A modelling tool and simulator based on their work correctly.
the CIMOSA concepts and called qFirstSTEP is
available commercially. We think that an interesting 4.1.2.5. Operation. In order to reach the objectives
and efficient issue could be the definition of an defined for the business entity, this phase includes
interface between the data in the GIPMODEL tool carrying out all the activities that have been specified
and qFirstSTEP, so that data can be exported from with the resources that have been installed in the
one tool to the other in an automated way. Currently, previous phase.
this issue is under development and it will help us to In this phase is where change and improvement
link the modelling and simulation environments in a actions will be initiated. Therefore, from this phase,
straightforward way. Additionally, the schemas for Enterprise Integration sub-programs will be launched,
databases, information systems, etc., necessary for which will lead to the re-execution of some of the
the entity are generated. steps of the methodology.

4.1.2.3. Implementation Description. This phase deals 4.1.2.6. Disposal. In this phase, the actuation criteria
with the selection of the most adequate current prod- is established in order to decide when the business
ucts and techniques to provide in an integrated and entity and some of its processes are no longer useful
effective way, the elements being able to execute the for the enterprise and must therefore be eliminated.
processes Žas they were defined by the users in the This aspect is especially important for new enterprise
Requirements Definition phase.. paradigms like virtual enterprises. For virtual enter-
The result of this phase will be a model that will prises, a fast set-up of the business entity is one of
represent all the elements chosen to operate the the basic requirements for success: similarly, the
business entity for which the Enterprise Integration same condition is true for the disposal of this busi-
Program has been developed. This model will inte- ness entity.
grate all the aspects defined in the proposal. More- The completion of these phases will lead to an
over, mechanisms have been established in order for adequate development of the Enterprise Integration
the technological elements to work according to Program in the enterprise. The architecture used in
standards, and for the human resources to be ade- the proposal will be described next.
quately prepared Žthanks to the training and learning
4.2. Architecture
programs, and motivation actions..
The methodology explains how to cope with and
4.1.2.4. Build. Once the adequate elements have develop in a way that is adequate for the enterprise,
been selected to comply with the requirements, we 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 archi- been made. is available which helps to apply the
tecture that provides the elements to structure and proposal to concrete enterprises efficiently. Živ. From
represent the enterprise from the Enterprise Integra- the Partial Architectures, it is possible to configure
tion perspective w8x. libraries of enterprise sectors, which can bring ex-
As mentioned earlier, it was decided to adopt the tremely valuable information to face projects in a
architectural point of view posed by CIMOSA, which faster and less expensive way.
is based on building blocks w29x, i.e., a construct However, the architecture provided by CIMOSA
used to describe any kind of element of the enter- does not cover all the phases Žfrom the identification
prise in a consistent and semi-formal way. of the business entity to its disposal. defined in the
This approach presents several advantages: Ži. It methodology of the proposal. It does not cover nei-
generates a common and finite language that enables ther some aspects introduced in the proposal, such as
a coherent and intelligible communication inside the definition of strategies, policies, efficiency parame-
whole enterprise and between enterprises. Thus, once ters, learning programs, master plans, actions for the
the enterprise staff has been ‘educated’ in the use of continuous improvement of processes, etc.
this language, many problems derived from the bad Although some of the CIMOSA constructs can be
communication produced by the use of different used to describe elements that appear in phases of
languages disappear. Žii. It facilitates the reusability the life cycle of the proposal for which they were not
and redesign. Indeed, once a set of building blocks specifically designed Že.g., Identification, Conceptu-
has been generated, it is quite easy to redesign or alisation, etc.. w23x, in our proposal, we have pre-
reuse it. This aspect will lead to a diminution of ferred to use another approach. We decided to use
design, set-up and release times because usually, the CIMOSA constructs exclusively for what they
many activities often appear in more than one enter- were designed, i.e. in the phases covered by the
prise process and because when processes change, CIMOSA approach Ži.e., Requirements Definition,
they usually do not change completely and a part of Design Specifications and Implementation Descrip-
them still remains unchanged. Žiii. The definition of tion.. For the other phases, we have defined either
three particularisation levels within the building CIMOSA-like building blocks, or additional mecha-
blocks ŽGeneric, Partial and Particular Levels. leads nisms Že.g., the checklists.. Furthermore, we have
to a progressive enrichment, which leads from the defined the mechanisms necessary to feed in a coher-
Generic building blocks to the Particular Enterprise ent way, the CIMOSA constructs with the informa-
Models Ževentually, through the Partial Models.. tion generated in the macro level. Thanks to this, we
Therefore, an initial base Žthe Generic Blocks or provide a clearer and more structured approach to
Partial Blocks when a particularisation has already the users.

Fig. 6. Building block Conceptualisation phase.

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

Let us consider an example in order to understand architecture to the phases of the methodology
better the approach. In Fig. 6, we show one part of ŽFig. 8..
the building block designed for the Phase II of the
proposal ŽConceptualisation.. For each one of the 4.3. Tools
represented items, we must annex one or more docu-
ments, as for instance, the strategy to be followed by The other element introduced by the proposal are
the business entity where the Enterprise Integration the tools. For the application of the methodology and
Program is being developed. These strategic con- architecture that reach the integration of the enter-
cepts that have to be covered by the business entity prise, it is necessary to have the required tools that:
will be derived in successive phases of the proposal Ž1. Support the concepts, constructs and mecha-
and will be integrated in the ObjectivesrRestrictions nisms,
building block ŽFig. 7. provided by CIMOSA in the Ž2. Facilitate both the application of concepts and
Requirements Definition phase. Similarly, the con- the management and maintenance of the models
structs used for the high level modelling of business being developed in the real world application of the
processes in the macro level can derive into the described proposal.
related CIMOSA constructs used in the detailed level, Moreover, it is necessary to build learning tools
adding more detailed information whenever neces- that provide a comprehensive description of the con-
sary. cepts to be used. These tools must take into account
Based on this approach, we manage to enhance the requirements and profiles of the users of the
the scope maintaining a structure coherent with the enterprise at the different levels of use of the
current CIMOSA proposal. This approach has been methodology and the architecture. If this kind of
followed both for the strategic phases and for the tools is not provided, the Enterprise Integration Pro-
operative ones, generating two architectural exten- gram will have little success chances, as the user
sions, which enables an adequate application of the 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 tion of the proposal. Apart from providing the sup-
with the detailed level of the methodologies. No port for the building of enterprise models, it guides
tools were developed to support the macro level. the user in the use of the proposed methodology,
Several reasons justify this decision: therefore reaching several of the defined objectives.
- In the first phases Žmacro level. of the methodol- As we have said, additionally and in order to
ogy, the amount of information with which one involve the user in the application of the proposal,
works is small, and is mainly descriptive. tools were developed to describe and teach himrher
- The generation of Process Flow Diagrams in the the concepts and aspects of the proposal. We focused
macro level can be carried out with common on presenting them in a friendly way, and motivating
commercial tools Že.g., qABC Flowchart, qFirst- the user to be more involved in the Enterprise Inte-
STEP, qVisio, etc... Therefore, it is not necessary gration Program. Two computer multimedia and vir-
to develop similar tools. tual reality based computer tools called CILT
- In the detailed level phases Ži.e., from Phase V., ŽCIMOSA Learning Tool. and VR-CILT ŽVirtual
the amount of information to collect or generate is Reality-CIMOSA Learning Tool. were developed.
much bigger, and needs computer support. However, it is important to point out that the
- In the detailed level, more users are involved in objective is not computerisation. It is the integration
the program. Therefore, a computer support will of the enterprise. The computerisation will only be
contribute to the efficient completion of the phases important as long as it supports adequately, the
and will add ease of use for the users. integration process.
In order to cover these aspects in the detailed As we have said, the tools do not cover all the
level phases, a computer tool called GIPMODEL phases of the methodology and architecture. In Fig.
ŽGestion´ Integrada de Procesos-Modelizacion; ´ in en- 9, we can observe the areas they cover. We can note
glish Modelling and Management of Integrated Pro- that, although GIPMODEL also supports data related
cesses. has been developed. This tools aims to give a with concepts generated in other phases Žobjectives,
computer-assisted modelling support to the applica- 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 Specifi- cycle of a program following a top-down iterative
cation. of the processes defined in the previous approach based on a Business Process point of view.
phases of the methodology. Additionally, it provides Two major levels were defined, each one of them
data for the successive phases of the proposal. The divided into phases. The first level is related with
CILT and VR-CILT tools cover the conceptual as- strategic, analysis, and process design aspects from a
pects related with the CIMOSA proposal ŽRequire- management perspective. It includes the description
ments Definition, Design Specification and Imple- of the AS-IS and TO-BE models, the description of
mentation Description phases.. 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
5. Conclusion previous phases, as well as with the build and man-
agement of the operation of the system.
In this work, we have introduced a proposal that In the proposal w4x, all the phases and their sup-
combines the most positive aspects of CIMOSA and porting architectural constructs are described in a
PERA, two of the most well-known and important detailed way. Tools are also provided both for the
proposals in the field of EI, providing additional modelling activities and for the integration of the
elements whenever necessary, in order to make the involved staff with the concepts and techniques used.
approach consistent, complete and effective. The proposal has been applied in several enter-
It was stated that it is necessary to cover at least prises both industrial Žtiles enterprise w32x. and ser-
the aspects related with vision, enterprise processes, vice Žcomputer components distribution.. The results
people and technologies in an Enterprise Integration achieved so far provide a first validation of the
Program. For this purpose, we defined a methodol- usefulness of the proposal. Several new pilots are
ogy, architecture and tools, that adequately integrate currently in project. They will help to further refine
users with these topics in order to develop a program and validate the approach in order to enhance and
in an enterprise. This proposal covers the whole life 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 pro- Systemes de Productique, These d’Etat en Automatique,
posal, several future R & D topics must be also ad- Universite de Bordeaux 1, Bordeaux, France, 1984.
w10x ¨
R. Jochem, K. Mertins, W. Sussenguth, An object oriented
dressed, mainly: method for integrated enterprise modelling as a basis for
- The definition and management of capabilities, enterprise coordination, in:. C.J. Petrie ŽEd.., Enterprise Inte-
fundamentally from a human perspective, gration Modelling. Proceedings of the First International
- The adequate management of change. Conference, MIT Press, 1992, pp. 249–258.
w11x C.J. Petrie ŽEd.., Enterprise Integration modelling, Proceed-
The work carried out must be consistent with
ings of the First International Conference, MIT Press, 1992.
future proposals developed by the main Enterprise w12x K. Kosanke, J.G. Nell ŽEds.., Enterprise engineering and
Integration Programs ŽCIMOSA Association e. V, integration: building international consensus, Proceedings of
PERA Users Consortium, IFACrIFIP Task Force on ICEIMT International Conference, Springer-Verlag, Berlin,
EI, ISO, CEN, etc... 1997.
w13x M. Porter, What is strategy?, Harvard Business Review.
November–December 1996.
w14x T.J. Williams, The needs of the field of integration, Architec-
Acknowledgements
tures for Enterprise Integration, Chap. 3, Chapman and Hall,
London, 1996.
This work has been developed in the framework w15x M. Hammer, J. Champy, Re-engineering de Corporation,
´ Interministerial
of a Project funded by the Comision Harper Collins, 1993.
´ ŽCICYT., titled ‘‘Software
de Ciencia y Tecnologıa w16x J. Harrington, Business Process Improvement, McGraw-Hill,
´ de la Gestion
de Integracion ´ de Empresas Industri- New York, 1993.
w17x T. Davenport, Process Innovation, Harvard Business School
´ de las Arquitecturas de Sistemas
ales, adaptacion
Press, 1993.
´ GRAI e IMPACS.
Abiertos y a las Metodologıas w18x F. Vernadat, Enterprise modelling languages, in: K. Kosanke,
´ a las PYMES’s Valencianas’’. Ref. TAP-
Aplicacion J.G. Nell ŽEds.., ICEIMT97, ´ International Conference on
95-0880. Enterprise Integration and Modelling Technology, Springer-
Verlag, Torino, Italy, October 1997, pp. 212–224.
w19x K. Kosanke, Enterprise integration and standardisation, in: K.
References Kosanke, J.G. Nell ŽEds.., ICEIMT97, ´ International Confer-
ence on Enterprise Integration and Modelling Technology,
w1x K. Kosanke, Enterprise Integration—international consensus: Springer-Verlag, Torino, Italy, October 1997, pp. 613–623.
a Europe–USA initiative, in: K. Kosanke, J.G. Nell ŽEds.., w20x P. Bernus, L. Nemes, T.J. Williams, Architectures for Enter-
´
ICEIMT97, International Conference on Enterprise Integra- prise Integration, Chapman and Hall, London, 1996.
tion and Modelling Technology, Springer-Verlag, Torino, w21x IFIP-IFAC Task Force, GERAM, The Generalised Enterprise
Italy, October 1997, pp. 64–74. Reference Architecture, Version 1.3, 1997.
w2x T.J. Williams, PERA Methodology: I. International Work- w22x K. Kosanke, Process oriented presentation of modelling
shop In Business Integration, Valencia, Spain, July 1997. methodologies, modelling and methodologies for Enterprise
w3x F.B. Vernadat, Enterprise Modelling and Integration: Princi- Integration., in: Modelling and Methodologies for Enterprise
ples and Application, Chapman and Hall, London, 1996. Integration, Proceedings of the IFIP TC5 Working Confer-
w4x A. Ortiz, Propuesta para el Desarrollo de Programas de ence on Models and Methodologies for Enterprise Integra-
´ Empresarial. Aplicacion
Integracion ´ a una Empresa del Sec- tion, Queensland, Australia, November 1995, Chapman and
´
tor Ceramico, PhD Thesis, Valencia, Spain, 1998. Hall, London, 1996, pp. 45–55.
w5x Esprit Consortium AMICE ŽEds.., CIMOSA: Open System w23x K. Kosanke, F.B. Vernadat, T.J. Williams, Manufacturing
Architecture for CIM, Springer-Verlag, Berlin, 1993. enterprise modelling with PERA and CIMOSA, Proc. Manu-
w6x CIMOSA Association e.V., CIMOSA. Open System Archi- facturing Systems: Manufacturing Modelling, Management
¨
tecture for CIM. Technical Baseline, Boblingen, Germany, and Control ŽMIM97´ ., Vienna, Austria, 5–7 February, 1997.
1996, private publication. w24x T.J. Williams, The Purdue Enterprise Reference Architecture,
w7x T.J. Williams, ŽEd.., Guide to master planning and imple- Instrument Society of America, Research Triangle Park, NC,
mentation for enterprise integration programs, Technical Re- 1992.
port 157, Purdue Laboratory for Applied Industrial Control, w25x T.J. Williams, The Purdue Enterprise Reference Architecture,
Purdue University, West Lafayette, IN, June 1994. Computers in Industry 24 Ž2 to 3. Ž1994. 141–158.
w8x D. Shorter ŽEd.., An evaluation of CIM-modelling constructs w26x G.A. Rathwell, T.J. Williams, Use of the Purdue Enterprise
—evaluation report of constructs for views according to Reference Architecture and methodology in industry Žthe
ENV 40 003, Computers in Industry 24 Ž2–3., 1994, pp. Fluor Daniel example., Modelling and Methodologies for
159–236. Enterprise Integration, Chapman and Hall, London, 1996, pp.
w9x G. Doumeingts, Methode GRAI: Methode de Conception des 12–44.
 A. Ortiz et al.r Computers in Industry 40 (1999) 155–171 171

w27x F. Vernadat, CIMOSA: enterprise modelling and Enterprise Ortiz Bas, Angel is an Assistant Profes-
Integration using a process-based approach, in: H. Yoshikawa, sor in operations management and oper-
J. Goossenaerts ŽEds.., Information Infrastructure Systems ations research at the Higher School of
for Manufacturing, North-Holland, Amsterdam, 1993, pp. Industrial Engineering, and member of
65–84. the Research Group on Management and
w28x M. Zelm, F. Vernadat, K. Kosanke, The CIMOSA business Manufacturing Engineering ŽGIP.. He is
an industrial engineer and he received
modelling process, Computers in Industry 27 Ž1995. 123–
his doctoral degree in industrial engi-
142.
w29x H.R. Jorysz, F. Vernadat, CIMOSA: Part 2. Information ´
neering from Universidad Politecnica de
Valencia in 1998. He works as consul-
View, International Journal of Computer Integrated Manufac-
tant in several projects about Production
turing 3 Ž3. Ž1990. 157–167.
w30x R.E. Giachetti, A. Kusiak, K.T.K. Toh, M. Zelm, A human Management, Information Systems and
Enterprise Modelling and Integration in Metal Mechanic, Ceramic
factors taxonomy and human modelling in enterprises, Work-
and Automotive Enterprises. He is a member of the GIP Research
shop 1, Working Group 1., in: K. Kosanke, J.G. Nell ŽEds..,
´ Group. He works as a Researcher in three Spanish Government
ICEIMT97, International Conference on Enterprise Integra-
Projects ŽCICYT. and one ESPRIT Project. He is a teacher in the
tion and Modelling Technology, Springer-Verlag, Torino,
Polytechnic University of Valencia and in the FORD Spain Indus-
Italy, October 1997, pp. 75–81.
w31x H.T. Goranson, M. Fox, B. Katzy, T.J. Williams, D. Wis- trial Engineer School. He also teaches in several Masters ŽMBA..
His major research interests areas are Production Planning and
nosky, Human factors and Enterprise Integration, Workshop
Control, Enterprise Integration, Information Management, Busi-
1, Working Group 2, in: K. Kosanke, J.G. Nell ŽEds..,
´ ness Process Modelling. He has several papers in books and
ICEIMT97, International Conference on Enterprise Integra-
conferences in these fields.
tion and Modelling Technology, Springer-Verlag, Torino,
Italy, October 1997, pp. 82–88. Ros Mcdonnell, Lorenzo is a lecturer in
w32x A. Ortiz, et al., Building a production planning process with management information systems at the
an approach based on CIMOSA and workflow management Higher School of Computer Engineering
systems, Computers in Industry, this issue. and director of Master Program in Health
management Systems ŽMISA.. He re-
Lario Esteban, Francisco-Cruz is a pro-
ceived his PhD in industrial engineering
fessor in operations management and
from Polytechnic University of Valen-
operations research at the Higher School
cia, and is member of the Association
of industrial engineering, Head of the
and College of Industrial Engineers. He
Research Group on Management and
has been active for several years as pro-
Manufacturing Engineering ŽGIP. and is
fessional manufacturing engineer in both
the head of the Business Management
industrial and consulting firms, and has
Department at the Polytechnic Univer-
been involved in the development of computer integrated manu-
sity of Valencia. He has received his
facturing systems in SMEs. He has published a number or papers
PhD in industrial engineering from
in computer science and production engineering areas. His re-
Polytechnic University of Cataluna, ˜
search interests include the application of production planning and
Barcelona. He was professor at the MBA
control systems to manufacturing industry.
˜
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 commit-
tee 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 indus-
try. 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 man-
agement 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 in-
clude production planning and control systems, business integra-
tion, supply chain management, group technology and hierarchical
and methodology for the SMEs companies.