Business Process Modelling in Industry the Powerful Tool in Enterprise Management

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 [5] (see Figure 1). The model consists of three main components:

 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) [1]. 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.

The same division of an artificial system into Service and Management & Control parts is present in Enterprise Reference Architectures such as PERA [23] and GERA [10].

Simplified PERA diagram

Communication with the external Life-cycle dimension environment (external information)

Management Management and Information Control System System Orders Physical system information (internal information) Goods Energy Physical system Raw material Service (manufacturing/service) Information/ By-products Data

Figure 1Cybernetic model of an artificial system (Doumeingts et al, XXXX) 2

2.2. Business Processes and Business Process Modelling

2.2.1. Business process The Oxford English Dictionary 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 [OED reference]. 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, ISO9000:2000) a ‘business processes’ 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 (1993) 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 model

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

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

b) All consequences of these facts agree with relevant properties of the modelled entity.

c) No consequences of the captured facts are in contradiction with relevant properties of the modelled entity.

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

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

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

Real world

ETI worker Elektroelement computer John Semantic algap

ETI employed in work with computer Elektroelement Model worker John Figure 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 language 3). There is always a difference between the real world and model. Only a 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). 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.1 Business Process Models as specific types of Enterprise Models

Enterprise 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

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

Enterprise Model is model of ‘enterprise objects4’ and their dependencies (Fox, Ontologies for EM). 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. There are various enterprise models [19] 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 (BPMs), are a specialised category of enterprise models, and focus on the description of business process features and characteristics. For example, BPMs 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:

 reduction (or better understanding) of process complexity (Vernadat, XXX),

 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 its improve 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

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 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 (subprocesses and activities) b) required inputs and delivered outputs for each subprocess / 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.4.1). 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 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: 6

 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 my 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 types Manufacturing 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 [21]. 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 [11]. 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 7 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 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 3 represents the components of the GERAM framework [10]. 8

GERA Generalised Enterprise EEMs Reference Architecture Enterprise Engineering Methodologies GEMCs EMLs EMs Generic Enterprise Enterprise Modelling Enterprise Models Modelling Concepts Languages EETs EOSs

Enterprise Enterprise Operational Engineering Tools System PEMs EMOs

Partial Enterprise Enterprise Modules Models

Figure 3: GERAM framework

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

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

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.

Generic Subdivision Views Partial according } to genericity { { { Particular

Instantiation

Identification Customer service Subdivision according to purpose Concept Management } of activity and control Requirements Software Subdivision Hardware} according to physical Preliminary design manifestation Design Resource Detailed design Organisation Subdivision Information according to Implementation } model content Function Operation

Decommission Subdivision according Machine } to means of Life-cycle Human implementation phases Reference Architecture Particular Architecture

Figure 4: Modelling framework of GERA

GERA identifies three dimensions for the definition of the scope and content of enterprise modelling (see Figure 4):

 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 10

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 atemporal and is subdivided into phases, while the life history is temporal, and is subdivided into stages.

 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:

 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 an ontology consists of:

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

6 Further discussion of these is beyond the scope of this chapter. 11

The informal specification of a language’s semantics usually includes the formal presentation of a 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. 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 – Ross, 1977), IDEF0, IDEF3, ARIS-Event Driven Process Chain, 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. 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). [26] 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 tools7( Tool (Language – Vendor)): AI0 WIN (IDEF0 – KBSI), ProSim (IDEF3 – KBSI), AIWIN/BPWin (IDEF0, IDEF1X, IDEF3 – Computer

7 It is not the intention of this chapter to present a complete list, only examples are given. 12

Associates), CORE (IDEF0, EFFBD8 – 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 a) 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. (The Process Interchange Format (PIF) Project, http://ccs.mit.edu/pif/) 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 minimized.

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 [16]. 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 ,The meaning of EM), and building block models (a set of elementary model fragments that can be freely combined as components to form a complete model) [2]. 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) [19].

8 Extended functional flow block diagrams (proposed for next UML extension) 13

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:19899 and (P. H. J. van Eijk, C. A. Vissers, M. Diaz (editors) (1989) The formal description technique LOTOS, Amsterdam : Elsevier Science Publishers B.V.) Interestingly the language has not been used for business process modelling (in the knowledge of this chapter’s authors), in spite of the 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). Two languages will be discussed below that allow the specification of business processes and translate 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 type. These features will be discussed on two examples: the CIMOSA languages and Workflow Modelling Languages.

9 ISO 8807:1989 (1989) Information processing systems -- Open Systems Interconnection -- LOTOS -- A formal description technique based on the temporal ordering of observational behaviour. 14

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 can not be given because the level of granularity in process description (modelling) depends on the model’s purpose. According to Uppington and Bernus (1996?) the level of granularity in BPM is driven by the need to understan the current state of affairs and by the pragmatic needs of the subsequent life-cycle phase of the change process and the personnel involved [20]. 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 [4]. 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 skilled and knowledgeable, 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 [12]. 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 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. 15

In addition, experience shows that during the development of the AS-IS model some demands and ideas about the process modification are already integrated into the model. Therefore parts of the AS-IS model is often not simply a snapshot of the existing process but also integrates some elements of the TO-BE model (confirming the fact that merely analysing the process has an impact on its present state).

2.5 CIMOSA process modelling language CIMOSA includes constructs (reference to CIMOSA baseline document) 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. 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 processes10, and eventually into enterprise activities. Relationships between activities are defined as behavioural rules.

DP1 Domain

PP1 A1 PP2

A2 A3 A4

DP…Domain process O1 O2 O3 A…..activity O…operation Figure 5.: Business Process Decomposition

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. On the level of detail that corresponds to the GERA detailed design phase CIMOSA a activity may be further described as a procedure (making CIMOSA on this level a workflow modelling language). This

10 According to this chapter’s definition of a ‘business process’ a domain process is a top-level business process. 16 procedure consists of a 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 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. [refer to EN / EMEIS]

2.6 Workflow Modelling Languages

2.7 Workflow Management and Execution Environments