A Reference Model for Project Enterprises – the Product Development Case

Study

Brane KALPIC*, Peter BERNUS**

* ETI Jt. St. Comp., Obrezija 5, 1411 Izlake, Slovenia, brane.kalpic@eti.si

** Griffith University, School of CIT, Nathan , QLD 4111, Australia, P.Bernus@bigpond.com

Corresponding Author:

A/Prof Peter Bernus, Griffith University, School of Computing and Information Technology, Nathan

(Brisbane), QLD 4111, Australia, Email: P.Bernus@bigpond.com Tel: +61-7-3875 5039 Fax: +61-7-3875

5051

A Reference Model for Project Enterprises – the Product Development Case

Study

Abstract

Findings of an effort to improve the performance of the new product development process (usually

executed as a project) in the company are presented. The article describes a set of generic, re-usable

reference models for the management and execution of such projects. An approach is described to develop

practically usable reference models of Project Enterprises both for mission fulfilment (called a process

reference model) and for management (called a project management reference model). This separation of

reference models allows the development of a generic model while at the same time fulfilling the need to

describe several types of projects that have a variety of missions. The article treats the issues concerning the

application of high-level and abstract reference models on the example of ISO9000:2000 requirements for

planning and execution of points of reviews, verifications and validations. The recursiveness of entities in the

project enterprise and the suitability of activity vs. behavioural process models for the development of

Reference Models is also discussed.

Keywords: Project Enterprise, Project Management, Reference Model, Business Process Modelling

1. Introduction

Unpredictability and changeability in the internal and the external environment require responsiveness and

flexibility in the organisation and in the execution of its processes (Warnecke, 1993). Customer orientation

and the time needed to turn an idea into a final product are increasingly important elements of

competitiveness in this environment. High quality, technical sophistication and price competitiveness of a

product are necessary but not sufficient: the product must be able to fulfil individual customer demands.

This is reflected in the increasing individualisation of product design and production.

The rapid change and development of technologies, techniques and new materials significantly

reduced product development time and extended the feasible limits of product complexity and ensuing

functionality – even in for very demanding products.

In this situation mastering the process of new product development is one of the key elements of

competitiveness and success of the enterprise. These factors were the motivation for the company1 to set-up a

Project2 intended to improve the qualtiy of project deliverables, planning and control of project activites and

resources, and to decrease product development lead time.

This Project was mandated to:

1 The case study is based on experience at the Electronics Manufacturer ETI, Slovenia.2 The company's project to improve product development is hence referred to as 'Project', to differentiate it from product development projects.

re-engineer the product development process and to define a decisional structure as well as a

corresponding organisation, which are transparent for every stakeholder;

capture the result as a reference model of the new product development process, to become the explicit

and reusable representation of relevant core engineering process knowledge. Such a reference model

was to be used as a generic blueprint that can be specialised and detailed for each project in turn.

Based on the analysis of several projects (post-mortem reviews) the company found critical issues in

project management and organisation that were similar to other projects in the company (e.g. those dedicated

to strategy implementation or to various change initiatives). Based on these findings the Project's mission

was extended to the development of a common reference model for all types of projects in the organisation.

Project enterprise reference models are not only important for the capture, formalisation and

distribution of knowledge about engineering processes but also for the establishment of a common

communication platform for all project stakeholders. Project enterprise reference models help explicitly

define the content of the project, necessary activities, required deliverables of individual project phases and

the roles and contributions of any individual in the project life-cycle. The article presents the developed set

of project enterprise reference models, their features and mutual connections.

An important finding and contribution of the presented industrial case study is the division of project

reference models into two broad categories: a) Project Management Reference Model (common reference

model of a project's management) and b) a set of dedicated 'process' reference models, which describe

mission-dependent functions of particular project types (such as new product development, new application

development and implementation, business process re-engineering, etc.).

The article discusses issues concerning the ISO9000:2000 standard requirements for planning and

execution of review points, verifications and validations, and the application and instantiation of high level,

abstract reference models into the idiosyncratic project (process) life-histories. The article also presents the

requirements for the separation of planning and control (reviews, verifications and validations) between the

project and its deliverables. Section 2 and 3 overview the basic concepts used. Section 2 also briefly reviews

some important features of the GRAI-Grid approach for the description of management systems.

Section 3 presents features of the GERAM (IFIP-IFAC Task Force, 1999) framework and of the

GERA architecture as used in this Project, such as the distimction between life-cycle and life-history, as well

as the recursive nature of enterprise entities.

Section 4 contains the developed set of models for Project Enterprises, discusses the interaction of

the Project Enterprise entity with other enterprise entities, as well as the approach used to design functional

models of project enterprises. Section 4 also discusses the suitability of activity models vs behavioural

process models for Business Process Reengineering and for Reference Models in particular, identifies drivers

which define the requisite level of granularity ofthese models, and concludes with general guidelines for

business process modelling.

2. Cybernetic model of an artificial system

2.1. The model of an artificial system

The structural and behavioural characteristics of artificial systems can be studied using a simple cybernetic

model (see Figure 1). The model consists of three main components (Chen and Doumeingts, 1996):

The Physical system is the component of the artificial system responsible for performing processes and

activities intended to transform system inputs into system outputs (goods, services and by-products) by

the application of the system’s resources (human, technical, financial, etc.). Thus the ‘physical system’ is

responsible for satisfying the system’s mission;

The Management & control system (often called the ‘decision system’) is the component of the artificial

system responsible for the co-ordinated functioning of the physical system according to the artificial

system's mission and objectives. The management of the physical system is done through 'orders' (orders

may be the result of a negotiation – thus the inverted commas – or purely delivered by a control system)

(Bernus and Nemes, 1999). These ‘orders’ are the product of decision-making processes. Decision-

making processes follow a logic controlled by a set of system objectives, constraints and decision

variables;

The Management information system connects the physical system and the management & control

system, and delivers feedback as well as aggregates information suitable for decision support. Decision-

making processes also exchange information with the external environment and this is done through the

management information system.

Figure 1. Cybernetic model of an artificial system – related to the enterprise life-cycle

The same division of an artificial system into Service and Management & Control parts is present in

Enterprise Reference Architectures such as PERA (Williams, 1994) and GERA (IFIP-IFAC, 2001).

2.2. How to model the management system of an enterprise?

Manufacturing and other business processes (e.g. engineering, design, production, etc.) performed in the

physical system (see Fig.1) can be modeled by activity3- or behavioural4 models.

While activity models can always be developed, behavioural models are feasible only for processes

that follow known procedures or known rules of transition,5 and are therefore called structured processes

(Vernadat, 1998).

Unstructured processes can only be described as an activity model, i.e. defining functions by their

inputs, outputs and mechanisms and circumscribing the contents of the function (using and explanation

suited to the mechanism at hand).

Ill-structured processes can only be described by their desired outputs, and noting the range of

inputs that might be necessary, as well as circumscribing the task in a way that is suitable for the mechanism

(which in case of ill-structured processes is invariably human). Typically, the inputs and outputs to

unstructured and ill-structured processes can only be defined as policies, objectives, goals and constraints

rather then mechanistically provided 'control signals'.

The system of management is a mixture of structured, unstructured and ill-structured processes.

Therefore, a fully structured model for their definition is not possible. On the highest level of management,

some process structure may be defined, helping to co-ordinate the activities of humans who co-operate to

manage the enterprise. For these models to be followed and uniformly interpreted it is expected that the

definitions will be interpreted by managers with a defined level of expertise and competency, and that they

share a set of commonly believed assumptions.

For unstructured management tasks the expectation from the enterprise's point of view is that the

models should describe what the tasks’ desired outputs or deliverables are and what crucial inputs must be

considered when making a decision. In addition, on the interface between unstructured management tasks the

enterprise may wish to enforce procedurally defined communication protocols, so as to co-ordinate the

activities of decision makers. Typically, at short horizons, management tasks become control functions, so

that a control system can be defined through structured processes and procedures or behavioural rules.

As a consequence of the above, in the design of a management system a great deal of care must be

taken at each level of detail: before attempting to further structure the description of management functions

using a model, one must ask the question whether this detail will be useful (is there a value in adding further

detail?) and whether the formalism chosen is adequante (is the formalism suited to model the structured,

unstructured or ill-structured function in question?).

3 Activity models concern the functionality of the business process i.e. the ‘things to be done’ or ‘tasks’ (activities and operations performed within process). Activity models are primarily concerned with the ways in which business activities are defined and connected through their products and resources. Therefore, activity models characterise a process by describing a) its structure (sub-processes and activities) b) required inputs and delivered outputs for each sub-process or activity, c) control relationships, and d) resources needed for activity/process execution and highlight the roles that objects play in them. These process models do not represent sequences of control or temporal properties. 4 Behavioural models capture the flow of control within a process – the rules of the sequence in which activities are (or must be) performed. This can be done explicitely (describing a procedure), or implicitely (describing rules of transition, also called behavioural rules). Behavioural models do not necessarily define the objects and resources used or produced by the process. These models are particularly well suited for the design or analysis of business processes in which the timing and/or sequencing of the events is critical (for example, in the development of simulation models).5 I.e. a partial ordering of activities exists.

We selected the GRAI-Grid for this management-oriented presentation of an enterprise. WHY???

The GRAI-Grid does not aim at the detailed modelling of management processes but identifies

points (also called decisional centres) where decisions are made and communicated and defines mutual

connections and interactions among these decisional centres (Doumeingts et al, 1998). A decisional centre

(as an autonomous unit) can be further described by specifying its:

objectives, constraints, decisional variables (Figure 2a)

required inputs and delivered outputs (which compose together a decisional frame for any individual

decision centre – Figure 2b) and

task (the decision making process in form of an activity model, a behavioural model, or as a natural

language description).

The description of the behavioural aspect may of course be different in granularity from decision centre to

decision centre depending on the level of formalisability of the decision process in question.

Figure 2: (a) The GRAI-Grid concept (b) Co-ordination links between DCs

Beside the main categories of decisional functions (product and resource management, and planning

and co-ordination functions) the hierarchy of decisions (form strategic to tactical, down to real time)

represents another dimension of the GRID. Each level of this dimension is defined by a horizon (a quantified

part of the future taken into account in a decision) and a period (the time that passes after a decision when

this decision is expected to be re-evaluated).

3. Selection of an Architecture Framework

Today's enterprises need an approach which could help them dynamically adapt to changes. Previous research, carried out by the AMICE Consortium on CIMOSA, by the GRAI Laboratory on GRAI and GIM, and by the Purdue Consortium on PERA, Zachman Framework, C4ISR, ARIS, etc. produced reference architectures or frameworks, which were meant to organise all enterprise integration knowledge and serve as a guide in enterprise integration programmes. Given tha tthere exist an international standard, ISO IS15704:2000, and an example ‘GERAM’ (Generalised Enterprise Reference Architecture and Methodology) the needs of the Project were analysed using the GERAM concepts. Below is a short introduction of the concepts used, for more detailed exposition see [ISO15704:2000].

The GERAM framework identifies in its most important component GERA (Generalised Enterprise

Reference Architecture) the basic concepts to be used in enterprise engineering and integration. GERAM

distinguishes between the methodologies for enterprise engineering and the modelling languages that are

used by the methodologies to describe and model the structure, content and behaviour of the enterprise

entities in question.

Methodologies use enterprise models to represent all or part of the enterprise. These models can be

used to guide the implementation, or to improve, the operational system of the enterprise.

The methodology and the languages used for enterprise modelling are supported by enterprise

engineering tools. The semantics of the modelling languages may be defined by ontological theories, meta

models and glossaries that are collectively called generic enterprise modelling concepts. The modelling

process is enhanced by using partial models (reusable reference models).

The operational use of enterprise models is supported by enterprise modules which are actual

existing resources used in the construction of the actual operational system.

3.1. Generalised Enterprise Reference Architecture (GERA)

GERA defines a set of generic concepts recommended for use in enterprise engineering and integration

projects. These concepts can be classified as human oriented (including individual, organisational and

communication aspects), process oriented and technology oriented concepts.

GERA identifies three dimensions for the definition of the scope and content of enterprise modelling

(see the Figure 3):

Life-Cycle Dimension provides a controlled modelling process of enterprise entities according to the

life-cycle activities,

Genericity Dimension provides a controlled particularisation (instantiation) process from generic and

partial to particular,

View Dimension provides a controlled visualisation of specific views of the enterprise entity (entity

model content, purpose, implementation and physical manifestation view) as may be needed for the use

of humans or machines in their various roles as they fulfil their tasks in the life-cycle of the given entity.

For the purpose of the Project we will focus on the presentation of process concepts (see Sections 3.1.1 and

3.1.2).

Figure 3. The Generalised Modelling Framework, GERA

3.1.1. Life-cycle and life-history of an entity

The life-cycle is a well known notion used to structure (abstract) different processes and activites performed

during an entity's life.

The GERA life-cycle model (see the Figure 3) can be used for the definition of any enterprise or any

of its entities and defines a total of six life-cycle activity types or life-cycle 'phases' of an entity (some other

frameworks define less or more life-cycle phases).

While the life-cycle of an entity defines the structure and types of activities in the entity's life, life-

history adds to the entity's model the dimension of time (defines the moments in time on the time scale when

activities start and finish). According to ISO 15288:2000 (System life-cycle processes) the life-history of an

entity can be subdivided into stages, and each stage is usually characterised by the predominance of one of

the life-cycle processes.

From the presented features of the life-cycle and the life-history concepts two important conclusions can be

drawn (Bernus and Schmidt, 1998):

life-histories of individual entities are unique and usually difficult to understand because of their

complexity and individual idiosynchratic properties, and

life-histories of enterprise entities are made up of instances of processes and their constituent activities

which, however, belong to the process/activity types defined in the common life-cycle dimension (Fig.

4).

Figure 4. Relation between life-history and life-cycle of an entity

3.1.2. Recursiveness and hierarchy of entities

In practice we often want to observe and define relations and interactions between different types of entities

especially between the enterprise and product entities.

GERA introduces two different approaches to categorise enterprise entity types:

an operation oriented set, which defines different types of operations like

o Project Enterprise Entity (Type A) defines an enterprise that is created for the one-off

production of another entity; the management system of project enterprises is typically set up quickly,

while the rest is created and operated in lock-step with the life-cycle activities of the product of the

project

o Repetitive Service- and Manufacturing Enterprise Entity (Type B) defines enterprises

supporting a type- or a family of products, produced in a repetitive or sustained mode; during their life-

history these business enterprises undergo multiple change processes

o Product Entity (Type C) defines a very large class of entities including any artificial product,

such as customer goods, services, hardware equipment, computer software, etc; these entities are not

enterprises themselves

a generic and recursive set of enterprise entity types, which defines Strategic Enterprise Management

Entity - Type 1, Enterprise Engineering/Integration Entity (e.g. a master planning project) - Type 2,

Enterprise Entity - Type 3, Product Entity - Type 4, Methodology Entity (such as a project developing an

engineering methodology) - Type 5; because of the recursion of these types this is not a closed set.

The two sets have close relations to each other (e.g. an enterprise integration entity is usually a project entity)

and both categorisations identify the product entity as the result of the operation of other entities.

Figure 5a represents a simple example of recursiveness of two entities: an enterprise entity type and

a product entity type. In the presented example the enterprise in its operation phase executes activities which

are dedicated to the identification, requirements definition, design and implementation of the product. For

example, company takes care of the identification of the need for a marketable product (marketing and

innovation), its design (technical and technological) and manufacturing.

Figure 5b presents another example of the interaction between enterprise and product entities. In this

case the enterprise (service) entitiy interacts with the product entitiy in the product's operation phase. For

instance, a car workshop (in its operation phase) provides maintanance of cars during their operations. Below

the diagram of the recursive relationship of life-cycles (on the Figure 5b) a simplified form of recurssive

relationship in a form of a cross-chocolate bar diagram is presented.

Manufacturing Entity (Type 3)

Preliminary design

Detailed design

Identification

Concept

Requirements

Operation

Decommissioning

Implementation

Design

Product Entity(Type 4)

Preliminary design

Detailed design

Identification

Concept

Requirements

Operation

Decommissioning

Implementation

PRIJ_ZT.DWG 01/98

90

36

4 5

36

43.7 58 63

Design

ServiceEntity (Type 3)

Preliminary design

Detailed design

Identification

Concept

Requirements

Operation

Decommissioning

Implementation

Design

Product Entity(Type 4)

Preliminary design

Detailed design

Identification

Concept

Requirements

Operation

Decommissioning

Implementation

Design

IdentificatioConcept

Require-ments Preliminary

design Detailed design Impleme-

ntationOperation

Decomm-issioning

Decomm-issioning

ConceptRequire-ments

Preliminary design

Detailed design

Impleme-ntation

Identificatio

Product

Enterprise

Figure 5. Examples of the recursive relationship between the a) Enterprise (Manufacturing) and b) Enterprise (Service)

and the Product Entity

In general, only operational activities of entities affect the life-cycle activities of other entities. At the same

time the presented interaction between entities represents a hierarchical 'pre-existence' relation (e.g.

manufacturing entity product entity means the product entity can not exist without a manufacturing

entity).

3.2. Enterprise Reference Models

In typical business environments there exist a number of common (business) processes, which are similar or

the same – no matter what is the function or mission of the enterprise. Therefore, the adoption of reusable

enterprise models (also called reference models or partial models), is a most significant improvement of

efficiency and quality in the planning of new, or redesigning of existing, processes (Mertis and Bernus,

1998).

There are three types of reference models, which lend themselves for reuse: generic models

(capturing the common aspects of a type of enterprise), paradigmatic models (where a typical, particular case

is captured in model form and that model is subsequently modified to suite the new situation) (Bernus et al,

1996), and building block models (a set of elementary model fragments that can be freely combined as

components to form a complete model).

We now introduce the terms process type and process instance. A process type is a structure

consisting of activities (e.g. ‘the processes of product development’) each defined by its name and signature

(inputs and outputs and conditions of execution), as well as the relationships between these (e.g. input-output

relationships and possibly rules for execution) (Schmidt, 1998).

A process instance is the execution in time of transformations on a set of concrete objects as defined

according to the rules defined by the process type. A process instance is therefore the real process following

the rules and structure of a given process type. A process instance has a life-history of its own, which at any

point in time consists of a past and a future: a) the past is a partially ordered set of events that happened

during the execution up to the given point in time, and b) a future which is the set of partially ordered sets of

all possible events (possible futures) that could eventuate (where exactly one of these sequences will become

the past at a given later point in time).

Given a process type, it is an interesting question what all the possible executions are – e.g. to find

out whether there are any circumstances which might cause an instance of that process type to get into a

deadlock, or any other undesirable state. Given a process instance, it is also interesting to find out what all

the possible futures are, e.g. in order to control the process instance in some intended, or optimal, way.

4. Project Enterprise Reference Models

4.1. Recursiveness of entities in the project enterprise

Figure 6 presents the recursiveness of life-cycles involved in new product development projects: Parent

Enterprise life-cycle, Project Enterprise life-cycle and Product life-cycle (Gobbi and Muffato, 1999). The

right-hand side of Fig. 6 also shows the time-dimension and the interactions of activities during the life-

histories of these entity types. For example, company (manufacturing entity, Entity Type 3) manufactures

different electrotechnical products (Entity Type 4). The operational activities of the company are shown as

activity 2 in the life-history diagram.

At a particular point in time the company identifies the need for a new product (activity area 3 in the

life-history diagram). The initial idea of the product is further developed into its requirements definition (this

is partially done by the Parent Enterprise and partially by a Project Enterprise).

The Parent Enterprise, for the purposes of the development of the new product, sets-up a project -

Entity Type 3 (activity area 4 in the life-history diagram) dedicated to the definition of the functional

requirements, preliminary and detailed design of the product (activity area 5).

The implementation phase of the product (its manufacturing) is done by the manufacturing activities

of the Parent Enterprise (activity area 6). Activity area 6 in the parent enterprise entity also represents

neccessary 'techology' related activites for the product manufacturing (for instance implementation of new

technology, application of new processes, installation of new machines, tools and layouts, etc.) executed by

the project.

The operation phase of the product at the same time represents the processes as performed by the

product (activity area 7) when it is in use by the final user (customer), and product maintenance and support

processes as performed by a Service Entity (Entity Type 3).

From the presented example we could see that part of product disposal (especially for some

environmental critically parts – e.g. Cadmium alloys integrated in the product) is also covered by company

activities. Disposal activities should be already considered and taken into account in the product

development phase; the Project should also provide or trigger the development of required processes

(services) which will support the execution of disposal activities (development and implementation of a new

processes – activity area 8 in the life-history diagram of the parent enterprise and the product entity).

{

{}}

Manufacturingentity (type 3)

Product entity (type 4)

Service entity (type 3)

Engineering -entity (type 3)

User-customer

PRIJ_ZT.DWG 01/98

90

36

4 536

43.7 58 63

Project

{

Preliminary design

Detailed design

Identification

Concept

Requirements

Operation

Decommissioning

Implementation

DesignPreliminary design

Detailed design

Identification

Concept

Requirements

Operation

Decommissioning

Implementation

Design

Preliminary design

Detailed design

Identification

Concept

Requirements

Operation

Decommissioning

Implementation

DesignPreliminary design

Detailed design

Identification

Concept

Requirements

Operation

Decommissioning

Implementation

Design

Preliminary design

Detailed design

Identification

Concept

Requirements

Operation

Decommissioning

Implementation

DesignPreliminary design

Detailed design

Identification

Concept

Requirements

Operation

Decommissioning

Implementation

Design

Preliminary design

Detailed design

Identification

Concept

Requirements

Operation

Decommissioning

Implementation

Design

{11

22

88

33

44

55

6677

88

66

2

ICRDImOD

1

5

3

8

67

ParentEnterpriseEntity

ProjectEnterpriseEntity

ProductEntity

Life

-cyc

le p

hase

s

Time (Life-history)

ICRDImOD

ICRDImOD

4

6 8

Figure 6. Recursiveness of entities and their life-histories (an example)

Beside the definition of hierarchical relations of entities, one of the important contributions of this

recursiveness model is that it allows us to find out structural requirements of the decisional models of the

involved entities.

Since both the Parent Enterprise and the Project Enterprise have management tasks in the Project

Enterprise life-cycle, two decisional models are needed, represented as a GRAI Grid for each (instead of one

single decisional Grid). The resulting decisional model will be presented in more detail in Section 4.4.

4.2. Development of functional reference models of a Project Enterprise

Our work was intended to improve and support project execution in the company, and specifically, to

achieve two objectives: 1) re-engineering of the life-cycle processes, organisation and management of

projects (with particular emphasis on new product development projects), and 2) design of a project

reference model which would improve the quality, reliability and efficiency of the planning of projects as

well as of their performance, management and control (in terms of identification of main process functions

and activities and main decisions). Such a reference model was intended to capture reusable enterprise

engineering knowledge in the company.

For the purposes of representing a re-engineered project life-cycle model we used the functional

modelling language IDEF0 (KBSI, 2001). This was well suited (in our case) for the description of the

processes in the project life-cycle (both for process analysis and redesign).

4.2.1. Re-engineering of business processes and existing project enterprise model

In many companies operations are still performed in a very traditional way and information is gathered using

‘paper and pencil’ methods. This causes low responsiveness to customers demands, long process lead times,

delays, information losses, excessive overhead and unnecessary production expenditures, and consequently

low customer satisfaction (Vernadat, 1996). New business trends have forced many companies to review and

simplify their operation procedures (Hammer and Champy, 1993).

The Business Process Reengineering (BPR) movement promotes the fundamental rethinking and

radical redesign of business processes (within and between organizations) to bring dramatic improvements in

critical, contemporary measures of performance, such as cost, quality, service, and speed (Hammer and

Champy, 1993; Davenport and Short, 1990). Popularity of BPR is proved by many different BPR

methodologies found in the literature.

In the Project we followed a ten-step approach (see the Figure 7) which integrates the guidelines of

some major methodologies proposed by a range of authors (Vernadat, 1996; Davenport and Short, 1990;

Malhotra, 1998).

Step 1: Identify processes and set objectives for improvement

Step 2: Get management commitment to re-design processes

Step 3: Form a cross-functional team

Step 4: Modelling the AS-IS process

Step 5: Identify areas for improvement

Step 6: Design the ideal TO-BE process

Step 7: Verify the TO-BE process

Step 9: Install and validate the new process

Step 10: Monitor the new process for future changes as needed

Step 8: Propose an implementation plan and get management commitment

Figure 7. The BPR ten-step approach

Among ten proposed steps in BPR approach modelling of AS-IS state represents many times the most

difficult and time-consuming task. In the creation of the AS-IS process model (both for BPR and for

documentation in a Quality Management System - QMS), companies face some typical problems.

The first step in the development of the functional model of the process represents the acquisition of

elementary information about the process in question. A QMS (quality manual and quality procedures) could

be many times considered as a main source of documented description of the organisation’s business

processes. These descriptions are usually composed of text and simple charts.

However, everyday practice has shown to the authors, that based on QMS documents it is very

difficult (or impossible) to reconstruct the contents of the process or to fully understand its functions,

sequence of activities, their dependencies, required inputs and delivered outputs, or to identify the key

decisions or allocation of authorities over these decisions.

The reason for this is that the use of textual descriptions and simple charts does not guarantee an

understandable, transparent and unequivocal description of business processes. Therefore, the use of business

process modelling supported by formal modelling languages, tools and methodologies are needed to provide

a systematic, standard, unequivocal, interpretable and complete description of information about processes,

the involved entities, functionality and behaviour. Such formal models play an essential role in the quality

description of business processes.

The incomplete process information captured in usual QMS documents, or in other organisation-

specific documents, has to be extended through additional interpretation, which usually needs interviews

with stakeholders and the process owner(s).

During the development of the AS-IS model, the authors have experienced how difficult it is for

people to express their implicit knowledge of the process. Therefore capturing of information about the

process is a difficult and time-consuming task. At the same time, process models are an adequate base and

communication vehicle (between process owner and the person who performed the modelling) for the

exchange, presentation and agreement on the interpretation of facts about the process (Kalpic and Bernus,

2002).

The authors, based on their own industrial experience gained through running different BPR projects

and the creation of AS-IS process models, point to the importance of a basic understanding of the modelling

language syntax and semantics by all stakeholers, to achieve an efficient exchange of information about the

process captured in the model. This may seem as an obvious statement, but since enterprise models are

mostly graphical, they can be interpreted by untrained stakeholders as just illustrative 'figures' or 'pictures'

and as a consequence part of the information in these graphically represented models may not be conveyed

(and this fact may remain unnoticed). Therefore, a short introduction of syntax and semantics of the

modelling language used in process modelling should be given first.

The design of the process model is usually an iterative process where, based on the model, the

exchange of information and understanding of its content is to be achieved between the process owner and

process designer/analyst. The process designer/analyst and process owner iterate this modelling process until

the process model is mutually agreed on and confirmed as a credible and relevant snapshot of the existing

process.

There are arguments for not preparing an AS-IS model, in case the present process is known to be of

such inferior quality that little would be learnt from a model of how it is performed at present. However,

often this knowdge is not shared by stakeholders, and they need an understanding of what the problems are.

In such a case an AS-IS modelling exercise may be started, with the intention for all stakeholders to agree on

the lacking qualities of the existing process. Practice shows that AS-IS modelling in such cases is usually not

carried to the end (not to the level of detail that one might expect from a TO-BE model). This is because

stakeholders will automatically include corrections in the model, and what started out as an AS-IS model,

becomes the implementation of steps 5 and 6 – ideas for improvement and the preparation of a TO-BE

model. If management is aware of the likelehood of this happening, starting an AS-IS modelling exercise

may still be of use for training purposes, e.g. if participants are not familiar with the formalisms intended to

be used for modelling. However, this latter goal can also be acheived through training that is based on

existing good examples.

4.2.2. The granularity (depth) of process models

In the development of a business process model practitioners are often faced with the question: given the

life-cycle phase for which the model is developed, how in-depth should be this description, i.e. what should

be its granularity? A general answer to the question cannot be given because the level of granularity in

process description (modelling) depends on the model’s purpose. According to Uppington and Bernus (1998)

the level of granularity in BPM is driven by the need to understand the current state of affairs and by the

pragmatic needs of the subsequent life-cycle phase of the change process and the personnel involved.

In the case of a single company there are many shared contextual elements that allow a simple model

to be produced, which is still pragmatically complete. In the context of an industry, either the context of use

must be defined in more detail (such as defining the necessary assumed knowledge and experience of the

users of the reference model), or the model itself should be more detailed.

However, for any parts of the model (such as the name of an activity, the name of a process or data

element) there must be an adequate explanation included in the model, which ensures that the lowest level

elements of the model are uniformly interpreted by everyone using this model.

The necessary level of process granularity is also connected to the nature of the process. E.g. if the

activities performed by human resource are creative in nature, or the human resource is highly qualified, then

it is better to stop at higher level activities in process decomposition. This also means that process models

might be developed so that the level detail revealed depends on the skill (competency) level of the human

user.

4.2.3. Use documented best practice as an input to the BPR process

To improve the quality of TO-BE process models, and the effectiveness and efficiency of the design process,

BPR practicians might use some available business process reference models. Reference models could be

used as a) general and high-level guidelines, developed from examples of the best practice in the given

industry (e.g. to gain insight into the most critical points of the process), or b) requirements which must be

met (e.g. in case the business processes must be adjusted to an ERP system implementation).

As an example of a high-level, abstract and public available reference model represents the

ISO9000:2000 standards (in the literature other examples of public available reference models could be

found, as for instance the automotive standard ISO TS16949, APQP proposals and guidelines for Product

Quality Planning, etc.). The ISO 9000:2000 standards, as a requirement specification and policy level

standards applicable to all types of enterprises, do not provide more detail and elaborated guidelines and

reference models how to fulfil these standard requirements (even though the ISO9000:2000 and

ISO9004:2000 guidelines are a good start). Therefore, organisations are many times left to their own devices

in the selection of detailed design and implementation approaches to fulfil the standard’s requirements.

The authors, based on their experience, recognise the ISO9000:2000 standard requirements for

planning and execution of points of reviews, verifications and validations in the design process as one of the

most demanding a) standard requirements for application and b) abstract reference model for instantiation.

Behavioural model of development process, which would provide explicit, step-by-step guideline (in terms

of functions and defined points of reviews, verifications and validations) could not be developed becouse of

its unstructured nature. Namely, each development process is idiosyncratic in its life-history so control points

could not be predefined and prescribed in term of a concrete plan or behavioural reference model (for

instance, where in how many points of reviews, verifications and validation of product components and

product itself will be needed).

To apply standard requirements users should integrate specific (product developemnt) expertise with

the capability of understanding of abstract standard requirements.

Business process reference models may be acivity or behavioural models, depending on the type of

the process and the purpose of the reference model’s use.

In the development of business process reference models or in BPR, authors have noticed that in

many cases activity process models are more satisfactory then behavioural ones. Namely, activity reference

models express a general nature of the processes (for instance they identify the interfaces and co-operation

between elementary activities) and can be instantiated according to the particular needs.

Behavioural models are useful for the purposes of simulation and certain analysis tasks, but can only

be produced if the business activity is procedural in nature. This means that some activity models (those

which are fully implemented in an automated way) may be further detailed using a behavioural model. Also

high-level behavioural models may be constructed to describe certain procedures, lowest level activities of

which, however, are not procedural and are thus need to be treated as elementary from the behavioural point

of view.

For the success of the business process modelling, business process reengineering or just simple

redeployment of the best practice described by reference models, easy accessibility and distribution of

business process models is one of the key factors. Organisations can use a variety of information

infrastructure and technologies (usually already available and present in organisations) such as Intranet, web

technology, etc. Using such a distribution mechanism process models can be made available to all

stakeholders, and their access can be made platform (software and hardware) independent.

4.2.4. Planning of project and product control points

In re-engineering the business process, modelling and analysis of the functional structure play an important

role, because it provides the definition of activities that must be executed to achieve the mission and

objectives of the process.

The second important task in the reengineering process is to analyse the decisional structure of the

process. The analysis of the decisional structure is primarily focussed on searching for answers such as:

which important decisions are made in the process, does the process integrate all required decisions or should

some decisions be added?

During the analysis of the decisional system in the Project we identified needs to change parts of the

decisional structure. An interesting example is the need to split the verification6 and validation7 of the project

and project deliverables (in this case the verification and validation were the basis of decisions):

the verification and validation of the product and other project deliverables (like developed new

processes, technologies, tools, etc.) establishe whether the product (or project deliverables in general)

fulfils pre-defined and specified requirements (in terms of functionality, characteristics and other

features, confirmed for instance by a product certification from an authorised institution) and

requirements for the intended use or application, and

the verification and validation of the project is based on the achievement of predefined project

requirements (in terms of time, costs, quality and applicability of project deliverables and outcomes, and

pay back of the investment).

This separation reflects the situation that we are often faced in practice, where the validation of the product

was successful (and this situation is usually interpreted as the end of the project), however, the project

validation was not entirely successful (e.g., the control of project expenses, planned dynamics of activities or

pay back of investment have not been achieved).

Based on the design of the process model, we could identify what were the project’s decision centres

and what preconditions existed for them to make informed decisions.

As the logical continuation of decisional structure analysis the issue about the adequacy of

organisational structure could arise. Namely the precise definition of authorities and responsibilities over the

decisions is essential for the successful and transparent execution of projects.

In the presented example (the site of our action research), based on the analysis of the organisation,

we have found that authorities and responsibilities of individual players were not clearly defined and they did

not sufficiently empower people. Therefore organisational design goals have been set: the definition of a

transparent organisational structure, and the decentralisation and flattening of the organisation. Note that

even though the organisation is flattened, the hierarchy of the decisional structure is not effected, therefore

the management structure has the necessary hierarchy so as to make decisions based on the right horizons.

The result also triggered a separate change project aiming at the definition and separation of project

organisation within the enterprise from the functional units.

As demonstrated above, re-engineering of business processes is not limited just to changes and

renewal of the functional structure of the engineering design process but also it effects the decisional and

organisational structure of the process.

6 ISO 9000:2000 standard defines verification as a conformation (through the provision of objective evidence) that design and development outputs have fulfilled specified (input) requirements. 7 ISO 9000:2000 standard defines validation as a conformation (through the provision of objective evidence) that the resulting product is capable of meeting the requirements for the intended use or application.

4.2.5. ‘Plug-in’ concept of the reference models

The objective of the Project has been the development of a set of project reference models which would be

dedicated to frequently arising (repetitive) types of projects in the organisation (e.g., new product

development, application development projects etc). The developed project reference models were to

describe the functional and management structure of projects in one single model because this would have

simplified the use of the model by the practitioners.

Based on a) the observation of the nature of issues present in the execution of projects (there exist

common problems in project management and project organisation no matter what is the project in question),

b) the survey of some reference models available in the literature (the ISO9000:2000 standards, the

automotive standard ISO TS16949, APQP proposals and guidelines for Product Quality Planning), and c) the

intention to define common rules for project management, we have decided to develop this functional

reference model in two parts:

Project Enterprise Reference Model: this reference model defines the general structural characteristics

and functionality of projects (service and management part) through their entire life-cycle;

Functional Process Models (e.g. of new product development): this model captures the functional

characteristics of particular types of projects; therefore this models should present the functional

characteristic of the technical processes which are usually executed by the projects.

We call this concept 'enterprise model plug-in' because we could insert into the core Project

Enterprise Reference Model any particular Functional Process Model that corresponds to the particular type

of project. The two reference models are integrated through defining the interface of the functional process

model as a specialisation of a generic interface defined in the core Project Enterprise Reference Model.

The content and contribution of these reference models relate to the life-cycles of the Project

Enterprise and Parent Enterprise as demonstrated in Fig. 8. The figure shows a simplified representation of

the PERA/GERA life-cycle models of a Project and of a Parent Enterprise and the place of the functional

reference models of a Project Enterprise as well as the Functional Model of a particular process that fulfils

the mission of the project.

If we analyse the life-history of a project in the time dimension, the first activity is the conception

and setting-up of the project. These tasks are usually carried out by the management of a Parent Enterprise

('set-up project management' and 'allocate project resources'). When the project has been set-up it can start to

operate. Depending on the desired autonomy of project management either only project management is set

up initially - and it is project management that sets up the rest of the project -, or the entire project operation

is set up by the parent enterprise. A mixture of these two extremes is usually employed, but the separation of

these tasks at project set-up time is crucial, because this may cause uncertainty regarding the authority, and

therefore accountability of project managers.

The Project Enterprise Reference Model covers three major activities a) monitoring and controlling

of the project (usually done by the management of the Parent Enterprise, e.g. a steering committee), b)

managing and controlling the project, executed by a project manager, and c) operation of the project (through

which the project fulfils its mission), executed by the project team.

Figure 8. Recursive relationships between project entities, showing the developed reference models

The operation of the Project Enterprise (see 'c' above) is described in a functional model of the project's

mission delivery processes (e.g.new product development). This model defines the activities that belong to

the 'service' part of the PERA diagram (Fig. 8). The reference model also defines additional management and

control activities that are specific to the given type of the project (so-called 'technical management tasks').

Technical management activities could not be captured in the generic Project Management Reference Model

because they are specific to the technical nature of the particular project (e.g., the definition of the types of

checkpoints relevant for the particular engineering activity of the given project type).

It is clear from this example that activities as defined in the presented reference models are distributed

among a number of life-cycles and life-cycle stages as well as among categories of activities (service or

management type). E.g.,

'Identify and set-up project' is a typical management activity belonging to the requirement definition

phase of the project life-cycle, and performed as part of the operation of the Parent Enterprise's

management;

'Control, verify and validate project deliverables and outcomes' (see the functional process model) is also

the operational task of the Parent Enterprise's management;

'Manage and control project' as may be detailed in a requirements level GRAI-GRID model is an

operational task of the project manager;

'Deliver project outcomes' as described in the functional process model is a requirements level definition

of the 'service' part of the project, and is the operational task of the project team.

As seen from the previous example, this modular enterprise life-cycle reference model is actually a Project

Management Reference Model, the modularity being a result of abstracting generic project management

tasks in one model, and project-type specific tasks in another model. In everyday practice today Project

Management Reference Models are described in less formal form (usually in a 'Project Management Manual'

using textual description).

We emphasize that further, more detailed, reference models could be developed for subsequent life-

cycle phases of the Project Enterprise (e.g. on the preliminary design level a reference model may capture the

structure and identity of the capabilities and resources of the project).

4.3. Organisational model

With the emergence of decentralised organisations, flat hierarchies, etc., explicit knowledge about the roles

of individuals, and who is responsible for what, is indispensable for any enterprise, especially for those

operating according to new management paradigms (Vernadat, 1996).

Individuals and groups of individuals are assigned a number of roles and responsibilities. These

assignments need to be carried out concurrently and cohesively, where each may involve different reporting

lines (for instance to parent enterprise and project enterprise at the same time) and control procedures. It is

important to understand when, by whom and how decisions are made in the enterprise as well as who can

fulfil certain tasks or to replace others.

Responsibilities and authorities cannot be defined completely and consistently before processes are

described and the decisional system is designed, because responsibilities and authorities constitute only one

view of enterprise processes. The systematic use of activity, behavioural and decisional process modelling

provides a description of processes and activities of the physical (customer service & product) and

management and control levels as well as the relations between these, and through this, the explicit

allocation of responsibilities and authorities.

The description of responsibilities and authorities could be done by employment of different matrix.

Organisational matrix usually put on one-axis decisions or tasks to be carried out and on the other relevant

organisational entities (positions). Figure 9 shows a simple example of the matrix of authorities; acronyms

are used for shorthand (PR- proposal, R-Review, A-Approval, etc.).

In the presented case, the organisational design of the Project Enterprise has put emphasis on the

design of a flexible organisational structure. Flexible organisation should provide necessary autonomy for

the Project Enterprise while it also improves the accountability of project management. At the same time as

increasing the autonomy of project-related organisational entities (read as an empowerment of project

managers), projects should maintain controllable and should fit in the organisational structure of the Parent

Enterprise. To achieve this, adjustments are needed in the practices and processes of both Parent Enterprise

and Project Enterprise management.

Based on the output of this stage of the Project the role of enterprise management and project

management has been clearly defined and separated. Enterprise management (represented by the president of

the board of directors or other executive directors) approves the project proposal and project master plan

(definition of project, specification of project deliverables and expected results) and consequently validates

the project (in terms of the return on investment). In turn, the development process is carried out by a project

that is set-up by the members from different departments (for instance, from sales and marketing, R&D,

technology, production planning, purchasing, etc.) and external members. The role of the steering committee

is to control and verify the project at defined project mile-stones.

Review of requirements related to product (contract review) – type A

Project proposal

Project Master-plan

Project validation

500.000 EUR

500.000 to 1,000.000

EUR

Over 1,000.000

EURBOARD President

A A A A A

Member A A A A

Marketing Marketing VP

R R R

Project Management Project Manager Steering Committee

PRR

PRR

PRR

PRR

PRR

PRR

Finances FEO

R R R R R

Legal affairs R R R

SBU CEO of SBU

A R R R R R

Supply chain Mngr

R&D Mngr R E

Production Mngr R

Quality assurance

LEGEND: Proposal – PR, Review – R, Approval – A, Execution – E, Control – C, Assessment – AS, Request – RQ

Figure 9: The model of the project organisation

The allocation of authorities to project management substantially influences the dynamics of the

Project Enterprise. If the project manager is allowed to modify the project organisation according to the

ongoing requirements, rather then the prior organisation being dictated by the Parent Enterprise, the project

organisation can be continuously optimised by project management. The 'lost' control over the project by the

Parent Enterprise can (and needs) to be replaced by carefully designed performance indicators to allow

timely intervention, should the project digress from the intended objectives.

In addition to the explicit definition of the role of humans in the enterprise (the definition of the

organisation), the required capabilities (for any single position) and possessed capabilities (for any

individual) might be defined as well.

4.4. Decisional model of the Project Enterprise

In the design and definition of a complete decisional model of a project we have considered certain findings

of the investigation of the recursiveness model of entities in Project Enterprise and of the functional model of

Project Enterprise life-cycle. Both models show that project management and control tasks are performed by

a Parent and Project Enterprise management therefore those management tasks (decisions) belong to two

different decisional systems (those of the Parent- and Project Enterprise) which interact between themselves.

For the description of a decisional structure of a project, both decisional systems may be described

by separate GRAI-Grids (instead one single decisional Grid). The two Grids should be connected through

decisional frameworks and information links.

The resulting interrelated decisional Grids are presented in Fig. 10. Note the Grid in Fig. 10 only

represents project related decisions in the parent enterprise (other regular decision activities have been

omitted from this model for simplicity of the presentation).

5. Conclusion

The article described a Project in a company dedicated to improve the execution of new product

development projects. This was achieved through designing reusable process models to improve the quality,

reliability and efficiency of planning, project performance, as well as the management and control of

subsequent development projects. Later, the Project's mission has been extended to include all projects in the

company.

Project Enterprise activities have been described by two functional reference models:

Project Enterprise Life-cycle Reference Model that defines the structural characteristics and functionality

of projects (service and management part) through their entire life-cycle. This model is actually a Project

Management Reference Model which defines project management tasks in detail, while the 'service' part

is only defined with its interfaces and is not detailed in this model;

Functional Process Models that define the functional characteristic of the technical processes, which are

usually executed by the projects as a 'service'. For each typical technical type of service a separate such

model has been developed (initially one for new product development and one for application

development and implementation).

Figure 10: Decisional framework of a Project Enterprise

The presented method of managing enterprise reference models could be called 'enterprise model plug-in'

because we can insert into the core Project Enterprise model any particular process model that corresponds to

a particular project type. With the separation of reference models in this way we meet the requirement for

generic reference models for Project Enterprises while at the same time fulfil the needs and requirements of

particular types of projects.

Because of the special nature of management oriented tasks and processes a fully structured

description of management processes could not be achieved, except for imposing some structure at a high

level, and a procedural description of decision making at the low-level, and therefore we described all

management tasks using GRAI-Grids. Based on the recursiveness nature of entities (in this case a Project

Enterprise is created and supported by the parent enterprise) Project Enterprise management activities are

distributed between the parent company and the projects. As a result the Project Enterprise's decisional

structure is described in two separate but interrelated Grids (those of the Parent- and Project Enterprises).

In addition to the previously mentioned advantages of using Reference Models, they also proved to be:

an adequate base and communication vehicle for all project stakeholders for the exchange, presentation

and agreement on the interpretation of facts about projects and involved processes, and

an important approach that allows the transformation of informal knowledge into the form of a

pragmatic, externalised, formalised, and structured knowledge that could be spread and shared

throughout the organisation. Therefore this form of enterprise modelling could be considered as a tool for

Knowledge Management in the given business environment.

Based on our findings in the Project we can also derive some general guidelines for Reference Model

development (these might be followed and considered in the implementation of similar change initiatives):

Level of granularity of business process models. Practice shows that granularity in business process

models (required completeness of process models) depends on certain enablers. The authors recognise

four major criteria. First, the granularity of process models depends on the model (modelling) purpose or

its pragmatic needs. Second criterion considers how many shared contextual elements (considered as a

common situation and cultural-shared knowledge) among model users is present Third criterion

considers the existing (or prerequisite) competence of those people who will be users of the model. And

last criterion considers the nature of the process in question (structured, unstructured and ill-structutred)

as for instance, are the activities performed by human resource creative in nature or should be strictly

procedural.

Use of formal modelling languages. Perform BPM and BPR using formal modelling languages, tools and

methodologies to provide a common communication vehicle for all stakeholders and ensure the

reusability of the created models. The experience gained in the design and use of business process

models has shown that a basic understanding of the modelling language syntax and semantics for all

stakeholders is required. This may seem as an obvious statement, but since enterprise models are mostly

graphical, they can be interpreted by untrained stakeholders as just illustrative 'figures' or 'pictures' and as

a consequence part of the information in these graphically represented models may not be conveyed (and

this fact may remain unnoticed).

Reference models. In the development of business process reference models or in BPR it was concluded

that in many cases functional process models are more satisfactory then behavioural ones. Namely,

functional reference models express a general nature of the processes and can be instantiated according

to the particular needs. Behavioural models are useful for the purposes of simulation and certain analysis

tasks, but can only be produced if the business activity is procedural in nature. This means that some

functional models (those which are, or could be, fully implemented in an automated way) may be further

detailed using a behavioural model. Also high-level behavioural models may be constructed to describe

certain procedures, lowest level activities of which, however, are not procedural and are thus need to be

treated as elementary from the behavioural point of view.

Article in the Section 4 also points out the ISO9000:2000 standard requirements for planning and execution

of points of reviews, verifications and validations in the design process as one of the most demanding

standard requirements for application and need for the separation of control points between project and its

deliverables.

One of the deliverables of the Project was an application on Lotus Notes platform (called e-Projects)

which supports the entire Project Enterprise life-cycle. The application (Genis, 2002) supports:

efficient control of the project throughout its entire life-cycle and life-history (e.g. status of project

activities, project costs, etc.),

automation of management information flows in the project (e.g. review and confirmation of project

master plan, project reviews, verifications and validations , etc.),

standardisation, management and provision of common repository of project documents, and

work and co-operation on the project in a distributed environment (web-interface of the application).

ReferencesBernus, P., Nemes, L., 1999. Organisational Design: Dynamically Creating and Sustaining Integrated Virtual

Enterprises. in: Proceedings of IFAC World Congress, Vol-A, London : Elsevier, pp.189-194Bernus, P., Nemes, L., Morris R., 1996. The meaning of an Enterprise Model. in: Modelling and

Methodologies for Enterprise Integration, P.Bernus, L.Nemes (Eds.), London : Chapman & Hall, pp.183-200

Bernus, P., Schmidt, G., 1998. Architectures of Information Systems. in: Handbook on Architectures of Information Systems, P.Bernus, K.Mertins, G.Schmidt (Eds.), Berlin : Springer Verlag pp. 1-10

Chen, D., Doumeingts, G., 1996. The GRAI-GIM reference model, architecture and methodology. in: Architectures for Enterprise Integration, P.Bernus, L.Nemes and T.J.Williams (Eds.), London : Chapman & Hall, pp102-126

Davenport, T.H, Short, J.E., 1990. The New Industrial Engineering: Information Technology and Business Process Redesign. Sloan Management Review, pp. 11-27

Doumeingts, G., Vallespir, B., Chen, D., 1998. Decisional Modelling GRAI Grid. in: Handbook on Architectures of Information Systems, P.Bernus, K.Mertins, G.Schmidt (Eds.), Berlin : Springer Verlag, pp. 313-338

GENIS Co., 2002. e-Project: the Application Overview. http://www.genis.si/splet/v2/genis.nsf

Gobbi, C., Muffatto, M., 1999. A Reference Model for Extended Enterprises. in: Proceeding of 8th International Conference on Productivity & Quality Research, Vaasa, Finland : MCB University Press, pp. 469 – 496

Hammer, M., Champy, J.,1993. Reengineering the Corporation, New York : Harper–Collins PublishersISO JTC 1/SC 7, 2002. ISO/IEC 15288:2002 Systems engineering - System life cycle processesISO/TC 176/SC2, 2000. ISO9004:2000 Quality management systems – guidelines for performance

improvementsISO/TS 16949:2002 Quality management systems – Particular requirements for application of ISO

9001:2000 for automotive production, and relevant service part organisationsIFIP–IFAC Task Force, 1999. GERAM: Generalised Enterprise Reference Architecture and Methodology.

Version 1.6.3. http://www.cit.gu.edu.au/~bernus, accessed 2001Kalpic, B., Bernus, P., 2002. Business Process Modelling in Industry – the Powerful Tool in Enterprise

Management. Computers in Industry, 47(3) pp299-318KBSI (Knowledge Based Systems, Inc.), 2001. IDEF Methods: IDEF0 Overview – Function Modelling

Method. http://www.idef.com/idef0.html (accessed 2001)Malhotra, Y.,1998. Business Process Redesign: An Overview. IEEE Engineering Management Review. 26

(3) pp27-31Mertins, K., Bernus, P., 1998. Reference Models. in: Handbook on Architectures of Information Systems,

P.Bernus, K.Mertins, G.Schmidt (Eds.), Berlin : Springer Verlag, pp. 589-600Schmidt, G., 1998. GPN - Generalised Process Networks. in: Handbook on Architectures of Information

Systems, P.Bernus, K.Mertins, G.Schmidt (Eds.), Berlin : Springer Verlag, 1998, pp.191-208D.Stamatis, 1998. Advanced Quality Planning: A Commonsense Guide to APQ and APQP, Productivity Inc.Uppington, G., Bernus, P., 1998. Assessing the necessity of enterprise change: pre-feasibility and feasibility

studies in enterprise integration. International Journal of Computer Integrated Manufacturing, 11(5) pp. 430-447

Vernadat, F.,1996. Enterprise Modelling and Integration – Principles and Applications. Chapman & HallVernadat, F.,1998. The CIMOSA Languages. in: Handbook on Architectures of Information Systems,

P.Bernus, K.Mertins, G.Schmidt (Eds.), Berlin : Springer Verlag, pp. 243-264Warnecke, H.J., 1993. The Fractal Company, Berlin : Springer VerlagWilliams, T.J., 1994. The Purdue Enterprise Reference Architecture. Computers in Industry, 24(2-3) pp. 141

–158