Business Process Modelling and its Applications in Business Environment

Brane KALPIC*, Peter BERNUS**, Ralf MUHLBERGER***

* ETI Jt. St. Comp., Obrezija 5, 1411 Izlake, Slovenia, brane.kalpic@eti.si** Griffith University, School of CIT, Nathan, QLD, Australia, P.Bernus@cit.gu.edu.au

*** University of Queensland, Information Technology & Electrical Engineering, QLD, Australia, ralf@itee.uq.edu.au

1 Introduction

Globalisation as the process of creating of a common, worldwide and open market is one of the key features of the external environment of business systems today.

Globalisation as the result of the rapid development of information and communication technologies (fast access to accurate, reliable and adequately structured data), transport systems and consideration of common standards (which provide the world-wide comparability and compatibility of the products) (Westkamper, 1997) also allows the fusion of local and national markets into a global one and is one reason for partnership and integration between customers and suppliers, and cooperation or even mergers of previous competitors.

Unpredictability and changeability in the internal and the external environment, is experienced by enterprises as turbulence (Warnecke, 1993), and requires responsiveness and flexibility in the organisation and in the execution of processes as well.

Customer orientation and time needed to turn an idea into a final product are increasingly important elements of competitiveness. Quality, technical sophistication and price competitiveness of a product is no longer sufficient on the market. The product must be able to fulfil individual customer demands as reflected in the increasing individualisation of the production (economy of scope).

Information and knowledge are becoming strategic resources in addition to traditional ones, such as raw materials, energy and food, which used to be the basis of progress of national economies for decades (Warnecke, 1993). Therefore, information and communication technologies can be considered today as strategic technologies, and knowledge is considered as the key capital of enterprises.

The rapid changes and development in the area of new materials, methodologies, technologies, and techniques (deep integration of customers and suppliers in the product life-cycle, network and virtual enterprises, project management, concurrent engineering, modern information systems, various approaches in the product development and design, new production and logistic concepts, new production paradigms, etc.) have resulted in a rapid reduction of development time, rising complexity and functionality and reduction of cost even in the most demanding products.

All the above features of a contemporary business environment require a restructuring of business processes, achievement of their efficiency and effectiveness, improvement of their management, their higher-level integration and automation, and reusability and redeployment of knowledge integrated in processes. Therefore, there is a need for an adequate description (modelling) of business processes, their analysis and knowledge capturing and redeployment techniques, tools and methodologies.

1

This chapter presents business process modelling as the response to the aforementioned requirements. The chapter starts with the introduction of the theoretical background of business process modelling (BPM), its basic concepts and different applications in the business environment.

Section 2 gives a definition of ‘business process’ and ‘business process model’ and presents a simple abstract model of artificial systems, which can be used to define different types of business processes and categories of process models. The section also discusses the relationships between models, modelling languages and modelling tools as defined in the GERAM framework (IFIP-IFAC, 2003). Furthermore, the application of CIMOSA (Section 2.5) and of Workflow Modelling languages is presented, as well as Workflow Management as a special application of BPM and Business Process Management (Section 2.6).

Section 3 discusses ISO9000:2000 standard requirements related to business process, as well as general guidelines and an interpretation of standard requirements regarding:

the definition of business process interactions,

the identification and differentiation of product realisation and support processes, and

organisational, resource- and information models of the business enterprise. Sections 4 and 5 discuss the application of BPM in the field of business process

reengineering (BPR), as the role of BPM in Knowledge Management (KM). The authors believe that BPM is an important tool for KM in the business environment, through capturing informal knowledge in a pragmatic, formalised and structured form that could be disseminated and shared throughout the organisation.

2 Business Process Modelling

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 2.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.

2

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, 2003).

Raw materialEnergy

Information/Data

Physical systeminformation

(internal information)

Communicationwith the external

environment(external information)

Management Information

SystemOrders

Goods

Service

Management and Control System

Physical system(manufacturing/service)

By-products

Simplified PERA diagram

Life-cycle dimension

Figure 2.1: Cybernetic model of an artificial system (Doumeingts et al, 1998)

2.2 Business Processes and Business Process Modelling

2.2.1 Business process

The Oxford English Dictionary (1999) defines ‘process’ as a series of actions or operations conducing to an end, or as a set of gradual changes that lead toward a particular result. Thus, according to Section 2.1, business processes (i.e. processes performed by the ‘physical system’) are a set of activities intended to transform system inputs into desired (or necessary) system outputs by the application of system resources.

It is customary to enrich this definition with characteristic properties that stress the business nature of a process. According to Davenport (1993) and ISO9000:2000 family of standards (2000) a ‘business process’ is a structured and measured, managed and controlled set of interrelated and interacting activities that uses resources to transform inputs into specified outputs (goods or services) for a particular customer or market. Davenport also proposes a differentia specifica of business processes: every process relevant to the creation of an added value is a business process.

2.2.2 Business process model2.2.2.1 What is a model?A model1 is a set of facts about an entity (captured in some structured and documented form), provided that:

there is a known mapping between the captured facts, and the real world entity (its constituents and properties)

all consequences of these facts agree with relevant properties of the modelled entity

1 In many engineering disciplines, the word ‘model’ is the equivalent to what mathematical logic calls a ‘theory’. The definition above uses this engineering terminology.

3

no consequences of the captured facts are in contradiction with relevant properties of the modelled entity and

all relevant properties of the modelled entity are either explicitly represented in the model, or can be inferred from these facts.

Thus a simple list of facts about an entity A is not necessarily a model of A. The set of facts becomes a model only if all relevant facts are captured. Depending on the nature of facts consequences may be derived using logical rules of inference, or mathematical equations.

In simple terms: “Model M models entity A, if M answers all relevant questions about A”. Depending on the types of questions that the model is supposed to answer (the ‘relevant’ questions) many types of models can be developed, each representing and aspect, or view, of the same entity.

For every type of model there is a set of inference rules, therefore in practice the developer of the model does not have to include these with the model, provided that:

the document clearly identifies to what model-type it belongs, and

the given model-type’s inference rules are uniformly available and understandable to all – i.e. those who develop, validate or use the model (the ‘users’ of the model).

Unfortunately this second requirement is not always met in BPM, and this has a number of negative consequences. E.g. a business process analyst may request people who are routinely performing a business process to verify that the analyst’s model is a correct representation of reality. These people might unknowingly accept an incorrect model as correct (e.g. in case all explicitly represented facts are correct), and not realise that some facts may be inferred from this model that are in contradiction with reality.

Models can be built for various purposes; for documenting (so that the same or similar system may be (re)constructed based on the model), for the analysis of a system (or part of a system) and its properties (so that a particular aspect of a system can be studied).

Realworld

Semanticalgap

Model

ETI worker John computer

work withemployed inETI

worker John

computer

Figure 2.2: Mapping of the real world into the model

Modelling is an abstraction (and a mapping) of the real world into a formal representation, where the relevant facts2 are expressed in terms of some formalism (called a modelling language3). There is always a difference between the real world and model. Only a 2 To the reader familiar with mathematical logic: the word ‘fact’ is used here in its everyday meaning, covering propositions, constraints, rules, etc. 3 For the purposes of the user, a modelling language may be defined as a set of modelling constructs (and rules that govern how they can be combined to form a valid model).

4

real world system is a perfect representation of itself; models are only approximations of the real world entity. The difference between a system and its model may be considered as a form of semantical gap (see the Figure 2.2). E.g. people who are part of a system have the potential to use a unique system as a reference to share meanings, whereupon those who only see a limited set of models of this system have the potential to develop meanings different from those developed ‘within the system’. This is because even if a set of formal models is a correct representation of the system in question, they are also a correct representation of other potential systems.

Therefore, for a representation to qualify as a model, it is necessary, that there should not exist unintended interpretations. This last requirement is especially important when models are created about a future system (i.e. a new or a modified existing one).

2.2.2.2 Business Process Models as specific types of Enterprise ModelsEnterprise models are formal representations of the structure, functions (activities, processes), information, resources, behaviour, goals and constraints, etc. of a business, government or other enterprise. An Enterprise Model is model of ‘enterprise objects4’ and their dependencies (Gruniger, 1997). Models may have different manifestations, they can be expressed using different formalisms, be processable or not, and may incorporate more or less common sense, and may be expressed on different levels of abstraction and detail. Practitioners often refer to ‘formal’ and ‘less formal’ models, but according to the above definition of what a model is, these ‘less formal’ models are always incomplete representations. Incomplete representations can serve a useful purpose, e.g. for clarifying explanations, but should not be used for analysis or as a specification.

It is practically not possible to create a single all-embracing model of an enterprise. Due to the complexity and size of enterprises, instead of a single model a set of models is developed. The enterprise is therefore described by a collection of interrelated, special purpose models, each concentrating on an aspect or view of the enterprise (Bernus et al, 1996). There are various enterprise models like process, data, resource, product, computer network topology, organisation, technical and engineering enterprise models, etc.

The selection of the type of models to be developed, the need for it to be complete and consistent, as well as the level of detail and abstraction, are driven by an understanding of the current state of affairs and by the pragmatic needs of planned or anticipated future stages of development/evolution.

Traditionally, the prime goal of enterprise modelling is to support process analysis, integration, automation and computer control. Enterprise modelling is also becoming popular in the area of business design, where the way of doing business is represented as a model (defining co-operative arrangements, enterprise networks, virtual enterprises) where the model provides insight into potential strategic behaviours of planned business arrangements.

Business Process Models are a specialised category of enterprise models, and focus on the description of business process features and characteristics. For example, business process models are used for the definition of the functionality and structure of a process (sub-processes, activities and operations), the sequence of activities and their relationships, the cost and resource usage characteristics, etc.

Business process models, may be used to achieve (Vernadat, 1996):

reduction (or better understanding) of process complexity

4 An ‘enterprise object’ in this context is an enterprise or any of its constituents – whether material, information, human, technical, and irrespective of whether manifested as software or hardware – or any aggregation of these.

5

improved transparency of the system’s behaviour and through it better management of business processes

better understanding and uniform representation of the entity in question

capitalisation of acquired business knowledge and improvement of its reusability

process improvement (to improve the characteristics of business processes).

A support of the model development process is usually necessary on two accounts: 1) Reference models should be available (standards, reusable blueprints, best practice captured in form of models) so that models should not need to be build from scratch; 2) Enterprise modelling tools should be used that support the creation, analysis, maintenance and distribution of these models.

2.2.3 Categories of business process models and business process types 2.2.3.1 Categories of business process models

The purpose of modelling determines what features/properties of business processes need to be represented. There are two major categories of business process models: activity models and behavioural models.

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.

Activity models are constructed using the functional decomposition principle (for more detail see section 2.5.). These process models do not represent sequences of control (state transitions, before-after-relations, exception handling) or temporal properties (timing of process activities). Therefore, activity models are constructed if the reason for modelling is the desire to understand or design a process in terms of how it is constructed out of elementary activities and how these activities are interconnected.

Activity models abstract from time and state transitions, therefore they are useful if

the analyst/designer wants to identify the interfaces between activities of a process, and deliberately delay the commitment regarding state transitions and timing, aiming to determine these details in subsequent design step (and thereby leaving the possibility open for many different implementations); or

the nature of the process is such that every execution is likely to be different in terms of state transitions or timing. This is the case with many policy-driven and/or creative processes, i.e. every process that does not have a control flow that can be pre-determined by design.

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 – the need to do so depends on the reason for developing the model.

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, the in the development of simulation models). Behavioural models are executable representations of a process (similar to a computer program), thus they can also be used for process control (or

6

process tracking), in which case they also need to represent the objects exchanged and resources used.

In addition to the representation of the control flow, behavioural models might also incorporate:

exception handling mechanisms - definition of possible process scenarios and their relations

temporal aspect – the dimension of time (e.g., activity durations – minimum, maximum, average or standard times, delays between process activities, triggering frequencies, and possibly the probability distribution of the above, etc.)

co-operative activities – the definition of message exchange (e.g. data/information views described as objects, naming the objects exchanged, defining their structures and states) and material exchange (volumes, batches, etc). Message exchange may be defined using either of two ways – the mechanism of sharing and the mechanism of passing. Co-operative activities use predefined operations (request, receive, send, broadcast, acknowledge) that may be built into the modelling language

process synchronisation - synchronisation may be synchronous or asynchronous and achieved through events, messages or object flows

pre-conditions and post-conditions to be satisfied / completed by the process and its constituents.

2.2.3.2 Business process typesManufacturing and other business processes (e.g. engineering, design, production, etc.) performed in the physical system (see the structure of the cybernetic model) can be described by activity- or behavioural models.

While activity models can always be developed, behavioural models are feasible only for processes that follow known procedures or known rules or transition, 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 process 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 are interpreted by managers with a defined level of expertise and competency, and commonly believed assumptions.

As the description of management tasks becomes less structured (and even if a structured description exists) such a description is only a guideline, with the only constraint from the enterprise's point of view being that the task is performed to produce the desired outputs or deliverables and that while performing the management task the human involved will have considered nominated crucial inputs to come to the decision. The exception to this relaxed definition is the interface between the unstructured management tasks where the enterprise still may wish to enforce procedurally defined communication protocols. It is only at the lowest

7

level of management that management tasks become control functions, thus the control system can be defined through structured processes and procedures or behavioural rules.

As a consequence of the above discussion, a great deal of care must be taken when developing a model in support of the design of a management system (see the section 3.1). At every level of structuring the description into a model one must ask the question whether further detailing the task is legitimate and useful, meaning whether the task is structured, unstructured or ill-structured. Mistakes in this regard are costly, because they may discredit the model in the eyes of its users.

2. 3 Generalised Enterprise Reference Architecture and Methodology (GERAM)

In order to discuss business process models and their role in the wider scope of enterprise modelling the GERAM Framework is briefly presented below (GERAM: Annex A, ISO 15704:2000). While many other popular frameworks exist, this framework generalises their common characteristics. For mapping other popular frameworks onto GERAM, such as ARIS, Zachman, CIMOSA, PERA, GRAI, C4ISR/DoDAF see (Noran, 2003).

2.3.1 GERAM framework

GERAM (Generalised Enterprise Reference Architecture and Methodology) is about those methods, models and tools which are needed to build and maintain the integrated enterprise. GERAM also represents a tool-kit of concepts for designing and maintaining all types of enterprises for their entire life-history. Figure 2.3 represents the components of the GERAM framework (IFIP-IFAC, 2003).

The GERAM framework identifies as its most important component GERA (Generalised Enterprise Reference Architecture) defining the basic concepts to be used in enterprise engineering and integration. GERAM distinguishes between the methodologies for enterprise engineering (EEMs) and the modelling languages (EMLs) that are used by the methodologies to model the structure, content and behaviour of the enterprise entities in question.

Methodologies propose to create and use enterprise models (EMs) to represent all or part of the enterprise’s operations, including its manufacturing and service tasks, its organisation and management, and its control and information systems. These models can be used to guide the implementation of the operational system of the enterprise (EOSs) as well as to improve the abilities of an existing enterprise.

8

Figure 2.3: GERAM framework

The methodology and the languages used for enterprise modelling are supported by enterprise engineering tools (EETs)5. The semantics of the modelling languages may be defined by ontologies, meta-models and glossaries that are collectively called generic enterprise modelling concepts (GEMCs). For enterprise models to be consistent these ontological models must be consistent – e.g. a meta-schema may describe all concepts used in a set of modelling languages, where each uses only a subset of these concepts. If the meta-schema is extended with all logical rules and constraints then the semantics of the modelling languages becomes fully defined and the definition is called an ontological model. Since ontological models are usually developed by logicians, logicians prefer to use the mathematically correct term ‘ontological theory’ instead of the engineering term ‘ontological model’.

The modelling process may be enhanced (made faster and improving quality) through using partial models (PEMs), which are reusable reference models of human roles, of processes and associated information, and of technologies.

The implementation of enterprise models is supported by enterprise modules (EMOs) which are actual building blocks – physical or software resources – such as humans with skills, equipment, etc. and which are used to build (manifest) the actual operational enterprise (EOS) as a socio-technical system. Some of these modules may be pre-existing (humans with skills that the enterprise can hire, products, software) and some may have to be built (by training humans, commission hardware and software) or configured.

2. 3. 2 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 Figure 2.4):

5 If the entity in question consists only of software then the term CASE (Computer-aided Software Engineering) Tool is used instead.

9

Life-Cycle Dimension – describes a controlled modelling process of enterprise entities according to the involved life-cycle activities; the GERA life-cycle model defines a total of six life-cycle activity types or life-cycle 'phases' of an entity (some other frameworks may define less or more life-cycle phases in the definition of the entity's life-cycle depending on the level of detail of this classification). The life-cycle concept represents a useful abstraction in understanding the life-history of any entity (which could be difficult to understand because of its complexity and individual idiosyncratic properties). According to ISO 15288 (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. Thus, the life-cycle is a temporal and is subdivided into phases, while the life-history is temporal, and is subdivided into stages.

Figure 2.4: Modelling framework of GERA

Genericity Dimension – describes a controlled particularisation (instantiation) process from generic, through partial, to particular,

View Dimension – describes a controlled visualisation of specific views of the enterprise entity – entity model content (function, information, resource, organisation), purpose (mission delivery, management & control), implementation (human, machine) and physical manifestation (hardware, software) views. Any combination of these defines a legitimate scope of modelling, but depending on the modelling purpose the detail of these models may be different. E.g. the function view may be filled by an activity model, or by a behavioural model, or both (provided these two are consistent).

2.3.3 Business process modelling languages and tools

Enterprise modelling languages are defined and formalised as the Generic Enterprise Modelling Concepts in one of the following ways:

10

by natural language explanation of the meaning of modelling concepts (glossaries)

in some form of meta-model (e.g. entity relationship meta-schema) or

in ontological theories – as formal models of the concepts that are used in enterprise representations, and are usually expressed in a (possibly extended) form of First Order Logic.

An ontology is a formal description of entities and their properties; it forms a shared terminology for the object of interest in the domain, along with definitions for the meaning of each of the terms. The definition of ontology consists of (IFIP-IFAC, 2003):

Terminology – providing a shared terminology for the enterprise, that every application can jointly understand and use;

Syntax – defines all legal constructs of the language. The syntax definition makes it possible for a parser to examine a proposed expression, or a complete model, and accept it as a legal (or reject it as illegal);

Symbology – defines a set of symbols for depicting terms and concepts, often in a graphical form;

Semantics – defines the meaning of the expressions written in the language. There are two usual ways to define the meaning of a language in a formal way: denotational (model theoretic) semantics, and operational semantics6 (it is necessary to define for this purpose a set of axioms and inference rules). The informal specification of a language’s semantics usually includes the formal presentation of syntax and is accompanied by a natural language description and explanation of concepts.

Ideally, a modelling language must have a formal syntax and semantics. In terms of the level of syntactic and semantic formalisation, modelling languages can be classified as: a) formal, b) semiformal, and c) informal languages.

Modelling languages also differ based on their expressive power. E.g. some business modelling languages may not be suitable for the description of all relevant facts of the subject area, and are not appropriate for certain analysis tasks. There is no one language, which is equally suited for all modelling purposes (structure or behaviour description, activity relationships and dependencies, cost analysis, simulation or emulation purposes, etc.). Also any subject area of modelling may be covered by more than one modelling language (IFIP-IFAC, 2003). This fact causes significant confusion for practitioners, because a) many languages need to be mastered, b) in the process of developing a model the practitioner may realise too late that the expressive power of the language is limited, forcing informal and idiosyncratic extensions to the language, c) the language is suited for a given life-cycle phase, but not to a subsequent one, thus model content must be translated from one language to the other.

In practice today, many different business process modelling languages are used, e.g. SADT (Structured Analysis Design Techniques), IDEF0, IDEF3, ARIS-Event Driven Process Chain (EPC), UML (Unified Modelling Language), Yourdon Data Flow Diagrams (DFD), CIMOSA function view language, FirstStep (enriched CIMOSA implementation built into the FirstStep tool), GRAI Grid, GRAI Nets, SA/RT (real-time structured analysis), Workflow Languages, Petri-nets (simple, coloured, timed), IEM (Integrated Enterprise Modelling), etc. Because of the nature of the (visual) perception of a human being, the majority of modelling languages has a graphical symbology.

The Draft International Standard ISO DIS 194407 ‘Constructs for Enterprise Modelling’, developed jointly by CEN8/TC 310/WG 1 and ISO TC184/SC5/WG1, defines (both

6 Further discussion of these is beyond the scope of this chapter.7 As of April 20038 CEN: European Standardisation Organisation

11

in English and using UML meta-schemata) a comprehensive set of requirements that enterprise modelling (and specifically process modelling) languages need to satisfy. The standard originates from the CIMOSA languages, extended with decisional modelling constructs, but a complete definition of the syntax and semantics of these languages is not part of this document, and especially the detailed design (coding) level is not part of this standard.

At the same time, a number of commercial systems have been developed that implement proprietary Workflow Languages that are suited for the implementation level description of business processes and thus can be executed in a Process Execution Environment (Workflow Environment). A detailed description of the state of the art of Workflow Systems is given in Section 2.6.

As of today (2003) many Enterprise Engineering/Enterprise Modelling Tools allow the specified process models to be exported to Workflow Systems (by dedicated translation). The result of this translation is a workflow, which then must be completed by adding implementation-level details.

For the efficient development and implementation of business process models, modelling languages must be supported by adequate enterprise engineering (modelling) tools. Enterprise engineering tools should support the entire life of these models (from the design, up to its implementation, redesign, distribution and storage).

Enterprise engineering tools should provide user guidance through the modelling process (information gathering, model building), support model analysis (simulations, evaluations, etc.), enable the connection of process models with the actual business process, and keep models up-to-date.

The ideal modelling environment should be modular and extensible (rather than based on a closed set of models), so that alternative methodologies can be used in conjunction with the already existing ones (e.g. through enriching modelling language constructs, or adding new views, as appropriate).

On the market, different modelling tools (software vendors) for the same modelling language can be found. E.g., the IDEF family of languages is supported by the following tools 9

(Tool/Language–Vendor): AI0 WIN (IDEF0 – KBSI), ProSim (IDEF3 – KBSI), AIWIN/BPWin (IDEF0, IDEF1X, IDEF3 – Computer Associates), CORE (IDEF0, EFFBD10 – Vitech Corporation), Workflow Modeler (IFEF0, IDEF1X, Workflow – Meta Software), Systems Architect (IDEF0/1X/3, UML – Popkins Software).

Because of the limited expressive power of any particular process modelling language and/or the functionality of the supporting modelling tool a set of complementary modelling languages and tools is usually needed. This also results in the need to exchange models between different tools. The exchange of process model information is very limited today, the reason for this is the diversity of tool native formats (which are not interoperable with other modelling tools) and of modelling language constructs (even though there may be a well defined language syntax and semantics, languages used for the same purpose may be based on incompatible ontologies).

The Process Interchange Format Working Group has proposed the development of a process interchange format (PIF) to help automatically exchange process descriptions among a wide variety of business process modelling tools and support systems. Instead of having to write ad-hoc translators for each pair of such systems, each system will only need to have a single translator for converting process descriptions in that system into and out of the common PIF format. Then any system will be able to automatically exchange basic process descriptions with any other system (PIF Working Group, 2003).

9 It is not the intention of this chapter to present a complete list, only examples are given.10 Extended functional flow block diagrams (proposed for next UML extension)

12

PIF aims to support the sharing of process descriptions in such a way that that they can be automatically translated back and forth between PIF and other process representations with as little loss of meaning as possible. If translation cannot be done fully automatically, human effort needed to assist the translation should be minimised.

2. 3.4 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.

E.g., the LOTOS process modelling language was developed to model the behaviour of computer network communication protocols, and to allow for the analysis of all possible executions. LOTOS is based on Process Algebra – for a detailed discussion of the language refer to ISO 8807:1989 and van Eijk et al (1989). Interestingly the language has not been used for business process modelling (in the knowledge of this chapter’s authors), in spite of its features that would make it a candidate for such use.

2.4 Business Process Modelling Principles

2.4.1 Process decomposition

Business processes can be very complex, being composed of several hundred activities and numerous relationships among them. Therefore, some process structuring is usually required (using process decomposition or aggregation).

13

Section 2.5 will discuss the CIMOSA process modelling language that allows the specification of business processes, together with the objects it manipulates11, the resources used and the organisation (allocation of responsibilities) as well as the translation of this specification to computer representations that can be executed in a process execution environment. A process execution environment allows processes to execute so that the process can communicate with both human and automated resources (machines, application programs, databases), through appropriate interfaces. Such an environment maintains the description of process types, and keeps track of each execution of these (process instances). Multiple instances of the same process type may execute at the same time.

2.4.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 level of the human user.

2.4.3 Modelling approach

Two different approaches in process model development are usually referred to: the bottom-up and the top-down approach (KBSI, 2001a).

In the bottom-up approach, the building of business process models is started from the most detailed description (operations or activities) up to a more general description (sub-processes or processes). This way of building of process model is often proposed for the development of AS-IS models (i.e., the modelling of existing processes).

The top-down approach develops the process description from the definition of basic features, or so-called high-level functional definition, into a detailed description, or low-level, definition. This approach is often proposed for the creation and definition of radically new TO-BE models or models of a future state or system behaviour.

Often the combination of these approaches is used in process modelling practice. For example, in the development of an AS-IS model first the high-level or general description of the

11 Called object-views in CIMOSA

14

process is carried out (rough definition of processes and roles of employees, to define the context and scope of modelling), followed by the detailed definition of process activities and lower process entities on the basis of actual tasks that are performed in the company.

2.5 CIMOSA process modelling languageCIMOSA includes constructs (AMICE, 1993) (Kosanke, 1992) to model processes as

well as information, resources and organisation. These constructs exist for the requirements, architectural design and detailed design life-cycle phases of GERA (called requirements, design and implementation in the CIMOSA modelling framework). In this section only the process modelling aspect of CIMOSA is discussed.

CIMOSA has a set of features to organise the process model into manageable modules. In CIMOSA, an enterprise is viewed as a collection of domains (see the Figure 2.5). A domain is a functional area achieving some goals of the enterprise (e.g., sales, purchasing, R&D, production, etc.). A domain is composed of stand-alone processes, called domain processes and interacts with other domains by the exchange of requests or objects.

Each domain process is triggered by some event (solicited or unsolicited), and is composed of a chain of activities, producing defined deliverables. Domain processes ignore organisational boundaries; therefore, the scope of domains should not be confused with the scope of an organisational unit.

A domain process could be further decomposed into business processes12, and eventually into enterprise activities. Relationships between activities are defined as behavioural rules.

On the level of detail that corresponds to the GERA preliminary design phase a CIMOSA activity is the lowest level of process decomposition, such that each activity can be allocated to one resource capable of performing that activity.

DP1

DP2

DP3

DP4

Domain

PP1 PP2 A1

A2 A3 A4

O1 O2 O3DP…Domain processA…..activityO…operation

Figure 2.5: Business Process DecompositionOn the level of detail that corresponds to the GERA detailed design phase CIMOSA

activity may be further described as a procedure (making CIMOSA on this level a workflow modelling language). This procedure consists of process logic and functional operations. A functional operation is a command or request understood by the resource that is to perform the activity. Thus, a detailed design level CIMOSA process model can be used for model-based control of business processes. Note that such a procedure is a generalisation of what is

12 According to this chapter’s definition of a ‘business process’, a domain process is a top-level business process.

15

commonly understood as a computer program. A computer program is executable by a computer and its external devices, whereupon a CIMOSA procedure may be executed by an automated resource (e.g. a software application, a tool, a robot, a communication device, etc.), or a human resource. Developers of CIMOSA procedures assume that all resources are interconnected by an integrating infrastructure that allows the execution of the procedure and the transparent delivery of messages between resources and CIMOSA procedures.

2.6 Workflow Management

Whereas business process modelling on the requirements specification and design level concentrates on understanding the workings of an organization to analyse and improve its processes, workflow management focuses on a highly automated implementation of processes using the organisation’s software infrastructure. Workflow technology therefore not only includes an executable modelling language (Workflow Language), but also the technology that enacts these process models.

2.6.1 Abstraction of Process Management

To understand the role of a workflow management system (WfMS) in an enterprise’s ICT environment, it helps to review the role of management systems in general within software development. A strong analogy can be drawn between workflow and database management in terms of management systems as the abstraction of a specific class of functions out from applications. Historically, applications used to operate on data within main memory only. As these data were lost when the application exited, application programs were modified to use the file system as a data store. This involved data structure specific code within the application that manages the interaction with a file (reads or writes specific data). Other applications now had access to the same data due to the shared nature of file systems, which caused a number of data management problems. Any application changing the file structure, e.g. due to the need to add some extra information, affected not only the file itself, but also the data management code in all other applications which needed to be aware of the file structure. Eventually it was realised that rather than repeating the same file access and data management functionality within every application it would be more efficient to have a separate application, the database management system, that can be asked to manage the data and serve it to any application that needs access.

Similarly, many applications have business process logic embedded in them. Examples include code that passes control to the next application to be executed in a process and code that specifies the order of execution through menus. WfMSs store a schema for such processes in the form of workflow templates, i.e. process types marked up with the extra information required for the system to

identify specific actors for whom to schedule tasks

invoke applications to enact the tasks of the process

pass information between different tasks of the process

Workflow instances are created by the workflow enactment engine, which then also tracks the ongoing execution of tasks during the life of the process instance.

It is to be noted, that because workflows are implementation level process models, some tasks are carried out by application programs, while other tasks are carried out by some equipment or by humans, thus a complete workflow system should have suitable interfaces to any functional entity that understands requests directed to it. Furthermore, given that human tasks are involved, the model-based control implemented by workflow execution should not

16

consider the human as a machine, thus workflow programmers must give consideration to the type of process logic that is suitable for such heterogeneous execution environment.

2.6.2 Architecture

The basic architecture of WfMS is well described by the original Workflow Management Coalition Reference Model (D.Hollingsworth, 1995). Although the division of interfaces has been revised, the framework of describing a workflow system as a combination of six modules is nevertheless very useful. These modules are:

Design tool

Enactment engine

Management and monitoring tools

Work list handler

Invoked applications

Remote enactment engines

An issue in workflow management, that is still under development, is the provision of views over the execution status of each process instance, allowing for an increased level of security while permitting clients and low-authority staff to monitor aspects of the process relevant to them. This helps increase the awareness of corporate knowledge by staff, and provides a valuable service to clients, e.g. as demonstrated by the packet tracking mechanisms of FedEx implemented using workflow technology. Opening complete access to the management & monitoring layer of a WfMSs may not be a wise idea if such a view mechanism is not available, given that details of business processes are increasingly the focus of corporate differentiation thus companies would not want to have these publicly viewable, e.g. by the organization’s competitors.

The work list handler is the main interface to a workflow environment for people working in a process driven organization. The application needed to enact a task within the process is invoked when a task is selected from the work list.

Remote enactment engines are included in this architecture to support distributed workflow execution, such as in virtual enterprises or, in general, inter-enterprise processes.

To provide more flexibility in the support of a business that requires both repetitive as well as ad-hoc/creative processes, integration between production WfMSs (such as IBM’s MQ Workflow and collaborative computing workflow tools such as provided by Lotus Notes) are another aspect of the remote enactment service facility of workflow architectures. See (Lin et al, 1997) for a description of such integration.

2.6.3 Design Principles and Issues

The abstraction of process management out from the underlying applications leads to a basic design principle for workflow models, i.e. that the models be clearly abstracted and separate from the application logic. This design principle addresses the issue of granularity within workflow modelling, i.e. the granularity is driven by the applications that are implemented beneath the process management layer. From a structural perspective, there are a number of flaws that can occur in process designs that such design principles will not help to avoid. The two key problems are deadlock and lack of synchronization. These have been addressed in workflow modelling through work such as (Sadiq et al, 2001).

17

2.6.4 Workflow from a data perspective

The added benefit that workflow management systems provide is that they can act as a platform for the integration of the disparate data sources (Muhlberger and Orlowska, 1996) that a business process involves, regardless of the technology that is used for the management of that data. A workflow may interact with a number of data sources, from heterogeneous database management systems, multidatabases, file systems and any other type of data source, through a communications layer and the applications that interact with those data sources. The communications layer itself can also involve bridging technologies, such as CORBA or DCOM layered on top of other communications protocols such as TCP/IP.

Workflow thus becomes a type of distributed information management technology that can be used to manage data for interoperable systems. Production workflows in particular, on which this Section is focused, involve the coordination of organisational information processing systems that are usually based on database management systems but can encompass other, non-DBMS architectures, having multi-tier, client-server architectures with a central workflow server responsible for management of business processes. These workflows, in contrast to ad-hoc or administrative document management workflows, have well defined procedures, rigorous and multiple repetitive process instance executions that may span several heterogeneous information systems.

Treating workflow as a generalisation of multidatabase13 transactions highlights the other issues that need to be addressed in a workflow, and indeed all process management. WfMSs are complex software products that should provide a number of functions/services to different groups of users. They should have extensive features to define the internal task structure, control the execution of activities involving different types of processing entities, and support reliable forward recovery services (for system failures) and backward recovery services (for external actions such as cancellation of a customer request). In other words, workflow management should provide for a form of atomicity, consistency, isolation and durability, similar to the classic database transactions’ ACID properties. These requirements need to be relaxed however, due to the long-running nature of workflow processes compared to database transactions. For example, for consistency, the underlying systems only need to be integrated for any data affected by the process instance, and then only along the flow of execution of that instance, rather than all information sources maintaining all dependencies across systems at all times.

2.6.5 Workflow Modelling Languages

Due to the implementation focus of workflow management, there are as many workflow language dialects as there are workflow enactment engines, design tools and workflow researchers. This is due in part to the independent development of workflow management systems, and also to the value added that differentiation brings to every workflow vendor.

From a process abstraction perspective, however, the options that are available to model a process are more limited. Common constructs used are:

Simple tasks, i.e. that describe an actual application or action performed by an actor in the system.

Block (aggregate) tasks which form a logical grouping of simple tasks.

Sub-process tasks, which invoke a new process instance in place of a simple or block task.

Control flow connecting tasks in an asymmetric, directed order.

13 Multidatabase management provides the logical integration of pre-existing databases through an integrated global schema and a transaction manager that generate global query plans issued to the participant database systems (transparently to the user), and without modification of the participant databases. In fact, users need not know that they are participating in a federated information architecture.

18

Splits, which can be a forking of the process path or describe exclusive or inclusive selection of paths. These are known as AND-Split, XOR-Split and OR-Split respectively.

Joins to recombine parallelism in the design of a workflow template. As for splits, these may be AND-Joins, XOR-Joins or OR-Joins.

The above information is commonly represented using a graphical notation. Extra information (not usually represented in the graphical notation) needs to be added to complete the workflow program: e.g., which application a task invokes when it is executed; which actor (or the role defining actors) that can execute a task; and in some modelling languages even the data that is passed between tasks in a workflow process. Furthermore, the level of constraints that a workflow designer could specify also varies from implementation to implementation.

3 What ISO 9000:2000 standard requirements must business process models satisfy?

The ISO 9000 family of standards has been developed to assists organisations to implement and operate effective quality management system (QMS). The ISO 9000 standards specify requirements14 for a QMS where an organisation needs to demonstrate its ability to provide products and services that fulfil customer- and applicable regulatory requirements, to enhance the satisfaction of customers and other interested parties, and improve the performance of the organisation (ISO/TC 176, 2000).

The ISO9000:2000 requirements can be interpreted in the context of enterprise modelling: this standard may be understood as a policy / requirement level enterprise reference model applicable to all types of enterprises15. Consequently when enterprise models are developed (as may be captured as function & process, information, organisation and resource modelling views) they must satisfy the required ISO9000:2000 quality properties.

The ISO 9000:2000 standards define requirements for business process performance monitoring, identification of the organisation’s strengths and weaknesses, assessment of the QMS’s maturity level, continuous improvement, complementing quality objectives with other objectives related to growth, founding, profitability, etc. ISO9000:2000 therefore extends the traditional QMS to more general management system of the organisation.

The ISO 9000:2000 family of standards is based on eight quality management principles:

customer focus

leadership

involvement of people

use a process approach

use a systems approach to management

continual improvement

factual approach to decision making and

mutually beneficial supplier relationships.

14 The ISO9000:2000 series of standards consists of requirements (ISO9001:2000) and guidelines (ISO9000:2000 and ISO9004:2000)15 According to the GERA life-cycle phases.

19

Two of these principles (process approach and system approach to management) capture general requirements directly related to the identification, definition and description of business processes.

The ISO 9000:2000 standards, as a requirement specification and policy level standards, 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 introduction of business process related requirements is new in ISO9000:2000, and is the first time that a wide scale deployment of BPM is required from the those who adopt a QMS. As a response, organisations not familiar with BPM often develop in-house business process modelling languages, methodologies and approaches. These languages are usually characterised by a weak definition of the modelling language’s syntax and semantics, and consequently by low uniformity and unequivocality of process descriptions. Non-systematic approach to business process description could lead to a limited (re)usability of the created business process models, and might not even satisfy the criterion to be called a model in the strict sense of the word (see the Section 2.2.2.1).

The aforementioned requirements of the new ISO9000:2000 standards and the recognition of obstacles to the implementation of BPM has lead the authors to develop general guidelines that can be followed to improve the efficiency, and support the practical adoption, of BPM in industry, with the aim of satisfying the business process related requirements of ISO9000:2000.

3.1 Business process modelling related requirements of the ISO 9000:2000 standards

From the eight quality management principles in ISO 9000:2000, two may be considered as BPM related principles (ISO/TC 176, 2000):

process approach which ensures that the desired result is achieved more efficiently when activities and related resources are managed as part of a process (where the management of activities and related resources is not limited to, or constrained by, functional, divisional or unit borders), and

system approach to management, which requires the identification, understanding and management of interrelated and interacting processes as a system.

To implement a QMS, the ISO 9000:2000 requires that the organisation must:

Identify the processes needed for the QMS and ensure their application throughout the organisation;

Determine the sequences and interactions of these processes;

Determine necessary criteria and methods, which ensure that both the operation and control of those processes are effective;

Ensure the availability of resources and of information necessary to support the operation and monitoring of processes;

Monitor, measure and analyse business processes.

In Sections 2.2.3.1 and 2.2.3.2, we described two types of process models (activity and behavioural), as well as three main process categories (structured, unstructured and ill-structured processes). The ISO9000:2000 standard requirement for the determination of the ‘sequence of processes’ could unintentionally create an expectation and assumption, that all processes are suitable for a uniform description / modelling (using a single process modelling

20

language) and that they can always be described by behavioural process models. Unfortunately, this expectation isn’t uncommon in present-day practice.

1

2

Welding

Welding

CP_ACP_B

SP_1

WP1

WP2

QP1

Drawing1

3

Assembly

SP_2

ASS

CP_C

SP_3

Product

QP2

Event3Event3

VV

Activity2Activity2

Activity1Activity1

Event2Event2

Activity3Activity3

Event1Event1

Figure 3.1: a/ Activity process model, b/ Behavioural process model

In addition to structured processes (e.g. accounting procedures, technological procedures, etc.), many unstructured (e.g. new product development process) and ill-structured processes (e.g. innovative processes) exist in an organisation. Considering a) business process properties (and consequently their suitability for modelling) and b) standard requirements about the determination of process sequences, it can be concluded that:

Interpreted in a strict way, the requirement of the ISO standard to determine the ‘process sequences’ can not always be met;

Interpreted in the spirit of the standard, ‘sequences of processes’ would better be understood as the modelling of the structure and relations of processes – where the structure is the composition of processes out of more elementary processes and activities, and the relations include information- and material exchange (interfaces), and/or succession sequences and events, and/or relations in time. The decision about which one of these relations to model depends on the process category, and thus appropriate process model types (and, accordingly, modelling languages) need to be used. Furthermore, the model(s) of business process structure and relations may have to capture additional characteristics that are essential for process design, prediction, analysis, planning, scheduling and control; and

In general, the use of a combination of behavioural and activity process models (modelling languages – see the Figure 3.1) is necessary to model business processes.

In addition to the description of operational processes (processes at the ‘physical’ level in the cybernetic model of artificial systems), a great deal of care must be taken in the identification and definition of management processes. Given that the majority of management processes are either unstructured or ill-structured, in the selection of an adequate model type these process characteristics must be taken into account.

As a response to the particular nature of management processes, the GRAI laboratory has introduced the GRAI methodology for a management-oriented description of an enterprise.

The GRAI methodology proposes to develop a high level model of management processes using a GRAI-Grid. The graphical modelling language GRAI –Grid does not aim at the detailed modelling of management processes but a) identifies decision roles (also called decisional centres) where decisions are made and communicated, and b) defines the decisional hierarchy through connections and interactions among these decisional centres (Dumeingts et al, 1998). The processes of decision centres may then be further detailed as management processes, and modelled using a functional or a behavioural modelling language.

21

As a first step in developing this high level model of a management system, the decisional centres (see the individual squares of the GRID in the Figure 3.2.a.) are identified. As a second step, each decision centre’s objectives, constraints, decisional variables, required inputs and delivered outputs may be added; these together are called a decisional frame of any individual decision centre. As a third step, the task to be performed to create a decision may be described (e.g. in natural language, as a list), which completes the high level decisional model.

The detailed model of decision making processes can be developed – depending on the nature of the process – using a functional (activity) model (KBSI, 2001a) or a behavioural model (KBSI, 2001b). However, often only a detailed natural language description is used. The detailed model may of course be different in granularity from decision centre to decision centre, depending 1) on the level of formalisability of the decision process in question, 2) on the intended skill levels of human resources to fill these management roles, and 3) on the formalisation needs of the links among decision centres.

h=1yp=3m

h=1mp=1w

h=1wp=1d

realtime

horizonperiod

I/Omngm

co-ordination/planning

resourcemngm

Decision framework for DC1(OBJECTIVES, CONSTRAINTSAND DECISION VARIABLES)

Decision framework for otherDC ensured through DC1

Inputs

(Intra- and inter systemic)

Outputs

(Intra- and inter systemic)

DC1

Figure 3.2: a/ The GRAI-Grid concept, b/ Co-ordination links between DCs

Assume, that a decision has been made to achieve some objectives by some time in the future (defined by a time horizon), and suitable activities are planned for this purpose. According to quality management principles the execution and results of this plan need to be monitored. If performance indicators (the feedback from the physical system) show that there is a deviation (or likely deviation) from achieving the objective, adjustments must be made either to the decisions or to the objectives. Performance indicators must be developed and suited for the set of objectives at hand and are part of the information links that flow among decision centres, the physical system, and the external environment.

The structure of this information flow (especially if this information needs to be stored in a database) has to be modelled using a language suitable for data modelling (e.g. using Entity Relationship modelling, the IDEF1X modelling language, Class diagrams/UML, or similar).

22

Financial transaction recordsMinutes of meetingsProject documents

Client requestsCustomer dataMarket investigation data

Customer confirmation of product

Allocate and adjust resourcesAllocate budgetAssign roles and responsibilities

Approve orders and payments, Control project operations

Internal resource availabilityAggregated financial records Weekly/monthly reports of project team

Distribute workloadsDevelop or acquire project resources, balance budget

Control delivered services and raw materials

Schedule project activities

Monitor project

Develop make or purchase policies, quality control plans, take make or purchase decisions

Develop detailed project plan

Verify and validate product (as project deliverable)

Financial and non-financial strategic performance indicators

Agree and decide on product requirements specification

Negotiate client requirementsDecide high level productspecsifications

Verify and validate projects (Steering Committees)

Determine activities needing project organisation

Develop projectproposal

Approve/revoke proj. proposals

Monitor strat performanceProposeresource dev.plan, budget, investment, resource allocation plansSelect plan options

Proposed sales, marketing and procurement plans

Determine company strategy:mission, vision, strategic objectives, policies, principles, performance indicatorsStrategic activities/programmes

Product & production historyResource and production cost statistics

Propose deployment and development strategy of resources and capabilities

Propose market strategy and propose product strategy

Market analysis reportsBenchmarking reportsBest practice information sourcesFundamental research reports

Develop projectmaster plan

ApproveMasterPlans

Assess resources and capabilities to determine

project feasibility

Records of demonstratedcapabilitiesResource availability from ERP system

Project Enterprise Reference Models

Requirements analysis report

Regular checkpoints and milestone reports of projects

External resource availability

Technical management decisions Work allocation decisions

Supplier, service provide details

PARENT ENTERPRISE

PROJECT ENTERPRISE

External info. To manage products To plan To manage resources Internal info.

Figure 3.3: A GRAI-Grid model (high level model) of the decision centre of two enterprise entities: a parent enterprise and a project, showing decision centres and their relationships

A GRAI-Grid model is a road map of key decisions (decision-making processes), their interactions (shown as decisional frameworks and information links) and relations (shown as a hierarchy of decision centres). A decisional model is valuable for the design of an efficient and effective organisation.

The GRAI-Grid can be used for the description of the functions of the management and control system on the high level (see the Figure 3.3). Starting from this model there is a choice to further model, on the detailed (‘micro’) level, the activities of decision centres. The GRAI methodology proposes the use of GRAI Nets, but other process modelling languages might also be used (IDEF0, CIMOSA, Workflow modelling language, etc) – whichever suits the given process category.

The selection of an appropriate modelling language would be based on a) what the model will be used for, b) what tools are available that can manage these models, and c) what languages are best fitted to the people who will use the models.

To improve the efficiency of business process modelling, the organisation should adopt an enterprise integration methodology, and develop or deploy a business process (or rather enterprise) modelling workbench that supports a set of well-formalised and interrelated modelling languages and tools. Such a workbench should be populated with the reference models that were adopted by the enterprise, and with particular enterprise models: AS-IS models, and various versions of TO-BE models (for the discussion of the variety of TO-BE models see (Hysom, 2003)).

3.2 Business process interactions

The ISO 9000:2000 standards refer to the process approach and processes interactions as follows (ISO/TC 176, 2000): “For organisations to function effectively, they have to identify and manage numerous interrelated and interacting processes. Often, the output from one process

23

will directly form the input to the next process. The systematic identification and management of the processes employed within an organisation and particularly the interaction between such processes is referred to as the process approach.”

While in theory all business processes (their structure, interaction of process activities, object flows, etc.) could be described in a very detailed and consistent way using functional (activity) or behavioural process models, the definition of process interactions does not necessarily require a fully detailed specification (description) of every process in question. The focus is on the definition of process interactions through the identification and description of the exchanged objects. The development of a complete and consistent (functional or behavioural) model of all interacting processes could be very difficult (or even not feasible) in practice. However, to fulfil the demands of the standard to define process interactions, a mixture of high-level and detailed functional models may be satisfactory.

Furthermore, functional modelling languages many times demand a detailed definition and specification of modelled processes. Therefore, the designed system of interacting processes could appear very complex and without emphasising the description of process interactions.

P1

P2

P3

Envir-onment

I I

O

O

X1 X2

X3

transformation inputCONTROL

feedback

Figure 3.4: The process interaction matrix

To emphasise process interactions, the authors propose the application of a simple process interaction matrix (see Figure 3.4). A process interaction matrix is defined by basic syntactic and semantic rules:

Individual business processes (internal processes as well as interacting external ones) are represented as boxes in the matrix’s diagonal (P1 to Pn) and are numbered from the top left to the lower right corner (the numbering sequence does not imply a sequence of execution or timing);

Any process may use certain inputs and creates outputs. Inputs of individual process are represented as boxes, situated in the same row where the process box is located (left and right form the process box); outputs of individual process are also represented as boxes, situated in the same column where the process box is located. The box at the intersection of P1’s column and the row of process P2 is an output of P1 used by P2 (output of process P1 as an input). Thus, the matrix represents the interaction of P1 and P2. Figure 3.4 shows the interaction of process P1 and P2 with process P3, where X1 represents the interaction between process P1 and P3 (the output of process P1 and input of process P3) while X2 represents the interaction between P2 and P3 (the output of process P2 and input of process P3). Figure 3.4 also represents the interaction between process P3 and some external process (that is part of the external environment). X3 is the object exchanged in this interaction (the output of process P3 is the input of an external process);

Process interactions (or more precisely, interacting objects) may be a) transformation objects (material or information), or b) control objects (information entities, like laws, policies, standards, etc.) guiding or constraining a process. As a convention, the names of

24

material objects are written in normal text style, information objects in bold and control objects in italic style;

If necessary, each process box (e.g. P1) may be represented in more detail in a separate matrix.

The process interaction matrix is similar in expressive power to the IDEF0 modelling language, with the exception that resource- (mechanism) inputs are not distinguished from ordinary- or control inputs, and arrow bundling/branching is not supported within one matrix (however, the decomposition of interface objects can be done on a detail-matrix). On the other hand the minor addition of a graphical notation to distinguish material, information and control objects has been found useful in practice. The advantage of this matrix variant of IDEF0 is its efficient use of space on a page, and the possibility to construct it using a simple text editor or spreadsheet program.

Note that the GRAI-Grid presented in the Section 3.1 is also a kind of process interaction matrix, because it defines the interactions between decisional centres or decisional process respectively (processes on the management- and control level).

3.3 Product realisation and support processes

The ISO9000:2000 standards require the identification of “the organisation’s product realisation processes, as these are directly related to the success of the organisation. Top management should also identify those support processes that affect either the effectiveness and efficiency of the realisation processes or the needs and expectations of interested parties” (ISO/TC 176, 2000).

Many organisations encounter difficulties in the attempt to identify, and differentiate between, product realisation and support processes. To define a line between these two groups of processes some strategic management concepts may be used.

Strategic management emphasises the importance of the identification, development, accumulation and maintenance of the organisation’s core capabilities and competencies in order to maintain a long-term source of organisational competitiveness and competitive advantage, and consequently, a successful market position of the organisation.

The ISO standard’s definition of product realisation processes could lead to a ‘narrow’ understanding and meaning. Product realisation processes are usually associated with the development, manufacturing, sales or distribution processes. However, the identification of a company’s core capabilities and competencies (and their associated processes) may reveal a larger set that includes both traditional product realisation processes and other processes of key importance. After all, a core product, or end-products are only the material manifestations of an organisation’s capabilities.

To understand the relationships between product realisation processes and an organisation’s core competencies, the definition of some basic notions, such as capabilities and competences, should be given first.

According to ISO 9000:2000, a capability is defined as the ability of an organisation, system or process to realise a product that will fulfil the requirements for that product. By generalising this definition, a capability can be defined as a firm’s ability to execute business processes and activities to produce and deliver a required product through the deployment of the firm’s resources. Therefore, a capability is a permanent or temporary aggregation of non-specific and/or specific assets needed to execute certain business processes (Kalpic et al, 2003).

Capabilities may be functional (e.g. the ability to develop new products) or cross functional (e.g. quality- or integrative capabilities, such as the ability to manage a network organisation). Capabilities that directly contribute and improve the value perceived by the

25

market/customers are called the core competencies of the organisation (Prahalad and Hamel, 1990).

A core competence is a company-specific capability (capability of strategic importance), which makes the company distinct from its competitors, and defines the essence of the company’s business.

Firm-specific (core) capabilities may also be considered through the perspective of the firm’s competitive advantage. Namely, governance over core capabilities should result in competitive advantage for the firm.

Companies could posses many competencies, some of them are core and some of them are non-core. Irrespective of the strategic importance of core competencies, organisations are often not clear about what is and what is not a core competence. It is essential to be able to make such a distinction, because any neglected core capability may result in the loss or weakening of the company’s competitive position. The first criterion is whether the activities that are part of the competence really contribute to long-term corporate prosperity. The second criterion of being a core-competence is that the competence must ‘pass’ the tests and meet the criteria below (Hamel and Prahalad, 1994):

customer value – a core competence must make a disproportionate contribution to customer-perceived value,

competitor differentiation – the capability must be competitively unique,

extendibility – a core competence is not merely the ability to produce the current product configuration (however excellent that product line may be), but it also must be able to be used as a basis of potential new products.

For example, according to these criteria, a very efficient home-developed accounting system, supported by a company-specific software, cannot be considered as a core-competence of a manufacturing company. Even though this is a specific asset of the organisation, it does not directly contribute to the value of products or services perceived by the customer, therefore these accounting capabilities cannot be considered as a core competence.

As a conclusion: the identification of an organisation’s core competencies and associated processes is equally important as the identification and definition of the (traditionally perceived) product realisation processes. Therefore, it is the core competencies and all associated (support) processes that need to be identified, defined and managed through their entire life-cycle. According to Hamel and Prahala (1994), core competencies are the soul of the company and as such, their management must be an integral part of the management process of company executives.

3.4 From Business Process Modelling to Enterprise Modelling

The ISO 9000 family of standards, in addition to business process modelling, requires the identification, definition and description of other enterprise entities as well. Standard requirements for the definition of authorities and responsibilities, required and possessed categories of individual capabilities, or process key-performance indicators is an extension that leads from business process modelling to enterprise modelling.

For a systematic categorisation of modelling-related standard requirements, the GERA entity model content views could be used. GERA defines four different model content views for the user oriented process representation (IFIP-IFAC, 2003):

Function View (presented in detail in the discussion of functional, behavioural and decisional types of process models).

Information View collects the knowledge about objects of the enterprise (material and information) as they are used and produced in the course of the enterprise’s operations. The

26

information to be modelled is identified from the relevant activities and is structured into an enterprise information model in the information view for information management and for the control of the material and information flow.

Resource View represents the resources (humans and technical agents as well as technological components) of the enterprise as they are used in the course of the enterprise’s operations. Resources are assigned to activities according to their capabilities and structured into resource models.

Organisation View represents the responsibilities and authorities of all entities identified in the other views (processes, information, resources). This view also represents the structure of the enterprise’s organisation by aggregating the identified organisational units into larger units such as departments, divisions, sections, etc.

3.4.1 Organisational view related standard requirements

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).

Typically, humans may assume different roles, as for example: chief executive, market & sales, technical (R&D), finance, production planning, logistics, information system designers, quality inspectors, etc.

Also alternative organisational structures may be deployed, for example elements of an organisation may be linked hierarchically or heterarchically and demonstrate properties of holons, webs, nets, temples or clusters. Further organisational structuring may occur on a functional, process or geographic basis.

Individuals and groups of individuals will be assigned a number of roles and responsibilities. These assignments need to be carried out concurrently and cohesively, where each may involve different reporting lines 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. The requirement to define and communicate responsibilities and authorities within the organisation is also included in the ISO 9000:2000 standards.

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. Figure 3.5 shows a simple example of the matrix of authorities; acronyms are used for shorthand (PR- proposal, R-Review, A-Approval, etc.).

The organisational view may be represented using traditional organisation charts (a tree) – at least to describe the organisational hierarchy. However, if the organisational chart is represented in a matrix (see Figure 3.5) it will assign management (decision) tasks to organisational units and thus may be considered a kind of (simplified) functional model of an enterprise.

27

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

Strategic contracts

Customer complaint

Unsettled debts

500.000 EUR

500.000 to 1,000.000

EUR

over 1,000.000

EURBOARD President

A A A

Member A A

Marketing Marketing VP

C C C PR

Purchasing coordin. PR

Economics Economics VP

R

Finances FEO

R R R R R

Legal affairs R R R R R

SBU President of SBU

A R R R E

Supply chain Mngr PR PR PR E PR

R&T Mngr

Production Mngr

Quality assurance AS

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

Figure 3.5: Authority matrix The organisational chart, as the most visible end-result of organisational design,

structures divisions into departments, departments into sections, and so on, and allocates manager for each of these.

3.4.2 Resource view related standard requirements

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) have to be known as well.

The ISO9000:2000 standard requires that personnel shall be competent on the basis of appropriate education, training, skills, experience, talents or backgrounds, and intellectual, psychological or physical capabilities. A competence is a demonstrated capability to apply knowledge or skills and accomplish the task and delivering appropriate results.

Therefore, the organisation must:

Determine the necessary competence levels for personnel performing work that directly or indirectly affects product quality. Note that this requirement is equally applicable to personnel involved in production & service delivery and management & control;

Allocate personnel to jobs matching the competencies of the individual with the capabilities required by the job; and

Provide training or take other action to satisfy these needs (foster the continuous development of employee competencies to the required level).

28

To identify, define, and actively manage the capabilities and competencies of personnel, the organisation can define main categories of capabilities and describe them by relevant attributes.

The standard also requires that the organisation should manage professional promotions for their employees. Therefore, organisations have to design professional development plans (career planning) for any individual and actively execute and manage those plans.

Career planning and execution of promotion plans could not be efficient if the enterprise has no processes to achieve this, e.g. through the division of tasks and jobs in a way that promotes gradual professional development.

Figure 3.6 shows an example of an R&D department’s professional development map describing the gradual progress of individuals based on their demonstrated capabilities.

An employee in the R&D department may starts his / her career at the assistant level to acquire basic skills and concepts of product development. Later on, the next typical transition would be to continue on to the position of constructor and developer. At that stage the basic professional training and development is complete and the professional career starts branching where the individual may continue to become a) a highly focused and competent professional (researcher / technical expert), b) manager (project manager) or c) marketing manager (product manager).

Figure 3.6: Professional development: attainment of human resource competencies (Abel, 2003)

An R&D department may also be considered as the main “recruiting” department, which is the source of professionals for different other departments, such as sales and marketing or different (senior) management positions (e.g. new plant manager).

In the definition of typical positions and professional migration steps (transitions), shown in Figure 3.6, one should aim at a balance between the scope of the given managerial- and professional role and the required managerial-, leadership- and professional capabilities / competencies.

Both the enterprise engineering process and the operational environment rely on a significant amount of technology. Technology, is either production oriented and therefore involved in producing the enterprise products and customer services, or management and

29

control oriented, providing the necessary means for communication and in-formation processing and information sharing.

Therefore, beside modelling human capabilities, at least two other fundamental types of functional entities (resources), have to be modelled: a) devices or machines (including IT, manufacturing or other types of technological devices) and b) applications (i.e. software packages).

Both types of functional entities could be defined in terms of their technical characteristics and constraints (e.g. data access time for database server, maximum feed rate of a machine, number of units processed per unit of time, etc.), types of functional operations offered, the level of machine autonomy, etc. A resource may be described using the following example set of characteristics (Vernadat, 1996):

identification

type

nature (consumable or non-consumable)

capacity

availability

roles

functionality

locations

shareabiltiy

mobility

reliability estimates

cost per unit, etc.

Resources may also be grouped into classes according to their nature. Generic classes can be defined listing essential resource characteristics. Subclasses of these are more detailed and inherit the characteristics from generic classes as well as add further specific ones.

Capability models would have to be developed for aggregate resources according to the intended / existing resource structure (e.g. shop floor models, system architectures, information models, infrastructure models), communication models (e.g. network models), etc.

Despite the importance of resource management, few modelling methods applicable to enterprise modelling offer resource constructs. Only the CIMOSA resource modelling view (CIMOSA Association, 1996) and Integrated Enterprise Modelling (Spurg et al, 1993) provide means to model in detail the structure of resources and their related characteristics.

3.4.3 Information view related standard requirements

In Section 2.1 a simple model of an artificial system was discussed. This model defines the following functions for the Management Information System (MIS):

connects the physical system and the management and control system (decision system)

exchanges information with the external environment

delivers feedback and

aggregates information suitable for decision support.

30

The requirement for the use of an MIS is also expressed in the ISO9000:2000 standard: “the organisation shall apply suitable methods for monitoring and, where applicable, measurement of the management system processes. These methods shall demonstrate the ability of the processes to achieve planned results”.

In the definition or design of key performance indicators (KPI), organisations are often too much focused on the development of a set of financial indicators, which show the growth of revenue, profit rate, market share, etc.

Traditional financial indicators reflect the result of the company’s previous activities and efforts – they may also be called ‘lagging’ indicators.

Non-financial indicators are useful to monitor the structural development of the company, the organisation’s potential and its corporate health – these indicators may be called ‘leading’ indicators. Therefore, in addition to financial indicators a set of non-financial indicators have to be developed and used.

The importance of the use of both types of performance indicators is also recognised by the ISO9000:2000 standards. The standards require that in addition to financial indicators the organisation should also measure process performance, and other success factors identified by management, such as the satisfaction of customers, of people in the organisation and of other interested parties. There are a number of methods and techniques to achieve this, e.g. benchmarking, process assessments, etc.

The definition and design of KPI could be supported by one of the contemporary methodologies developed for this purpose, such as the EFQM model or Balanced Scorecard (BSC) methodology.

Kaplan and Norton (1996) in their BSC methodology identify four categories of performance indicators (learning and growth, business processes, customer relationship and financial performance). The EFQM Excellence Model (1999) organises 32 sub-criteria into 9 major criterion groups. BSC also allows the creation of a tangible link between the organisation’s vision and its translation into strategic objectives, key success factors, key projects and performance indicators.

To provide management with control over these key performance indicators the support of an MIS is essential. A major part of the MIS is a software application that facilitates data collection (form a wide range of internal and external data sources), its presentation (a highly automated generation of KPI values from relevant databases) as well as the interpretation, and the distribution of relevant KPIs to individuals.

In the design of software applications for the MIS an adequate methodology should be used. Various Data Warehouse16 (DW) methodologies available today could be applied in the analysis, design and implementation of an information system that enables data to be transformed into meaningful business information and overcome today’s companies’ richness of data (availability of different applications and systems such ERP, other transaction-oriented systems, CRM, e-business, etc.) and poverty of information.

A DW methodology is composed of four major phases:

Organisational analysis, delivering information system requirements (business and technical), as well as the identification of business objectives and a technical feasibility analysis.

Design phase, composed of the following activities: conceptual design delivering a conceptual data model, logical design and physical database design from the data model, detailed specification of the process model for extraction, transformation, and loading,

16 The data warehouse is the central repository for data consolidation, cleansing, transformation and storage in a format best organised for reporting, extraction and data mining. Virtually all data warehouse best practice methodologies embrace variants of what is often referred to as a “hub and spoke” architecture. Data warehouses function as the hub, or staging area, for feeding application-specific data marts.

31

design of reports, and the design of additional aspects such as the security and metadata models. For modelling the information aspect, many different modelling languages could be used, such as: (extended) entity-relationship model, IDEF1X, EXPRESS, UML class diagram, SQL or CIMOSA information modelling language.

Construction phase, where implementation teams build the Database Management System, code and populate the warehouse with data, and develop the applications for end-user analysis and reporting.

Verification and validation of the system (e.g. data quality validation, user acceptance testing regression / system load testing, etc.).

3.5. The ISO9000:2000 and business process reference models

The ISO9000 standard requires that the organisation shall plan, develop and control the processes needed for product realisation.

Many product realisation processes are fairly standard, structured and repetitive in nature, and can be described by behavioural or activity process models (e.g. sales processes, order conformation, shipment processes, customer complaint resolving process, etc). These processes are usually well defined, described and formalised in so-called ‘quality procedures’ (QP) in the organisation’s QMS.

However, enterprises could incorporate in their repertoire of models other product realisation processes, even if they are unstructured or ill-structured (as for example, the product design and development process). QPs for these are usually not described, or if they are, not in sufficient detail to provide guidelines or procedures for their execution. For such processes QPs would typically exist only as high-level requirements for review, verification, validation, monitoring, inspection, and test activities and activities attached to determination of quality objectives.

Some of these processes (e.g. product design and development) are performed and managed in a fashion similar to project management. To improve quality, reliability and efficiency, as well as to provide support for project design (planning and scheduling), implementation and operation (execution and control), organisations should develop reference models for these processes.

Project reference models (including the processes performed in the project) do not necessarily have to standardise on a single particular process but rather they should propose a model, based on which each individual project may design its own, tailored process. The existence (and adoption) of such a reference model promotes commonality without forcing uniformity on a process that by its nature is expected to be different each time it is executed.

For example, a reference model for product design and development processes may determine:

the design and development stages, and the key activities in each stage,

the review, verification and validation processes that are appropriate to each design and development stage,

the responsibilities and authorities for design and development tasks,

inputs and the outputs of the design and development process. An activity model may be able to capture the commonality in every such process,

whereupon the actual procedure (sequences of activities) and the life-history (development in time) of every single development project is potentially unique.

Behavioural reference models can be developed for projects that have a repetitive nature, i.e., where product development is following a predominantly predictable path.

32

In the authors’ experience reusable process reference models benefit the company though:

supporting project planning, and scheduling of activities and resources, etc. – therefore development activities do not start from scratch;

improving the efficiency and quality of project planning and scheduling;

providing a repository of knowledge and experience for the project planning phase (through the formalisation and reuse of this knowledge);

providing the user/project manager with a checklist of important activities during the project’s development (bill of activities);

helping to create a common communication platform, and providing for the entire organisation a greater chance of understanding what is represented in the project plan.

4 Business Process Modelling in Business Process Reengineering

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).

Teng et al (1994) ague that the reason for an increased attention to business processes is largely due to the Total Quality Management (TQM). They conclude that TQM and BPR share a cross-functional orientation. However, Davenport (1993) observes that quality specialists tend to focus on incremental change and gradual improvement of processes, while proponents of reengineering seek radical redesign and drastic process improvement.

The popularity of BPR notwithstanding, there are many misconceptions about the essence of reengineering. Hammer and Champy (1993) note: what organisations often do under the banner of reengineering is simply a reorganisation project, a staff reduction exercise, or is an incremental efficiency programme. The essence of reengineering is not ‘reorganizing’ or ‘downsizing’. Reengineering looks at what work is required to be done, eliminating work that is not necessary, and finding better, more effective ways of doing what is needed; its focus is not on how the organization is structured. If a company embarks on a reeingineering programme, then organizational structures should be defined only after the production and service delivery processes have been (re)designed. In other words, the organizational structure is designed so it can best support these processes.

Therefore, reengineering is not simply about making an organization more efficient, but about creating value for the customer. Note that an indiscriminate customer focus can also be a danger of reengineering, because the purpose is not exclusively the service to the customer; equal value should be placed on the continued health and competitiveness of the organisation (so the company can continue serving customers in the future).

4.1 Ten-step approach to BPR

Many different BPR methodologies are proposed in the literature. The ten-step approach presented below integrates the guidelines of some major methodologies proposed by a range of authors (Vernadat, 1996; Davenport and Short, 1990; Malhotra, 1998).

33

1. Identify processes and set objectives for improvement. First, one has to identify those business processes tha are targeted for improvement. Priority for BPR is given to those processes that directly contribute to the organisation's mission and vision. Therefore, the strategic identity of the organisation should be profiled and a strategy must be defined. BPR must be driven by a business strategy, which implies specific business objectives relevant for the BPR process (such as Cost Reduction, Time Reduction, Output Quality improvement, etc.).

2. Get management commitment to re-design processes. Managers are accountable for results and are therefore empowered to act with much discretion with respect to business process reengineering. Leadership is critical to the success of any BPR effort.

3. Form a cross-functional team. Process redesign usually has significant impacts across organisational boundaries and generally has impacts or effects on external suppliers and customers. For this reason, the process reengineering team must be cross-functional, to include members from all impacted organisations or organisational units.

4. Modelling the AS-IS process. To develop an AS-IS process model the acquisition of basic information about the process in question has to be performed first. As the first source of information formal documents (e.g. documents of the company’s quality management system) could be used. (See Section 4.2 for common problems in gathering process information, as well as discusses cases where the preparation of an AS-IS model is not expected to add value to the BPR exercise).

5. Identify areas for improvement. Business processes need to be analysed to eliminate non-value added activities, simplify and streamline limited value added processes, and examine all processes to identify more effective and efficient alternatives to the process, data, and system baselines.

6. Design the ideal TO-BE process. Determination how much of the TO-BE process can actually be implemented starting from the AS-IS process, followed by the evaluation of alternatives (e.g. through a preliminary functional/economic analysis) and selection of a preferred course of action. In the design of the TO-BE process: a) awareness of ICT capabilities should influence the process design and b) review of the existing or design of the new process key performance indicators must be carried out. The new process design must clearly show how the company and its customers will benefit from its implementation – the mere fact that the new business process is correct (i.e., it will produce the expected deliverables) is not a sufficient argument for its adoption.

7. Verify the TO-BE process. TO-BE process should be vefied (showing that the model is based on the company's business requirements), tested for correctness (verify that he process would work if implemented, using business process simulation, ABC tool, acting-out sessions conducted by stakeholders, etc.), and improved (if needed). Note that this verification process is not the same as validation after process implementation (see step 9), because the execution of the process under real life circumstances may bring out further needs for correction or improvement.

8. Propose an implementation plan and get management commitment. The implementation plan, beside the definition of main process implementation activities (including timing and responsibilities), should define any required organisational changes, the definition of required resources and capabilities, etc. The implementation plan should recognise that the first implementation is likely to result needs for modification, therefore a tesing period should be planned for.

9. Install and validate the new process. Installation of the new process should be done according to the implementation plan and managed as a project. Ultimately, process validation is carried out by the process owner, based on the results of key performance indicators.

34

10. Monitor the new process for future changes as needed. The actual design should not be viewed as the end of the BPR process. Rather, it should be viewed as a prototype, with successive iterations performed in an ongoing process.

In spite of well documented BPR methodologies and management awareness and initial commitment, statistics shows that about 70% of BPR projects still fail. According to literature (Malhotra, 1998; Bashein et al, 1994) some of the biggest obstacles faced by BPR projects are:

lack of sustained management commitment and leadership,

unrealistic scope and expectations,

resistance to change,

"Do It to Me" attitude (lack of active involvement),

unsound financial conditions,

too many projects under way, etc.

4.2 How to develop an AS-IS process model

In the creation of the AS-IS process model (both for BPR and for documentation in a QMS), companies face some typical problems.

A QMS (quality manual and quality procedures) are 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

35

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.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).

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.

36

5 Business Process Modelling and Knowledge Management

As economies move into the information age and post-industrial era, information and knowledge become important, if not the most important, resources to organisations (Bell, 1973).

Knowledge is widely recognised as being the key asset of enterprises. Therefore, knowledge and its use are regarded as the primary source of competitive advantage of enterprises and base for an enterprise’s long-term growth, development and existence.

The awareness of the strategic importance of knowledge has also been reflected, recognised and investigated in the strategic management field. E.g., the resource-based view (RBV) of strategic management regards knowledge, privately held by the enterprise, as a basic source of competitive advantage. It is argued that a company’s competitive strength is derived form the uniqueness of its internally accumulated capabilities (Conner and Prahald, 1996; Schultze, 2002). The RBV approach therefore implies that not all knowledge is equally valuable. A (knowledge) resource that can freely be accessed or traded in the market has limited ability to serve as a source of competitive advantage (however this knowledge/resource could improve the organisation competitiveness).

Because of the evident importance of knowledge, it is not a surprise, that present times are described by phrases like ‘knowledge society’ or ‘knowledge economy’.

5.1 What is knowledge?

In the literature, several different definitions of knowledge can be found. Oxford English dictionary (1999) defines knowledge as the “facts, feelings, or experiences known by a person or group of people”.

According to Baker et al (1997), knowledge is present in ideas, judgements, talents, root causes, relationships, perspectives and concepts. Knowledge can be related to customers, products, processes, culture, skills, experiences and know-how.

Bender and Fish (2000) consider that knowledge originates in the head of an individual (the mental state of ideas, facts, concepts, data and techniques, as recorded in an individual's memory) and builds on information that is transformed and enriched by personal experience, beliefs and values with decision and action-relevant meaning. Knowledge formed by an individual could differ from knowledge possessed by another person receiving the same information.

Similar to the above definition Baker et al (1997) define knowledge in the form of a simple formula:

Knowledge = Information + [Skills + Experience + Personal Capability]

This simple equation must be interpreted to give knowledge a deeper meaning: knowledge is created from information as interpreted and remembered by a person with given skills, experience and personal capabilities, and is the ability to use this information to guide the actions of the person in a manner that is appropriate to the situation. It is noteworthy that this does not imply that the person is aware of this knowledge or that he/she can explain (externalise) it. These distinctions are important to consider when planning to discover what knowledge is available, or intending to establish knowledge transfer/sharing.

5.2 Need for Knowledge Management

Why is KM one of the hottest topics of the past decade, when the basic techniques of KM, which help people to capture and share their knowledge, experience and expertise, have been known and applied for a long-time?

The authors believe that the great interest in KM is conditioned by several drivers.

37

Fist, the birth of KM, which occurred in the early 1990s, grew from recognition of how difficult it is to deal with complexity in an environment of ever increasing competition spurred by technology and the demands of sophisticated customers (Bennet and Bennet, 2002).

Second, the idea of KM has created considerable interest because it gives a deeper explanation to managers’ interest in core competencies, their communication, and their transfer. It also creates awareness of knowledge as an important economic asset, and of the special problems of managing such assets (Spender, 2002).

Third, many companies have a world-wide distributed organisation, and the dissemination of company knowledge requires suitable techniques of knowledge management (such as knowledge acquisition and sharing). This situation is made even more difficult in organisations that operate in culturally diverse environments.

Fourth, the pace of adoption of the Internet technology, especially the establishment of Intranets, Extranets, Web portals, etc., has created a networking potential that drives all of society and corporations to work faster, create and manage more interdependencies, and operate on global markets (Bennet and Bennet, 2002).

Finally, as a fifth driver, in the 1990s companies became aware of the threat and risk of losing valuable key organisational knowledge, that is often present only in employees’ heads (knowledge which is not explicit, externalised or formalised and is consequently not available for use by other individuals). At the same time, the demand for quicker growth of knowledge (competence) of employees has become a new driver to manage organisational knowledge.

Consequently, KM is expected to provide (Holsapple and Joshi, 2002):

an organisational response on awareness of the importance of information and knowledge,

an answer to how organisational knowledge can be used more efficiently,

techniques to create, capture, formalise, organise, integrate, tailor, share, spread and reuse organisational knowledge, and

techniques to make available the right knowledge to the right people in the right representations and at the right time.

Beside the technical and methodological issues of the implementation of KM, the socio–cultural aspects of KM must also be carefully considered. According to Baker et al (1997) KM should continually improve the effectiveness of available knowledge by focusing on the key people, processes and technology. Companies should develop an organizational ethos, which applies the concept of knowledge management as the norm. According to Bender and Fish (2000), KM is not a programme but a new way of working that needs to be embedded into an organisation's culture through its overall strategy and design of operations.

Even though the concept of KM has emerged only recently, there is a number of initiatives that organisations have earlier adopted and that are useful components to implement KM. The result of the learning organization, business process re-engineering, business process modelling, quality management and business intelligence movements can be used as a foundation for a comprehensive adoption of KM and the building of knowledge-based companies.

5.3 The nature of knowledge and its sharing

KM literature defined two main knowledge categories: explicit and tacit.Polanyi (1966) defines tacit knowledge as knowledge, which is implied, but is not

actually documented, nevertheless the individual ‘knows’ it from experience, from other people, or from a combination of sources. Explicit knowledge is externally visible; it is documented tacit knowledge (Junnarkar and Brown, 1997).

38

Skryme and Amidon (1997) define explicit knowledge as formal, systematic and objective, and it is generally codified in words or numbers. Explicit knowledge can be acquired from a number of sources including company-internal data, business processes, records of policies and procedures as well as from external sources such as through intelligence gathering. Tacit knowledge is more intangible. It resides in an individual’s brain and forms the basis on which individuals make decisions and take action, but is not externalised in any form.

Polanyi (1958) also gives another detailed and substantial definition of knowledge categories. He sees tacit knowledge as a personal form of knowledge, which individuals can only obtain from direct experience in a given domain. Tacit knowledge is held in a non-verbal form, and therefore, the holder cannot provide a useful verbal explanation to another individual. Instead, tacit knowledge typically becomes embedded in, for example, routines and cultures. As opposed to this, explicit knowledge can be expressed in symbols and communicated to other individuals by use of these symbols.

Bejierse (1999) states that explicit knowledge is characterised by its ability to be expressed as a word or number, in the form of hard data, scientific formulas, manuals, computer files, documents, patents and standardised procedures or universal works of reference that can easily be transferred and spread. Implicit (tacit) knowledge, on the other hand, is mainly people-bound and difficult to formalise and therefore difficult to transfer or spread. It is mainly located in people's ‘hearts and heads’.

Considering the aforementioned definitions, the authors define explicit knowledge as knowledge, which can be articulated and written down. Therefore, such knowledge can be externalised and consequently shared and spread. Tacit knowledge is developed and derives from the practical environment; it is highly pragmatic and specific to situations in which it has been developed. Tacit knowledge is subconscious, it is understood and used but it is not identified in a reflective, or aware, way. Although tacit knowledge is not directly externalisable, it is sometimes possible to create externalisations17 that may be used by someone else to acquire the same tacit knowledge. Tacit knowledge could be made up of insights, judgement, know-how, mental models, intuition and beliefs, and may be shared through direct conversation, telling of stories and sharing common experiences.

The above definitions give rise to a categorisation that can be used to make practically important differentiations between various forms of knowledge. The authors propose to divide knowledge into sub-categories according to the following criteria (see Figure 5.1):

17 I.e., these externalisations do not contain a record of the knowledge itself, rather they would contain information that another person could (under certain circumstances) use to construct the same knowedge out of his/her already possessed internal knowledge.

39

Figure 5.1.: Knowledge categories

Is the knowledge internalised in a person’s head or has it been externalised (internal/externalised)? In other words, have there been any external records made (in form of written text, drawings, models, presentations, demonstrations, etc.)?

Is there awareness of this knowledge (explicit/tacit)? Awareness means here that the person identifies this knowledge as something he/she is in the possession of and which could potentially be shared with others. In other words, the person not only can use the knowledge to act adequately in situations, but also conceptualises this knowledge (this awareness may be expressed by statements as “I can tell you what to do”, “I can explain how to do it”). The lack of awareness manifests is statements like “I can not tell you how to do it, but I can show”.

Does the externalisation have a formalised representation or not (formal/not formal)? Formalisation here means that the external representation of the knowledge is in a consistent and complete mathematical/logical form (or equivalent).

Note that each domain of knowledge may contain a mixture of tacit and explicit constituents.

5.4 The knowledge process and knowledge resources

A comprehensive survey of the KM literature shows the various knowledge management frameworks and KM activities. Some of frameworks are composed of very low-level activities and in some frameworks seems that elementary activities group into higher-level activities.

Nonaka and Takeuchi (1995) defines four processes:

Internalisation is the process in which an individual internalises explicit knowledge to create tacit knowledge. In Fig.5.1 this corresponds to turning aware knowledge into tacit knowledge – Nonaka does not differentiate between formal and informal awareness.

Externalisation is the process in which the person turns their tacit knowledge into explicit knowledge through documentation, verbalisation, etc. In Fig 5.1 this process corresponds to turning tacit knowledge into aware knowledge and subsequently communicating it (internal externalised).

Combination is the process where new explicit knowledge is created through the combination of other explicit knowledge. In Fig 5.1 this process is internal to explicit knowledge, and does not differentiate cases, such as formalising knowledge, i.e. the transition informal awareness formal awareness.

Socialisation is the process of transferring tacit knowledge between individuals through observations and working with a mentor or a more skilled / knowledgeable individual. In Figure 5.1 this corresponds to tacit knowledge observable actions, etc.

Devenport and Prusak (1998) identify four knowledge process: knowledge generation (creation and knowledge acquisition), knowledge codification (storing), knowledge transfer (sharing), and knowledge application (these processes can be represented as various transitions between knowledge categories in Figure 5.1).

Alavi and Marwick (1997) define six KM activities: a) acquisition, b) indexing, c) filtering, d) classification, cataloguing, and integrating, e) distributing, and f) application or knowledge usage, while Holsapple and Whinston (1987) indentfy more comprehensive KM process, composed of the following activities: a) procure, b) organise, c) store, d) maintain, e) analyse, f) create, g) present, h) distribute and i) apply.

Holsapple and Joshi (2002) present four major categories of knowledge manipulation activities:

40

acquiring activity, which identifies knowledge in the external environment (form external sources) and transforms it into a representation that can be internalised and used (the two steps of internalisation, external aware internal and aware internal tacit are not differentiated);

selecting activity identifying needed knowledge within an organisation’s existing resources; this activity is analogous to acquisition, except that it manipulates resources already available in the organisation;

internalising involves incorporating or making the knowledge part of the organisation

using, which represents an umbrella phrase for a) generation of new knowledge by processing of existing knowledge and b) externalising knowledge that makes knowledge available to the outside of the organisation.

The above processes are applicable to the organisation as an entity, rather then addressing knowledge processes from the point of view of an individual.

As a conclusion: organisations should be aware of the complete process of knowledge flow, looking at the flow between the organisation and the external world and the flow among individuals within (and outside) the organisation. This latter is an important case, because in many professional organisations individuals belong to various communities, and their links to these communities is equally important to them as the link to their own organisation.

5.4.1 Knowledge resources

Knowledge manipulation activities operate on knowledge resources (KR) to create value for an organisation. On the one hand, value generation depends on the availability and quality of knowledge resource, as well productive use of KR depends on the application of knowledge manipulation skills to execute knowledge manipulation activities.

Holsapple and Joshi (2002) developed a taxonomy of KR, categorising them into schematic and content resources. The taxonomy identifies four schematic resources and two content resources appearing in the form of participant’s knowledge and artefacts. Both schema and content are essential parts of an organisation’s knowledge resources.

Content knowledge is embodied in usable representations. The primary distinction between participant’s knowledge and artefacts lies in the presence or absence of knowledge processing abilities. Participants have knowledge manipulation skills that allow them to process their own repositories of knowledge; artefacts have no such skills. An organisation’s participant knowledge is affected by the arrival and departure of participants and by participant learning. As opposed to this, a knowledge artefact does not depend on a participant for its existence. Representing knowledge as an artefact involves embodiment of that knowledge in an object, thus positively affecting its ability to be transferred, shared, and preserved (in Figure 5.1 knowledge resources correspond to recorded externalised knowledge).

Schema knowledge is represented or conveyed in the working of an organisation. It manifests in the organisation’s behaviours. Perceptions of schematic knowledge can be captured and embedded in artefacts or in participant’s memories, but it exists independent of any participant or artefact. Schematic knowledge resources are interrelated and none can be identified in terms of others. Four schematic knowledge resources could be identified: a) culture (as the basic assumptions and beliefs that are shared by members of an organisation), b) infrastructure (the knowledge about the roles that have been defined for participants), c) purpose (defining an organisation’s reason for existence), and d) strategy (defining what to do in order to achieve organisational purpose in an effective manner).

In addition to its own knowledge resources, an organisation can draw on its environment that holds potential sources of knowledge. Through contacts with its environment,

41

an organisation can replenish its knowledge resources. The environmental sources do not actually belong to an organisation nor are they controlled by the organisation. When knowledge is acquired form an environment source, it becomes an organisational source.

5.5 Business Process Modelling and Knowledge Management

Many knowledge management systems (KMSs) are primarily focused on solutions for the capture, organisation and distribution of knowledge.

Rouggles (1998), for example, found that the four most common KM projects conducted by organisations were creating/implementing an intranet, knowledge repositories, decision support tools, or groupware to support collaboration.

Spender (2002) states that the bulk of KM literature is about computer systems and applications of ‘enterprise-wide data collection and collaboration management’, which enhance communication volume, timeliness, and precision.

Indeed, current KM approaches focus too much on techniques and tools that make the captured information available and relatively little attention is paid to those tools and techniques that ensure that the captured information is of high quality or that it can be interpreted in the intended way.

Teece (2002) points out a simple but powerful relationship between the codification of knowledge and the costs of its transfer. Simply stated: the more a given item of knowledge or experience has been codified (formalised in the terminology of Figure 5.1), the more economically it can be transferred.

Uncodified knowledge is slow and costly to transmit. Ambiguities abound and can be overcome only when communication takes place in face-to-face situations. Errors of interpretation can be corrected by a prompt use of personal feedback.

The transmission of codified knowledge, on the other hand, does not necessarily require face-to-face contact and can often be carried out by mainly impersonal means. Messages are better structured and less ambiguous if they can be transferred in codified form.

Based on the presented features of business process modelling (and in the broader sense enterprise modelling) and the issues in knowledge capturing and shearing, BPM is not only important for process engineering but also as an approach that allows the transformation of informal knowledge into formal knowledge, and that facilitates externalisation, sharing and subsequent knowledge internalisation. BPM has the potential to improve the availability and quality of captured knowledge (due to its formal nature), increase reusability, and consequently reduce the costs of knowledge transfer. The role and contribution of BPM in knowledge management will be discussed in more detail in Section 5.6.1.

5.5.1. BPM and KM are related issues

While the methods for developing enterprise models have become established during the 1990s (both for business process analysis and design) these methods have concentrated on how such models can support analysis and design teams, and the question of how these models can be used for effective and efficient sharing of information among other stakeholders (such as line managers and engineering practitioners) has been given less attention.

If enterprise models, such as business process models, embody process knowledge then it must be better understood to what extent and how existing process knowledge can be externalised as formal models, and under what conditions these models may be effectively communicated among stakeholders. Such analysis may reveal why the same model that is perfectly suitable for a business process analyst or designer may not be appropriate for end users in management and engineering. Thus the authors developed a theoretical framework which can

42

give an account of how enterprise models capture and allow the sharing of the knowledge of processes – whether they are possessed by individuals or groups of individuals in the company. The framework also helps avoid the raising of false expectations regarding the effects of business modelling efforts.

5.6 The knowledge life-cycle model

Figure 5.2 introduces a simple model of knowledge life-cycle, extending (detailing) the models proposed by Nonaka and Takeuchi (1995), and Zack and Serino (1998). Our extension is based on Bernus et al (1996), which treat enterprise models as objects for semantic interpretation by participants in a conversation, and establishes the criteria for uniform (common) understanding. Understanding is of course most important in knowledge sharing. After all if a model of company knowledge that can only be interpreted correctly by the person who produced it, is of limited use for anyone else. Moreover, misinterpretation may not always be apparent, thus through the lack of shared interpretation of enterprise models (and lack of guarantees to this effect) may cause damage. This model (Figure 5.2) represents relations between different types of knowledge, and will be used as a theoretical framework.

In order for employees to be able to execute production, service or decisional processes they must possess some ‘working knowledge’ (e.g. about process functionality, required process inputs and delivered outputs, organisation, management, etc.). Working knowledge is constantly developed and updated through receiving information from the internal environment (based on the knowledge creation process) and from the external environment (thought the process of knowledge acquisition).

Working knowledge (from the perspective of the knowledge holder) is usually tacit. Knowledge holders don’t need to use the possessed knowledge in its explicit, formalised form to support their actions. They simply understand and know what they are doing and how they have to carry out their tasks – having to re-sort to the use of explicit formal knowledge would usually slow down the action.

According to the suitability for formalisation such working knowledge can be divided into two broad groups: formalisable and not-formalisable knowledge. (Note this is not the same as the formalised/not-formalised distinction, because there may be tacit knowledge that is held in an unaware way, but with suitable enquiry into that knowledge ways to make it aware and make it explicit – either in a formal or not formal way – may be found.)

Such division of knowledge (into formalisable and not formalisable) into two broad categories seems to closely correspond to how much the process can be structured, i.e. to be decomposed into a set of interrelated lower level constituent processes. These characteristics can be observed when considering knowledge about different typical business process types.

The formalisation and structural description of innovative and creative processes, such as some management, engineering and design processes (or in general the group of ad-hoc processes), is a difficult task, due to the fact that the set of constituent processes is not predefined, nor is the exact nature of their combination well understood by those who have the knowledge. Consequently, knowledge about this type of processes could be considered tacit knowledge (because they are not formalisable unaware processes), i.e. not suitable for formalisation/structuring.

In contrast to the characteristics of the group of ad-hoc processes the group of ill-structured and structured (repetitive or algorithmic) processes can be formalised and structured at least to a degree; consequently the knowledge about these processes is may become explicit formal knowledge. Examples of such processes are management, engineering and design on the level of co-ordination between activities as performed by separately acting-individuals or groups, and repetitive business and manufacturing activities.

43

Figure 5.2: The knowledge life-cycle model

The formalisable part of knowledge (knowledge about structured and ill-structured processes) is extremely important and valuable for knowledge management, because this may be distributed and thus shared with relative ease. Namely, the process of transformation of the formalisable part of tacit knowledge into formal knowledge (the formal part of explicit knowledge) represents one of the crucial processes in knowledge management. The authors believe that the cost of knowledge management (measured by the level of reuse and return of investment to the enterprise) in case of formal explicit knowledge would be lower than in case of tacit (unaware/implicit) – or even in case of unstructured explicit – knowledge, simply because the sharing of the latter is a slow and involved process.

To be able to perform the aforementioned formalisation process we need additional competencies known as culturally shared or situation knowledge (e.g. knowledge shared by the community that is expected to uniformly interpret the formal models of the target processes). Culturally shared knowledge plays an essential role in the understanding of the process or entity in question and in its formalisation and structuring. E.g. the definition of an accounting process can only be done by an individual who understands accounting itself, but this formalisation will be interpreted by other individuals who must have an assumed prior culturally shared and situational knowledge that is not part of the formal representation (Bernus et al, 1996).

As we already mentioned, one of key objectives of KM is the externalisation of participant’s knowledge. Regarding the type of knowledge (tacit and explicit) different tools and approaches in knowledge capturing may be used:

Tacit knowledge (whether formalisable or not) can be transferred through live in situ demonstrations, face-to-face storytelling, or captured informal presentations (e.g. multimedia records, personal accounts of experience, or demonstrations). Note that tacit formalisable knowledge may be discovered through research process and thus made explicit. Subsequently such knowledge may be captured as described in the bullet point below.

Explicit knowledge can be captured and presented in external presentations (through the process of knowledge capturing also known as knowledge codification). An external presentation may be formal or not formal. A textual description, like in quality procedure documents (ISO9000) is not formal, while different enterprise models (e.g. functional business process models) are examples of formal external representations of knowledge (knowledge externalisations).

44

Formal and informal external representations are called knowledge artefacts. The advantage of using formal models for process description is the quality of the captured knowledge.

To actually formalise knowledge, formalisation skills are needed (in this case business process modelling skills).

The above process of knowledge externalisation has to be complemented by a matching process of knowledge internalisation that is necessary for the use of available knowledge resources.

According to the type and form of externalised knowledge, various internalisation processes (and corresponding skills) are necessary. In general, the less formal the presentation / representation, the more prior assumed situation-specific knowledge is necessary for correct interpretation. Conversely, more formal representations allow correct interpretation through the use of more generic knowledge and require less situation-specific knowledge. Thus formalisation helps enlarge the community that can share the given knowledge resource.

An informal external presentation of knowledge accompanied with its interpretation (e.g. interpretation of the presented story) can directly build working (tacit) knowledge, however the use of these presentations is only possible in limited situations, and it is difficult to verify that correct interpretation took place as well as the completeness of knowledge transfer. However, the verification of correct interpretation and completeness is only possible through direct investigation of the understanding of the individuals who internalised this type of knowledge. This is a serious limitation for knowledge sharing through informal means.

A formal external presentation, such as a business process model developed in the IDEF0 (ICAM DEFinition) modelling language (Menzel and Mayer, 1998), must be first interpreted to be of use. To interpret the content of information captured in this model, formal model interpretation skills are needed. These skills are generic and not situation dependent, therefore even culturally distant groups of people can share them. Still, such formal representation must be further interpreted by reference to culturally shared, prior assumed knowledge so that the content of the formal knowledge (information captured in the business process model) can be understood and interpreted in the intended way, and thus integrated into working knowledge (to improve competencies). However, to test for correct interpretability it is possible to test whether the primitive concepts in the model (i.e. those not further explained / decomposed) are commonly understood. If this is the case then the formal nature of the model guarantees uniform interpretability. Completeness can be tested without the direct investigation of the understandings of those individuals who internalise this formal knowledge (i.e. the developer of the formal model can test himself or herself, whether the model is complete – provided the primitive concepts used are uniformly understood 18).

The reuse of formal externalised knowledge could have an impact on the execution of process in terms of their efficiency, according to the well known fact that formally learnt processes must undergo an internalisation process after which they are not used in a step-by-step manner. Therefore, the transfer of the acquired formal knowledge into tacit knowledge is a ‘natural’ learning process and is necessary for efficiency. The internalisation of externalised formal knowledge thereby closes the loop of the knowledge life-cycle.

Beside the importance of the formalisation / structuring process of knowledge, easy accessibility and distribution of business process models is one of the key factors for a successful deployment of EM practice in organisations. Organisations can use an information infrastructure and variety of technologies (usually already available and present in organisations) such as an Intranet, web tools, etc. to support storage, indexing, classification, transfer and sharing activities. 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.18 This test is commonly ignored by developers of formal models, probably because they assume that primitive concepts are all known through the users' formal education.

45

6. Conclusion

This article reviewed business process modelling with an emphasis on industrial practice. There are several approaches to BPM, which causes fragmentation of effort and parallell developments in the area. Enterprise Integration/Enterprise Architecture schools place an emphasis on modelling business processes on the concept and requirements levels, irrespective of the level of automation that might be intended. Workflow modelling schools concentrate on process modelling from the point of view of the possibility to automate business processes. Unfortunately these schools propose different modelling languages to be used and thus the top-down and bottom-up approaches do not meet in a staightforward manner.

However, many of the obstacles are artificial. 1) Requirements level activity models (such as may be expressed in IDEF0) capture the business process in such a way which allows several possible behavioural implementations, and if a behavioural model needs to be developed (e.g., in view of possible automation – also called model based control, or workflow execution) the activity models define the requirements for such models and can be used as an input for behavioural/workflow modelling; 2) Various versions of behavioural models are fairly similar in their expressive power, therefore the choice between these is dictated by the intended tools of implementation. Unfortunately very few of these languages allow resource modelling, which limits their usefulness, because a crucial question that management wants answered is: what are the resource requirements of processes and how do these compare with the capabilities of existing resources?

An important aspect of business process modelling, which is not in widespread use yet, but in the authors’ view crucial, is the modelling of the management and control system (the decision system) of the enterprise. Decisional models can be used to define the way the enterprise’s activities are co-ordinated, on every management horizon - strategic, tactical, operational and real-time. This co-ordination includes inter-enterprise as well as intra enterprise management tasks. Thus, the traditional area of business process modelling is extended to unstructured and ill-structured processes.

A combination of activity models and behavioural models can cover all enterprise processes, and satisfy the ISO9001:2000 requirements for business process management, including all core processes of the enterprise. It was also pointed out that process modelling and the modelling of the information, resource and organisation views of the enterprise are intricately interconnected, and business process modelling practice should address all four view of the GERA modelling framework.

Furthermore, the explicit definition of the enterprise’s decision system also defines user requirements for the Management Information System (which might either be implemented using contemporary Decision support tools and Data Warehousing technology, or using more traditional techniques).

The article pointed out that the scope of using reference models in BPM is not limited to behavioural models, but useful activity models can be used even is cases where the actual implementation of these reference models may be different in each case, such as in new product development projects.

Finally, the role of business process modelling was discussed in business process reengineering and knowledge management.

46

References:Abel, D.F. (2003) Changing Leadership Responsibilities and the Development of Tomorrow’s Leaders.

IEDC BledAlavi, M., Marwick, P. (1997) One Giant Brain. Boston (MA) : Harvard Business School. Case 9-397-

108AMICE (1993) CIMOSA: Open System Architecture for CIM. 2nd extended and revised version.

Springer–VerlagBaker M., Baker, M., Thorne, J., Dutnell, M. (1997) Leveraging Human Capital. Journal of Knowledge

Management. MCB University Press. 01:1 pp63-74Bashein, B.J., Markus, L., Riley, P. (1994) Business Process Reengineering: Preconditions for Success

and how to prevent Failures. Information Systems Management. 11(2) pp7-13Beijerese, R.P. (1999) Questions in knowledge management: defining and conceptualising a

phenomenon. Journal of Knowledge Management. MCB University Press. 03:2 pp94-110Bell, D. (1973) Coming of Post-Industrial Society: A Venture in Social Forecasting. New YorkBennet, D., Bennet, A. (2002) The Rise of the Knowledge Organisations. in Holsapple, C.W. (Eds.)

Handbook on Knowledge Management 1. Berlin : Springer-Verlag. pp5-20Bender, S., Fish, A. (2000) The transfer of knowledge and the retention of expertise: the continuing need

for global assignments. Journal of Knowledge Management. MCB University Pres. 04:2 pp125-137Bernus P., Nemes, L., Moriss, B. (1996) The Meaning of an Enterprise Model. in Bernus, P., Nemes, L.

(Eds.) Modelling and Methodologies for Enterprise Integration. London : Chapman and Hall. pp183-200

Bernus P., Nemes, L. (1999) Organisational Design: Dynamically Creating and Sustaining Integrated Virtual Enterprises. in: Proceedings of IFAC World Congress. London : Elsevier. Vol-A pp189-194

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

CIMOSA Association (1996) CIMOSA Technical Baseline. Germany : CIMOSA AssociationConner, K., Prahalad, C.K. (1996) A resource-based theory of the firm: Knowledge versus opportunism.

Organization Science. Vol. 7 pp477-501Davenport, T.H. (1993) Process innovation: reengineering work through information technology. Boston

(MA) : Harward Business School PressDavenport, T.H, Short, J.E. (1990) The New Industrial Engineering: Information Technology and

Business Process Redesign. Sloan Management Review. pp11-27 Davenport, T. H., Prusak, L. (1998) Working Knowledge: How Organizations Manage What They Know.

Boston (MA) : Harvard Business School Press. pp16 Doumeingts, G., Vallespir, B., Chen, D. (1998) Decisional Modelling GRAI Grid. in Bernus, P., Mertins,

K. and Schmidt, G. (Eds.) Handbook on Architectures of Information Systems. Berlin : Springer-Verlag. pp615-618

EFQM (1999) The EFQM Excellence Model. Brussels: European Foundation for Quality Managementvan Eijk, P.H.J., Vissers, C.A., Diaz, M. (Eds.) (1989) The formal description technique LOTOS.

Amsterdam : Elsevier Science Publishers B.V.Gruniger, M. (1997) Integrated ontologies for enterprise modelling. in: Proceedings of ICEIMT’97.

Torino (Italy) Hamel, G., Prahalad, C.K. (1994) Competing for the future. Boston (MA) : Harvard Business School

PressHammer, M., Champy, J. (1993) Reengineering the Corporation. New York : Harper–Collins Publishers Hysom, R. (2003) Enterprise Modelling – The readiness of the Organisation. in Bernus, P., Nemes, L. and

Schmidt, G. (Eds.) Handbook on Enterprise Architecture. Berlin : Springer-Verlag. pp373-416.Holsapple, C.W., Joshi, K.D. (2002) A Knowledge Management Ontology. in Holsapple, C.W. (Eds.)

Handbook on Knowledge Management 1, Berlin : Springer-Verlag. pp89-128

47

Holsapple, C.W., Whinston., A.B. (1987) "Knowledge-based Organizations." Information Society. (2) pp77-89

ISO JTC 1/SC 7 (1989) ISO8807 Information processing systems - Open Systems Interconnection - LOTOS - A formal description technique based on the temporal ordering of observational behaviour

ISO/TC 176/SC2 (2000) ISO9004:2000 Quality management systems – guidelines for performance improvements

ISO JTC 1/SC 7 (2002) ISO/IEC 15288:2002 Systems engineering - System life cycle processesJunnarkar, B., Brown, C.V. (1997) Re-assessing the Enabling Role of Information Technology in KM.

Journal of Knowledge Management. MCB University Press. 01:2 pp142-148 IFIP–IFAC Task Force on Architectures for Enterprise Integration (2003) GERAM: Generalised

Enterprise Reference Architecture and Methodology. http://www.cit.gu.edu.au/~bernus/taskforce/geram/versions/geram1-6-3/v1.6.3.html

Kalpic, B., Bernus, P. (2002) Business Process Modelling in Industry – the Powerful Tool in Enterprise Management. Computers in Industry. Elsevier. 47(3) pp299-318Kalpic, B., Pandza, K., Bernus, P. (2003) Strategy as a Creation of Corporate Future. in Bernus, P.,

Nemes, L. and Schmidt, G. (Eds.) Handbook on Enterprise Architecture. Berlin : Springer-Verlag. pp213-254

Kaplan, R., Norton, D. P. (1996) The balanced scorecard: translating strategy into action. Boston : Harvard Business School Press

Knowledge Based Systems, Inc. (2001a) IDEF Methods: IDEF0 Overview–Function Modelling Method. http://www.idef.com/idef0.html

Knowledge Based Systems, Inc. (2001b) IDEF Methods: IDEF3 Process Flow and Object State Description Capture Method Overview, http://www.idef.com/idef3.html

Kosanke, K. (1992), CIMOSA – A European Development for Enterprise Integration. Part 1: An overview: In Enterprise Integration Modelling. Cambridge (MA) : The MIT Press. pp179–188

Malhotra, Y. (1998) Business Process Redesign: An Overview. IEEE Engineering Management Review. 26 (3) pp27-31

Menzel, C., Mayer, R.J. (1998) The IDEF family of Languages, in: Bernus, P., Nemes, L. and Williams, T.J. (Eds.) Architectures for Enterprise Integration. London : Chapman & Hall. pp102-126

Mertins, K., Bernus, P. (1998) Reference Models. in: Bernus, P., Mertins and K. Schmidt, G. (Eds.) Handbook on Architectures of Information Systems. Berlin : Springer–Verlag. pp615-618

Nonaka, I., Takeuchi, H. (1995) The Knowledge – Creating Company: How Japanese Companies Create the Dynamics of Innovation. New York : Oxford University Press

Noran, O. (2003) A Mapping of Individual Architecture Frameworks (GRAI, PERA, C4ISR, CIMOSA, ZACHMAN, ARIS) onto GERAM, in Bernus, P., Nemes, L. and Schmidt, G. (Eds.) Handbook on Enterprise Architecture. Berlin : Springer-Verlag. pp65-212

Oxford University Press (1999) The Oxford English dictionary. Version 2.0PIF Working Group (2003) The Process Interchange Format (PIF) Project. http://ccs.mit.edu/pif/Polanyi, M. (1958) Personal Knowledge. University of Chicago PressPolanyi, M. (1966) Tacit Dimension. New York : DoubledayPrahalad, C.K, Hamel, G. (1990) The core competence of the corporation. Boston (MA) : Harvard

Business Review. 68(3) pp79-91Rouggles, R. (1998) The State of the Notion: Knowledge Management in Practice. California

Management Review. 40(3) pp80-89Schultze, U. (2002) On Knowledge Work. in: Holsapple, C.W. (Eds.) Handbook on Knowledge

Management 1, Berlin : Springer-Verlag. pp43-58Schmidt, G. (1998) GPN - Generalised Process Networks, in: Bernus, P., Mertins, K. and Schmidt, G.

(Eds.) Handbook on Architectures of Information Systems, Berlin : Springer – Verlag. pp191-208Skyrme, D., Amidon, D. (1997) The Knowledge Agenda. Journal of Knowledge Management, MCB

University Press. 01:1 pp27-37

48

Spender, J.C. (2002) Knowledge Fields: Some Post-9/11 Thoughts about the Knowledge-Based Theory of the Firm. in: Holsapple, C.W. (Eds.) Handbook on Knowledge Management 1. Berlin: Springer-Verlag. pp59-72

Spur, G., Mertins, K., Jochem, R. (1993) Integrierte Unternehmensmodellierung. Berlin: Beuth VerlagTeece, D.J. (2002) Knowledge and Competence as Strategic Assets. in: Holsapple, C.W. (Eds.)

Handbook on Knowledge Management 1. Berlin : Springer-Verlag. pp129–152Teng, T.C., Grover, V., Fiedler, K.D. (1994) Business Process Reengineering: Charting a Strategic Path

for the Information Age. California Management Review. pp 9-31Uppington, 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) pp430-447

Vernadat, F. (1996) Enterprise Modelling and Integration – Principles and Applications. Chapman & HallVernadat, F. (1998) The CIMOSA Languages. in: Bernus, P., Mertins, K. and Schmidt G. (Eds.)

Handbook on Architectures of Information Systems. Berlin : Springer – Verlag. pp243-164Warnecke, H.J. (1993) The Fractal Company. Berlin: Springer-VerlagWestkamper, E. (1997) Integrated Production with Virtual Elements. in: Proceedings of 29th CIRP

International Seminar on Manufacturing Systems. Osaka (Japan). pp50-56Williams, T.J. (1994) The Purdue Enterprise Reference Architecture. Computers in Industry. Elsevier.

24(2-3) pp141–158Zack, M.H., Serino, M. (1998) Knowledge Management and Collaboration Technologies.

http://www.lotus.com/solutio

49