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: aortiz@omp.upv.es 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-
sation boundaries Žextended and virtual enter-
prises..
- 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 enter-
prises
The evolution in this field has gone through sev-
eral 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 opera-
tions were addressed ŽFig. 1..
In the present work, a new definition is intro-
duced 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 func-
tions with information, resources, applications and
people, with the aim of improving communica-
tion, cooperation and coordination in the enter-
prise, 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 ad-
vances 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., user-
friendly, simple and easy-to-use. have not been ade-
quately addressed. In these management levels, the
emphasis is on simple models with information cen-
tred 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 predic-
tions on time behaviour of any model to support
decisions. Žiii. Often, the availability of methodolo-
gies and tools in order to operate the models has
been disregarded. Živ. The impact of Enterprise Inte-
gration 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 devel-
opment 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. 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. 2..
 A. Ortiz et al.r Computers in Industry 40 (1999) 155–171
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 evalu-
ation 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 anal-
ysed 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
157
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 dis-
carded all the existing work and know-how devel-
oped by numerous R & D projects. Therefore, our
position was to try to combine the most interesting
aspects of the existing proposals in terms of method-
ological, 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 archi-
tectures 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 infor-
mation 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 compari-
son grid to become a complete framework for com-
paring 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 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
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 man-
agers and decision-makers, because the main objec-
tive 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 moder-
ated consumption of resources, as it must be taken in
account that they represent an overload for man-
agers.
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 man-
agement has already adopted the program.
In addition, the last phase of the system life cycle
is the disposal of the business entity. Table 1 sum-
marises 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 method-
ology, 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 be-
tween 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 Spon-
sor, 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 Spon-
sor 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 peo-
ple 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 pro-
gram 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.
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
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 re-
sources 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 estab-
lished. It is important to note that this step is devel-
oped within the defined business entity. For instance,
if the program is developed in an area of an enter-
prise, 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 strate-
gic 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, criti-
cal 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 enter-
prise 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 evolv-
ing. The elements to be measured can vary from one
enterprise to another. The members of the Steering
Committee and the EIT must decide which parame-
ters 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 man-
agement 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 busi-
ness 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 responsi-
ble 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 pro-
cesses. 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 de-
pends 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 TO-
BE, 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 be-
tween strategic, fundamental ŽKey and Key Criti-
cal., support w4x,
Ø The identification of the parameters that enable to
measure the results of a process Žefficiency, flexi-
bility, 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 pro-
cesses,
Ø A first approach towards the acceptance Žor rejec-
tion. 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 analy-
sis 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 opera-
tional effectiveness.
4.1.1.4. Action Plan deÕelopment. Once the pro-
cesses 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 be-
tween 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 pro-
cess, 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 impor-
tant 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 Pro-
cess 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 revo-
lutionary one. Žvi. Once the teams have been de-
fined, it is necessary to define the Management of
Change. It deals mainly with the development of
training courses for the staff and stresses the neces-
sity for the enterprise to define organisational and
cultural changes in order to adapt itself to the cir-
cumstances configured by the Enterprise Integration
Program. Žvii. Definition of the standards the enter-
prise decides to use. Žviii. Development of the Ac-
tion 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 manage-
ment 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 tem-
porarily or forever.
Ø Request more information. The Steering Commit-
tee 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 deci-
sions 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. More-
over, it is used as a framework to do all the succes-
sive phases. This introduces a key element for the
success of the program: for the first time, the man-
agement 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 prob-
lems, and before the cost generated by the program
becomes unaffordable if the program is to be stop-
ped.
4.1.2. Detailed leÕel
For the Requirements Definition, Design Specifi-
cations 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 pro-
cesses. 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 imple-
mented, 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 anal-
ysed. Ž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 indepen-
dent format Ži.e., without taking into account con-
crete aspects, as for instance the exact type of ma-
chine 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 simula-
tion 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
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 estab-
lished 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.
4.1.2.3. Implementation Description. This phase deals
with the selection of the most adequate current prod-
ucts 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 inte-
grate all the aspects defined in the proposal. More-
over, mechanisms have been established in order for
the technological elements to work according to
standards, and for the human resources to be ade-
quately prepared Žthanks to the training and learning
programs, and motivation actions..
4.1.2.4. Build. Once the adequate elements have
been selected to comply with the requirements, we
165
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 man-
agement 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 Spec-
ification phase Žand updated with the information of
the Implementation Description phase. is being car-
ried 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.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.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 enter-
prises, 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 busi-
ness 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.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 archi-
tecture that provides the elements to structure and
represent the enterprise from the Enterprise Integra-
tion 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 enter-
prise 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 enter-
prise 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
Fig. 6. Building block Conceptualisation phase.
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 ex-
tremely 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 nei-
ther some aspects introduced in the proposal, such as
definition of strategies, policies, efficiency parame-
ters, 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, Conceptu-
alisation, etc.. w23x, in our proposal, we have pre-
ferred 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 Descrip-
tion.. For the other phases, we have defined either
CIMOSA-like building blocks, or additional mecha-
nisms Že.g., the checklists.. Furthermore, we have
defined the mechanisms necessary to feed in a coher-
ent way, the CIMOSA constructs with the informa-
tion generated in the macro level. Thanks to this, we
provide a clearer and more structured approach to
the users.
 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 docu-
ments, as for instance, the strategy to be followed by
the business entity where the Enterprise Integration
Program is being developed. These strategic con-
cepts 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 con-
structs 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 neces-
sary.
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 exten-
sions, which enables an adequate application of the
Fig. 7. Link between new building block and CIMOSA building block.
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 enter-
prise, it is necessary to have the required tools that:
Ž1. Support the concepts, constructs and mecha-
nisms,
Ž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 con-
cepts 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 Pro-
gram will have little success chances, as the user
must be involved actively in its development w30,31x.
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 methodol-
ogy, 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, qFirst-
STEP, 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 en-
glish Modelling and Management of Integrated Pro-
cesses. has been developed. This tools aims to give a
computer-assisted modelling support to the applica-
tion of the proposal. Apart from providing the sup-
port 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 Inte-
gration Program. Two computer multimedia and vir-
tual 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
Fig. 9. Tools supporting the proposal.
phase ŽRequirements Definition and Design Specifi-
cation. 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 as-
pects related with the CIMOSA proposal ŽRequire-
ments Definition, Design Specification and Imple-
mentation 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 methodol-
ogy, 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
169
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 man-
agement of the operation of the system.
In the proposal w4x, all the phases and their sup-
porting 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 enter-
prises both industrial Žtiles enterprise w32x. and ser-
vice Ž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 pro-
posal, several future R & D topics must be also ad-
dressed, 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...
Acknowledgements
This work has been developed in the framework
´ Interministerial
of a Project funded by the Comision
´ ŽCICYT., titled ‘‘Software
de Ciencia y Tecnologıa
´ de la Gestion
de Integracion ´ de Empresas Industri-
´ de las Arquitecturas de Sistemas
ales, adaptacion
´ GRAI e IMPACS.
Abiertos y a las Metodologıas
´ a las PYMES’s Valencianas’’. Ref. TAP-
Aplicacion
95-0880.
References
w1x K. Kosanke, Enterprise Integration—international consensus:
a Europe–USA initiative, in: K. Kosanke, J.G. Nell ŽEds..,
´
ICEIMT97, International Conference on Enterprise Integra-
tion and Modelling Technology, Springer-Verlag, Torino,
Italy, October 1997, pp. 64–74.
w2x T.J. Williams, PERA Methodology: I. International Work-
shop In Business Integration, Valencia, Spain, July 1997.
w3x F.B. Vernadat, Enterprise Modelling and Integration: Princi-
ples and Application, Chapman and Hall, London, 1996.
w4x A. Ortiz, Propuesta para el Desarrollo de Programas de
´ Empresarial. Aplicacion
Integracion ´ a una Empresa del Sec-
´
tor 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 Archi-
¨
tecture for CIM. Technical Baseline, Boblingen, Germany,
1996, private publication.
w7x T.J. Williams, ŽEd.., Guide to master planning and imple-
mentation for enterprise integration programs, Technical Re-
port 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
Systemes de Productique, These d’Etat en Automatique,
Universite de Bordeaux 1, Bordeaux, France, 1984.
w10x ¨
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 Inte-
gration Modelling. Proceedings of the First International
Conference, MIT Press, 1992, pp. 249–258.
w11x C.J. Petrie ŽEd.., Enterprise Integration modelling, Proceed-
ings of the First International Conference, MIT Press, 1992.
w12x K. Kosanke, J.G. Nell ŽEds.., Enterprise engineering and
integration: building international consensus, Proceedings of
ICEIMT International Conference, Springer-Verlag, Berlin,
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-
tures for Enterprise Integration, Chap. 3, Chapman and Hall,
London, 1996.
w15x M. Hammer, J. Champy, Re-engineering de Corporation,
Harper Collins, 1993.
w16x J. Harrington, Business Process Improvement, McGraw-Hill,
New York, 1993.
w17x T. Davenport, Process Innovation, Harvard Business School
Press, 1993.
w18x F. Vernadat, Enterprise modelling languages, in: K. Kosanke,
J.G. Nell ŽEds.., ICEIMT97, ´ International Conference on
Enterprise Integration and Modelling Technology, Springer-
Verlag, Torino, Italy, October 1997, pp. 212–224.
w19x K. Kosanke, Enterprise integration and standardisation, in: K.
Kosanke, J.G. Nell ŽEds.., ICEIMT97, ´ International Confer-
ence on Enterprise Integration and Modelling Technology,
Springer-Verlag, Torino, Italy, October 1997, pp. 613–623.
w20x P. Bernus, L. Nemes, T.J. Williams, Architectures for Enter-
prise Integration, Chapman and Hall, London, 1996.
w21x IFIP-IFAC Task Force, GERAM, The Generalised Enterprise
Reference Architecture, Version 1.3, 1997.
w22x 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 Confer-
ence on Models and Methodologies for Enterprise Integra-
tion, Queensland, Australia, November 1995, Chapman and
Hall, London, 1996, pp. 45–55.
w23x K. Kosanke, F.B. Vernadat, T.J. Williams, Manufacturing
enterprise modelling with PERA and CIMOSA, Proc. Manu-
facturing Systems: Manufacturing Modelling, Management
and Control ŽMIM97´ ., Vienna, Austria, 5–7 February, 1997.
w24x T.J. Williams, The Purdue Enterprise Reference Architecture,
Instrument Society of America, Research Triangle Park, NC,
1992.
w25x T.J. Williams, The Purdue Enterprise Reference Architecture,
Computers in Industry 24 Ž2 to 3. Ž1994. 141–158.
w26x 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 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.