Process Modelling Extract V2

IMMTM

INTEGRATED MODELLING METHOD Process Modelling John Owens The development of IMM™has brought Business Modelling into the 21st Century

A business mo del l ing method for pr ofessi on al ana l ysts and business per sonnel a l i ke.

Copyright © John Owens 2009 All Rights Reserved

Copyright © John Owens 2009 No part of this document may be reproduced, photocopied, stored for retrieval by electronic means or made available to (or transferred to) any third party without the express written permission of the author

Trademarks The term IMM™ and the IMM™ Logo are both registered trademarks.

Copyright © 2009

IMM

TM

– INTEGRATED MODELLING METHOD

PROCESS MODELLING

CONTENTS 1 I N T R ODUCTION

1

1.1 I M M ™

1

1.2 The elements if IMM™

1

1.3 First Things First

2

1.4 Before Starting This Book

3

2 WHAT IS A BUSINESS MODEL?

3

2.1 S c h e m a tic or Model?

3

2.2 W h i ch Model?

4

3 DEFINITIONS

4

3.1 Process

4

3.2 R e q u i r e d Elements of a Process

5

4 WHEN TO USE PROCESS MODELLING

7

5 D I A G RAMMING TECHNIQUE FOR PROCESSES

8

5.1 D i a g r a m ming Conventions

8

5.2 F u n c t ion Catalogue vs Process Diagram

9

6 BUILDING A PROCESS

11

6.1 Getting Started

11

6.2 E x a m p l e

14

6.3 B u ilding the Diagram

15

6.4 Exercise 1

18

Copyright © John Owens

www.integratedmodelling.co.nz

Index Page 1

IMM

TM

– INTEGRATED MODELLING METHOD

PROCESS MODELLING

7 P R O C E SS FLOW

18

7.1 Precedence

19

7.2 S i m ple Process Flows

19

7.3 Triggering

21

7.4 Process Flow and ‘Dependency’

25

7.5 M u l tiple Flows

25

7.6 C o m p o und Flows

27

7.7 B r a n c hing

28

7.8 More

30

Complex Process Flows

7.9 I m p lied Arc

33

7.10 S h o r t hand Notation

34

7.11 Process Flows and Looping

36

7.12 ‘ I llegal’ Structures

37

7.13 Exercise 2

40

8 MORE ON OUTCOMES AND TRIGGERS

41

8.1 Further Definitions

41

8.2 C o n t i guous Process

42

8.3 Outcome = Trigger?

43

9 SWIM LANES

44

9.1 S w i m Lanes as Business departments

44

9.2 S w i m Lanes as Locations

45

9.3 S w i m Lanes as Job Roles

46

9.4 S w i m Lanes and Technology

46

9.5 S w i m Lanes vs Matrices

47

Copyright © John Owens

www.integratedmodelling.co.nz

Index Page 2

IMM

TM

– INTEGRATED MODELLING METHOD

PROCESS MODELLING

9.6 Errors Using Swim Lanes

47

10 DETAIL FOR PROCESS ELEMENTS

48

10.1 Trigger

48

10.2 Process Step (Function)

49

10.3 Outcome (Preferred)

49

10.4 Outcome (Non-Preferred)

50

10.5 S w i m Lane

50

11 W ORLDVIEW

51

11.1 D e f i n i tion: Worldview

51

11.2 D e f i n i tion: Management Horizon

51

11.3 L a y out of the Diagram

52

11.4 More

54

on Data Flow

12 MORE ON NON-PREFERRED OUTCOMES

5 5

12.1 S ingle Non-Preferred Outcome

56

12.2 T e c h n i que for Non-Preferred Outcome

56

12.3 M u l tiple Non-Preferred Values

57

12.4 L o o king for Alternatives

57

12.5 M u l tiple Non-Preferred Outcomes

58

13 TUNING PROCESSES

60

13.1 Effectiveness and Efficiency

60

13.2 R a n k ing Non-Preferred Outcomes

61

13.3 Exercise 3

63

Copyright © John Owens

www.integratedmodelling.co.nz

Index Page 3

IMM

TM

– INTEGRATED MODELLING METHOD

PROCESS MODELLING

14 A D D I NG FUNCTIONS TO THE FUNCTION CATALOGUE 63 14.1 Adding Functions

64

14.2 R e p l a c ing Functions

64

14.3 E x a m p l e

64

15 LEVELS OF PROCESS MODEL

68

15.1 C o n v entional Approach

68

15.2 I M M ™ Approach

69

15.3 The

70

15.4 No

‘Replace’ Concept Such Thing as a High Level Process

16 B U S I N ESS PROCEDURE & WORKFLOW

71

7 2

17 USING CASE TOOLS

73

18 S O LUTIONS TO EXERCISES

73

18.1 S o lution to Exercise1

73

18.2 S o lution to Exercise 2

79

18.3 S o lution to Exercise 3

82

19 G L O SSARY

87

Copyright © John Owens

www.integratedmodelling.co.nz

Index Page 4

IMM

TM

3

– INTEGRATED MODELLING METHOD

PROCESS MODELLING

DE FI NI TIO NS This section defines all of the terms you will need to know in order to model Business Processes successfully. The Glossary in Section Error! Reference source not found. contains definitions that cover all of the elements of IMM™, business analysis in general and some elementary systems design definitions.

3.1

PROCESS A Business Process, usually referred to simply as a Process, is the definition of the order of execution of Business Functions, usually referred to as Functions, in order to arrive at a particular Outcome, given one or more specific Triggers. Every Process must have at least one Trigger and at least one Preferred Outcome. An example of a Process is ‘Accept Customer Order’. This could comprise the following elements: Trigger

Step1

Step 2

customer Accept Verify order Customer Customer received Order Status

3.2

Step 3

Step 4

Verify Product Status

Verify Stock Status

Step 5

Step 6 Outcome

Reserve Confirm order Stock for Customer confirmed Customer Order

REQUIRED ELE MENTS O F A PR OCE SS Every Process must comprise all of the following elements: Element

Definition

Objective

This is the starting point for all Processes. It describes what the Process is meant to achieve. Rule: No objective = No Process! If there is nothing to be achieved, then there is no need to link activities together to achieve it! Sadly, many ‘Processes’ in real life have been built without objectives and, unsurprisingly, seem to achieve very little! An example of an objective for the Process ‘Receive and Resolve Domestic Billing Query’ would be: “To ensure that all billing queries from domestic customers are dealt with in a consistent manner and resolved in the shortest time either by explanation or by correction of errors.”

Copyright © John Owens

www.integratedmodelling.co.nz

Page 1

IMM

TM

– INTEGRATED MODELLING METHOD

PROCESS MODELLING

Element

Definition

Description

A description is added whenever it is necessary to expand on or qualify the objective. For example, for the Process ‘Receive and Resolve Domestic Billing Query’ the description might be: “This Process deals only with queries from domestic customers. All domestic queries should be resolved within 24 hours of receipt of the query.”

Name

A unique name that succinctly describes the Process objective. The naming convention for Processes is identical to that for Functions as described in the IMM™ book Function Modelling. In summary these are: •

The name should begin with a strong, positive, active verb.

•

The verb should act on a noun or nouns.

•

All major words should be capitalised.

Examples of Process names are: ‘Recruit Employee & Assign to Post’, ‘Receive Order & Confirm Acceptance’, ‘Receive and Resolve Customer Billing Query’. Trigger

A specific occurrence that initiates the Process within the business by ‘triggering’ the Function that is the first step in the Process. Every Process must have at least one Trigger.

Preferred Outcome

This is the result that the Process is preferred to achieve and can be thought of as concise way of expressing the objective for the Process. Every Process must have one Preferred Outcome.

Nonpreferred Outcome

This represents a desired Outcome for the Process if the Preferred Outcome is not achievable. A Process may have many Non-Preferred Outcomes. This is the only optional element of a Process because it is possible, though unusual, for a Process to have no NonPreferred Outcomes.

Events

Triggers and Outcomes can be collectively referred to as Events (with a capital “E”).

Process Steps

Each step in a Process must be a Function from the Function Catalogue. Ideally each one should be elementary Business Functions (EBF’s) or, failing that, an atomic Function from the Catalogue as it stands at this stage in analysis.

Copyright © John Owens

www.integratedmodelling.co.nz

Page 2

IMM

TM

– INTEGRATED MODELLING METHOD

PROCESS MODELLING

Element

Definition

Process Flow

This defines the order in which the Process steps should be carried out and how each step is related to the preceding and following steps. In essence it defines how control moves from Function to Function within the Process. Process flow is described in detail in Section 7.

Detail on the information that ought to be supplied for each of the above Process elements is described in SectionError! Reference source not found..

4

WHE N TO USE PROCESS MO DELLI NG Process modelling is only applicable in circumstances where: a) You need to map in detail a course from a specific Trigger to a specific Outcome, for example: “Given the Event ‘customer order received’ how do we get to the Preferred Outcome ‘customer order fulfilled’?” b) You need to know how to achieve a particular state within the business, for example: “What Functions must we carry out and in what precise sequence in order to hire a new employee and end up with that employee in post?” If what you are trying to do is not in either of these categories then Process modelling is NOT the correct technique to use! Process modelling is not a technique to be used for cataloguing all of the activities of a business. That is the role of the Function Catalogue. The most common misuse of Process modelling is when someone in the business says “We need to know what the business does” and someone starts building Process models. Its use in this way is inappropriate, time consuming and ineffective as it misses out up to 50% of all business activities! The quickest, simplest and most effective modelling technique to show “what the business does” is the Function Catalogue. This, ideally, should be done before Process modelling as it is the foundation of Process models, indeed of all business models. However, Process models and the Function Catalogue are interdependent and the activities in Process modelling can help expand and improve the Function Catalogue.

Copyright © John Owens

www.integratedmodelling.co.nz

Page 3

IMM

TM

– INTEGRATED MODELLING METHOD

PROCESS MODELLING

My book IMM™ Function Modelling is available from our on-line store at www.integratedmodelling.co.nz I strongly recommended you to read that book before embarking Process modelling.

5

DIA GRA MMI NG TE CH NIQUE FOR PRO CE SSE S The diagramming technique for Business Processes is the Process diagram. An example of a simple Process diagram is shown below. Trigger customer order received

Process Step = Function Accept Customer Order

Verify Customer Status

Outcome Verify Product Status

Verify Stock Status

Reserve Stock for C ustomer

C onfirm A cceptance of C ustomer Order

customer order accepted

Process Flow

5.1

DIAGR AM MIN G CO NV ENTIONS In IMM™ each element of a Process is represented on a Process diagram in a specific and consistent manner as described in the following table. Element

Representation

Objective

The objective for the Process need not appear on the diagram but, if is felt that it would aid in understanding the diagram, it can be placed in a rectangle positioned either at the top right or along the bottom. When using CASE tools (see Section Error! Reference source not found.) the objective is held within the tool and can be printed on reports as and when required.

Description

The description need not appear on the Process diagram but can be added to the same box as the objective whenever it is felt that it will add clarity. When using CASE tools the description can be printed when required.

Name

The name of the Process should appear in a rectangle at the top left of the Process diagram. This is not just technical drawing standard but essential to tell those viewing the diagram what the Process is as opposed to leaving them to guess! The version number of the diagram and the date it was drawn should also appear in this box.

Copyright © John Owens

www.integratedmodelling.co.nz

Page 4

IMM

TM

– INTEGRATED MODELLING METHOD

PROCESS MODELLING

Element

Representation

Trigger

The drawing convention for a Trigger is a block arrow pointing to the right, for example: vacancy identified

v acancy identified

If using colour then the Trigger should be green with black text. Preferred Outcome

Preferred Outcomes are drawn as block arrows pointing to the left, for example: em ployee as signed

PO

em ployee as signed

If the diagram is in black and white the initials PO (indicating Preferred Outcome) should be placed to the right of the symbol, as shown above. If using colour then the Preferred Outcome should be green with black text. Non-Preferred Outcome

Non-Preferred Outcomes are drawn as block arrows pointing to the left, for example: interview cancelled

NO

interview cancelled

If the diagram is in black and white the initials NO (indicating Non-preferred Outcome) should be placed to the right of the symbol, as shown above. If using colour then the Non-Preferred Outcome should be red with black text. Process Step

Each Process step (Function) is drawn as a rectangle with rounded corners, as on the Function Catalogue, containing the name of the Function. Interview Candidates

Offer Position to Candidate

If using colour then the step should be pale colour – we have chosen yellow – with a black border and black text. Process Flow

The flow of control from one Process step to another, is shown by a solid arrow between the Process steps, like this: Offer Position to Candidate

Copyright © John Owens

Hire Candidate

www.integratedmodelling.co.nz

Page 5

IMM

TM

5.2

– INTEGRATED MODELLING METHOD

PROCESS MODELLING

FUNCTION CATAL O GUE vs PRO CESS DIAGR AM The Function Catalogue is not (nor is it meant to be) a Process model. The segment of the Catalogue below shows the steps involved in recruiting personnel, but is it a Process? Rec ruit Personnel

Advertise Vacancy

Assess Applications

Sc edule Interviews

Interview Candidates

Selec t a Candidate

Offer Position to Candidate

Hire Candidate

We can check by seeing if it possesses the required elements of a Process. If does not then it is not a Process. Element

Comment

Objective

What is the objective? On the Function Catalogue there is not really an objective for a grouping Function. It could be implied, but maybe not correctly, that the objective for ‘Recruit Personnel’ is equivalent to the sum of the objectives for all of the Functions beneath it. This could be a long winded and a messy objective.

Description

It could be suggested that the description for ‘Recruit Personnel’ would equate to the description for a Process. But, as we saw in the book on Function Modelling (which you ought to read before proceeding with Process modelling), the only descriptions that grouping Functions have, when they have them, is a list of their child Function names.

Name

It could be suggested that the combination of the child Functions has the name ‘Recruit Personnel’ and this is the name of the Process. This is possible but again is being implied, which is not good practice in analysis and modelling.

Trigger & Outcome

There is no Trigger and no Outcome, both essential elements of a Process.

Process Flow

The order in which the Functions are arranged under ‘Recruit Personnel’ on the above Function Catalogue merely suggests the order in which they might be executed under normal circumstances. It cannot define the precise order in which Functions will be carried within a Process because a single Function in the Catalogue could be a step in more than one Process.

Copyright © John Owens

www.integratedmodelling.co.nz

Page 6

IMM

TM

– INTEGRATED MODELLING METHOD

PROCESS MODELLING

So does the above Function Catalogue equate to a Process? The answer is ‘no’. It fails to meet the criteria for a Process on nearly all counts. This is not a shortcoming of the Function Catalogue. It is not meant to be a Process Model, no more than it is meant to be an Information Flow Model.The power of IMM™ is that there is a suitable technique for modelling each different facet of a business. The use of the different techniques is not an added burden but significantly adds to productivity, accuracy and clarity.

7

PRO CE SS FL OW We talked about Process flow briefly in Sections 3.2 and Error! Reference source not found.. We will now look at it in more detail and the way it is portrayed on Process diagrams.

7.1

PRECEDENCE E1

A

A

B

B

O1

Process flow represents two things: • The order in which Process steps should be carried out. • The flow of control from one step to another. These two things can be conveniently shown on Process diagrams as an arrow going from one object (and Event or a Function) to another. The arrow indicates that: 1) Control within the Process passes from the object at the source of the arrow to the object at the point of the arrow. 2) The object at the point of the arrow cannot be carried out until the object at the source of the arrow has finished. The conditions and relationships described in 1) and 2) above can be conveniently combined into the term ‘precedence’, i.e. the object at the source of the arrow ‘precedes’ the object at the point of the arrow.

Copyright © John Owens

www.integratedmodelling.co.nz

Page 7

IMM

TM

7.2

– INTEGRATED MODELLING METHOD

PROCESS MODELLING

SIMPLE PRO CESS FL OWS This section describes some of the basic ways in which Process flow is drawn on Process diagrams.

FUNCTION TO FUNC TION A

B

The above diagram shows the most common form of Process flow. The arrow going from Function A to Function B tells us: 1) In the context of the Process being modelled, A is carried out before B. 2) In the context of the Process being modelled, on completion of A control passes to B. 3) In the context of the Process being modelled, B cannot begin until A has finished. 4) In the context of the Process being modelled, B can begin at any appropriate time after A has finished. The term ‘in the context of the Process being modelled’ is used to point out that the Process flow shown between objects on a particular Process diagram can be thought of as being valid and true ONLY in the context of the Process the diagram represents. With regard to Function A and Function B, it is possible, and probable, that in other Processes that they could be preceded or followed by entirely different Functions or Events. For this reason each statement in the following text defining Process flow should be thought of as beginning with the phrase ‘in the context of the Function being modelled’. It is a useful practice when checking the correctness of your Process model with key members of the business to state the relationship between Functions as in 3) and 4) above. These are known as the ‘reverse form’. The reason for this is that the relationship as stated in Error! Reference source not found. and 2) (the direct form) nearly always seems self evident. However, when people are presented with the statements in the reverse form they are made to rethink.

Copyright © John Owens

www.integratedmodelling.co.nz

Page 8

IMM

TM

– INTEGRATED MODELLING METHOD

PROCESS MODELLING

They ask themselves: ‘Is it really true that B cannot begin before A is complete?’ or ‘can B really begin anytime after A has finished?’ The responses to these questions often bring changes that significantly improve the Process being modelled. The term ‘improve’ is perhaps an understatement as they often change the Process from being wrong to being right! In all forms of analysis asking the reverse form of a question is a powerful technique for validating the direct form. People will often quickly agree with the direct form and then revise their opinion when presented with the reverse form.

TRIGG ER TO FUNC TION E1

A

The above segment of a Process flow that tells us two things: • The occurrence of the Event E1 starts up Function A. Events that start up Functions and, hence, Processes are called ‘Triggers’. • A cannot begin until the Event E1 has occurred. The relationship between a Trigger and a Function differs from that between a Function and a Function in one essential way; control does not pass from the Trigger to the Function. Triggers do not have ‘control’ of the Process but they can initiate a Function, which then has control.

FUNCTION TO OUTC OM E B

O1

The above Process flow tells us two things: • The completion of Function B gives rise to the Event O1. Events arising as the result of the completion of Functions are called Outcomes. • Outcome O1 cannot occur before Function B has finished. The relationship between a Function and an Outcome differs from that between a Function and a Function in that control does not pass from the Function to the Outcome. Outcomes do not have ‘control’ of the Process; they end the need for control because they end the Process. Copyright © John Owens

www.integratedmodelling.co.nz

Page 9

IMM

TM

– INTEGRATED MODELLING METHOD

PROCESS MODELLING



7.7

BR ANCHIN G In real life Processes will not be as simple and straightforward as those we have dealt with so far. Most Processes will include ‘branches’ where the route through the Process splits. There are two types of branch: unconditional and conditional.

UNCON DITIONAL BRAN CH An unconditional branch occurs when steps of a Process can be carried out simultaneously as shown below. B A C

In the above unconditional branch, after Function A has finished control is passed to both Function B and Function C. This is not an ‘either or’ situation as both B and C can begin after the completion of A. For this reason it is better to draw the diagram as below where the arrows leaving Function A have been merged into one. B A C

A real life example of an unconditional branch is shown below: Develop Project Plan Initiate IT Project Determine Software Requirements

In the above example, ‘Develop Project Plan’ and ‘Determine Software Requirements’ can both be started after ‘Initiate IT Project’ has finished.

COND ITIONAL B RANC H A conditional branch is where the route through the Process is determined by the occurrence of some state or value.

Copyright © John Owens

www.integratedmodelling.co.nz

Page 10

IMM

TM

– INTEGRATED MODELLING METHOD

Accept Customer Order

PROCESS MODELLING

Verify Customer Status

Arc

good credit rating

Verify Product Status

bad credit rating

Reject Customer Order

customer order rejected

In the above example, if the customer has a good credit rating then we proceed with the order and verify the product status. If the credit rating is bad we reject the order and end the Process. Because the route taken is based on some condition being satisfied this is called a ‘conditional’ branch. Because the conditions being met are mutually exclusive, i.e. the customer must either have a good credit rating or a bad one, the flows leaving the decision making Function are also said to be mutually exclusive. The drawing convention in IMM™ for showing mutually exclusive flows leaving a Process is a line drawn across the flows. This line is called an ‘arc’. The Function ‘Reject Customer Order’ may not have existed on the Function Catalogue at the start of Process modelling as the need for it may only have become apparent during Process modelling and so will need to be added to it. Adding new Functions to the Function Catalogue is an integrated part of Process modelling and is covered in detail in Section Error! Reference source not found.. The Outcome ‘customer order rejected’ is a ‘non-preferred’ Outcome. We deal with these in detail in Section Error! Reference source not found.. The evaluation carried out by a Function can result in any number of (two or more) predefined states, so any number of flows can be included in an arc. good credit rating

Verify Customer Status

Verify Product Status

Request Deposit medium credit rating

bad credit rating

Reject Customer Order

In the example above the Function ‘Verify Customer Status’ evaluates the customer’s credit record and classes it as one of three possible statuses, ‘good’, ‘medium’ or ‘bad’. Each of these statuses will pass control to a different Function after the completion ‘Verify Customer Status’.

Copyright © John Owens

www.integratedmodelling.co.nz

Page 11

IMM

TM

– INTEGRATED MODELLING METHOD

PROCESS MODELLING

This idea of having as many flows in an arc as are required by the business to Function properly is different from the ‘yes/no’ approach used in conventional modelling where every decision box (usually in the form of a diamond) could have only two Outcomes. This ‘binary’ approach had its roots in computer flow-charting where binary Outcomes were desirable. However, in Process modelling this approach is cumbersome and has some major disadvantages. Verify Customer Status

Status Good?

NO YES

Verify Product Status

Status Medium?

NO

Reject Customer Order

YES Request Deposit

In the above diagram, based on the conventional ‘binary’ approach, the statuses represented by the lines in our arc have had to be converted into binary test ‘diamonds’. There are four main disadvantages to this approach: • It adds unnecessary symbols to the diagram. The Function ‘Verify Customer Status’ has tested for the appropriate statuses and yet this testing has to shown again in the binary boxes. • All situations have to be reduced to binary format. This may have advantages when designing a computer program but has none in a Process model. • The integrity of the Process models is maintained at a high level by the rule that all steps in a Process should be Functions from the Function Catalogue. The Function Catalogue would become a mess if it had to hold ‘Status Good?’, ‘Status Medium?’ and, in any business of a moderate size, several hundred more such binary tests. • This approach detracts from the elegance of the Process model. This desire for elegance is not just an aesthetic thing. A Process diagram is a visual aid to understanding a Process and, as such, should be pleasing to the eye. If it is, it will also be easier to understand and will reduce confusion and ambiguity. For these reasons IMM™ does not use or advocate the use of binary decision boxes in Process diagrams.

Copyright © John Owens

www.integratedmodelling.co.nz

Page 12

IMM

TM

– INTEGRATED MODELLING METHOD

9

PROCESS MODELLING

SWIM LA NE S When modelling Business Processes it is often important to know what part of the organisation does each step in the Process, or the location at which each step is done, or what job role does each step. The use of ‘Swim Lanes’ is an effective way to show these things. They are rectangles stretched across the Process diagram and can be used to represent: • Business departments • Business locations • Job roles • Types of technology Each step in the Process is then placed in a swim lane. The term ‘swim lane’ came about by somebody thinking that the horizontal rectangles across the page looked like the lanes in a swimming pool viewed from above!! (There are such individuals!)

9.1

Customer Services

SWIM LANES AS BU SINE SS DEPAR TMEN TS customer order received

Accept Customer Order

Verify Customer Status

Confirm Acceptance of Customer Order

customer order accepted

Stores Verify Product Status

Verify Stock Status

Reserve Stock for Customer

The diagram above is an example of a Process model using swim lanes to represent business departments. What does this diagram tell us? • There are two departments involved in the Process. • The Process is triggered and ends in Customer Services. • After ‘Verify Customer Status’ responsibility passes from Customer Services to Stores. • After ‘Reserve Stock for Customer’ responsibility passes from Stores to Customer Services.

Copyright © John Owens

www.integratedmodelling.co.nz

Page 13

IMM

TM

– INTEGRATED MODELLING METHOD

PROCESS MODELLING

There are major benefits in using swim lanes in this way. It can answer such questions as: • How many business departments are involved in the Process? • Is the Process fragmented as a result of too many departments? • How many times during the Process does responsibility pass from one department to another? These ‘handoffs’ between departments represent potential problems in a Process because: • With the handoff comes a change of responsibility • Different departments may have different business objectives and different performance indicators (see Section Error! Reference source not found.) that may not align. • The different departments may use different computer systems and different technologies.

9.2

SWIM LANES AS LOCATI O NS

Head Office customer order received

Accept Customer Order

Verify Customer Status

Confirm Acceptance of Customer Order

customer order accepted

Warehouse Verify Product Status

Verify Stock Status

Reserve Stock for Customer

In the above diagram the swim lanes represent locations at which the business is carried out. The diagram tells us: • The business is carried out at two locations. • That there needs to be some way of communicating between these locations in order to be able to complete customer orders. This may all seem self evident from such a simple diagram but in a real life situation the Process would be larger and more detailed and there could be numerous locations. In such circumstances the visual representation that a Process diagram provides can enable problems and solutions to be visualised that might not be possible to appreciate using text alone or even matrices (see Section 9.5).

Copyright © John Owens

www.integratedmodelling.co.nz

Page 14

IMM

TM

– INTEGRATED MODELLING METHOD

9.3

PROCESS MODELLING

SWIM L ANE S AS JO B RO LES

Senior CSR customer order received

Accept Customer Order

Verify Customer Status

Senior Storeman

Verify Product Status

Confirm Acceptance of Customer Order

Verify Stock Status

customer order accepted

Reserve Stock for Customer

The above diagram shows swim lanes being used to represent job roles. This tells us: • What the responsibilities of a Senior Customer Services Representative and of a Senior Store Man are with regard to processing customer orders. • The Functions in which both of these job roles will require training. • The circumstances in which these two job roles will need to communicate. Knowing such things can enable the business to make sure appropriate training is developed and made available and that the people performing these roles are supplied with the correct technology to allow them to carry out the Functions. The use of swim lanes to represent job roles is normally not done when building Process diagrams but restricted to business procedures. My book on how to model business procedure in IMM™ is available from our on-line store at www.integratedmodelling.co.nz

9.4

SWIM LANES AND TECHN OLO GY

Manual Action

customer order received

PC Based Sales System

Verify Stock Status

customer order accepted

Accept Customer Order

Main Frame Accounts System

Verify Customer Status

Main Frame Stores System

Verify Product Status

Copyright © John Owens

Confirm Acceptance of Customer Order

www.integratedmodelling.co.nz

Reserve Stock for Customer

Page 15

IMM

TM

– INTEGRATED MODELLING METHOD

PROCESS MODELLING

The diagram above shows how swim lanes can be used to represent technology. Such a diagram can be useful in visualising where disparate technologies are used across a single Process.

9.5

SWIM LANES vs M ATR ICE S It can be very time consuming building different Process diagrams with swim lanes representing business departments, locations, job roles and technologies. Because of this the use of swim lanes is normally restricted to representing business departments. When building procedure diagrams (see Section Error! Reference source not found.) the swim lanes are normally used to represent job roles. So what about locations, technologies, etc.? A much less labour intensive way of mapping Process steps against any number of other elements is the use of Matrix Modelling. My book on Matrix Modelling in IMM™ is available from our online store at www.integratedmodelling.co.nz

9.6

ERRORS USIN G SWIM L A NES A common error in Process modelling occurs when a Function can occur in more than one department of a business. Many analysts draw the Function stretched across several swim lanes as in the diagram below. Customer Services

Verify Customer Status

Verify Product Status

Stores Verify Stock Status

Production

The problem with stretching the box across all swim lanes is that it is unclear what happens after ‘Verify Customer Status’ is complete. • Is the next step triggered in all three departments at the same time? This would be very undesirable and is very unlikely. • But, if that is not the case, what does happen? If a Function can happen in several departments there must be conditions that occur that cause the Function to be done in one department rather than another. Mapping these conditions on the Process diagram will make clear what these are. The technique to use in these circumstances is to: Copyright © John Owens

www.integratedmodelling.co.nz

Page 16

IMM

TM

– INTEGRATED MODELLING METHOD

PROCESS MODELLING

• Place an occurrence of the Function in question in each of the relevant swim lanes. • Create a conditional branch at the Function preceding the Function in question. • Write on each of the branches the condition that causes it to occur in the relevant department. The diagram below shows how this is done. Customer Services

Verify Customer Status

type A product

Verify Product Status

Stores type B product

Verify Product Status

Verify Stock Status

Production type C product

Verify Product Status

The above diagram removes the ambiguity that existed in the original diagram as to what happened after ‘Verify Customer Status’ and shows the circumstances that cause the subsequent Function to be carried out in a specific department. The rule here is ‘Do not, under any circumstances, stretch Functions across swim lanes’. It might be that the business needs to know the different circumstances in which Processes are ending in Non-Preferred Outcomes. If this is the case it might be desirable to have a separate Non-Preferred Outcome to match each circumstance. In our example three such Non-Preferred Outcomes would be required: • ‘order rejected – bad credit rating’ • ‘order rejected – no product’ • ‘order rejected – no stock’ These would replace the existing Non-Preferred Outcome ‘customer order rejected’. This would be deleted from the list of valid Non-Preferred Outcomes for the business after checking that it was not being used by any other Process. The term ‘customer’ was omitted prior to “order rejected’ from the new Non-Preferred Outcome name in order to shorten it, but without loosing meaning. modelling prior to computerisation and enable business modelling to be an activity in its own right.

Copyright © John Owens

www.integratedmodelling.co.nz

Page 17

IMM

TM

– INTEGRATED MODELLING METHOD

PROCESS MODELLING

Serious CASE tools are ‘repository based’. This means that they have a database in which you create all the objects that you use on various models. Because the object is held in the database you have to create it only once and can use it again and again whenever you need it. We strongly recommend that you use a repository based CASE tool to do business modelling as it will greatly increase productivity, accuracy and integrity. Avoid the use of those applications that are merely diagramming tools and which do not have a database as they result in a large amount of replication, are low in productivity and greatly reduce the overall integrity of models.

Copyright © John Owens

www.integratedmodelling.co.nz

Page 18