process modelling extract v2

Copyright © John Owens 2009

All Rights Reserved

IMMTM

INTEGRATED MODELLING

METHOD

Process Modelling

John Owens

The development of IMM™has brought

Business Modelling into the 21st Century

A b us i ne s s m o de l l i ng meth o d f o r p r o fes s i o n a l an a l y st s an d bus i nes s

p er s o nne l a l i ke.

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

IMMTM

– INTEGRATED MODELLING METHOD PROCESS MODELLING

Copyright © John Owens www.integratedmodelling.co.nz Index Page 1

CONTENTS

1 INTRODUCTION 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 Schematic or Model? 3

2.2 W h i ch Model? 4

3 DEFINITIONS 4

3.1 Process 4

3.2 Required Elements of a Process 5

4 WHEN TO USE PROCESS MODELLING 7

5 DIAGRAMMING TECHNIQUE FOR PROCESSES 8

5.1 Diagramming Conventions 8

5.2 Funct ion Catalogue vs Process Diagram 9

6 BUILDING A PROCESS 11

6.1 Getting Started 11

6.2 Example 14

6.3 B u ilding the Diagram 15

6.4 Exercise 1 18

IMMTM



7 PROCESS FLOW 1 8

7.1 Precedence 1 9

7.2 S i m ple Process Flows 1 9

7.3 Triggering 2 1

7.4 Process Flow and ‘Dependency’ 2 5

7.5 M u l tiple Flows 2 5

7.6 C o m p o und Flows 2 7

7.7 B r a n c hing 2 8

7.8 More Complex Process Flows 3 0

7.9 I m p lied Arc 3 3

7.10 S h o r t hand Notation 3 4

7.11 Process Flows and Looping 3 6

7.12 ‘ I llegal’ Structures 3 7

7.13 Exercise 2 4 0

8 MORE ON OUTCOMES AND TRIGGERS 4 1

8.1 Further Definitions 4 1

8.2 C o n t i guous Process 4 2

8.3 Outcome = Trigger? 4 3

9 SWIM LANES 4 4

9.1 S w i m Lanes as Business departments 4 4

9.2 S w i m Lanes as Locations 4 5

9.3 S w i m Lanes as Job Roles 4 6

9.4 S w i m Lanes and Technology 4 6

9.5 S w i m Lanes vs Matrices 4 7

IMMTM



9.6 Errors Using Swim Lanes 47

10 DETAIL FOR PROCESS ELEMENTS 4 8

10.1 Trigger 4 8

10.2 Process Step (Function) 4 9

10.3 Outcome (Preferred) 4 9

10.4 Outcome (Non-Preferred) 5 0

10.5 S w i m Lane 5 0

11 W ORLDVIEW 5 1

11.1 Def in i tion: Worldview 5 1

11.2 Def in i tion: Management Horizon 5 1

11.3 L a y out of the Diagram 5 2

11.4 More on Data Flow 5 4

12 MORE ON NON-PREFERRED OUTCOMES 5 5

12.1 S ingle Non-Preferred Outcome 5 6

12.2 Techn ique for Non-Preferred Outcome 5 6

12.3 M u l tiple Non-Preferred Values 5 7

12.4 L o o king for Alternatives 5 7

12.5 M u l tiple Non-Preferred Outcomes 5 8

13 TUNING PROCESSES 6 0

13.1 Effectiveness and Efficiency 6 0

13.2 R a n k ing Non-Preferred Outcomes 6 1

13.3 Exercise 3 6 3

IMMTM



14 A D D I NG FUNCTIONS TO THE FUNCTION CATALOGUE

6 3

14.1 Adding Functions 6 4

14.2 Replac ing Functions 6 4

14.3 Example 6 4

15 LEVELS OF PROCESS MODEL 6 8

15.1 C o n v entional Approach 6 8

15.2 I M M ™ Approach 6 9

15.3 The ‘Replace’ Concept 7 0

15.4 No Such Thing as a High Level Process 7 1

16 BUSINESS PROCEDURE & WORKFLOW 7 2

17 USING CASE TOOLS 7 3

18 S O LUTIONS TO EXERCISES 7 3

18.1 S o lution to Exercise1 7 3

18.2 S o lution to Exercise 2 7 9

18.3 S o lution to Exercise 3 8 2

19 G L O SSARY 8 7

IMMTM


Copyright © John Owens www.integratedmodelling.co.nz Page 1

33 DEFINITIONSDEFINITIONS

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.13.1 PROCESSPROCESS

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 Step 3 Step 4 Step 5 Step 6 Outcome customer

order received

Accept Customer

Order

Verify Customer

Status

Verify Product Status

Verify Stock Status

Reserve Stock for Customer

Confirm Customer

Order

order confirmed

3.23.2 REQUIREDREQUIRED ELEMENTS OF A PROCE ELEMENTS OF A PROCESSSS

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

IMMTM



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.

Non-preferred 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 Non-Preferred 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.

IMMTM



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

44 WHEN TO USE PROCESS WHEN TO USE PROCESS MODELLINGMODELLING

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.

IMMTM



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.

55 DIAGRAMMINGDIAGRAMMING TECHNIQUE FOR TECHNIQUE FOR PROCESSESPROCESSES

The diagramming technique for Business Processes is the Process diagram. An example of a simple Process diagram is shown below.

Veri fy Customer

Status

Veri fy Product

Status

Veri fy Stock Status Confirm

Acceptance of

Customer Order

Reserve Stock for

Customer

customer order

received

customer order

accepted

Accept Customer

Order

Trigger OutcomeProcess Step = Function

Process Flow

Veri fy Customer

Status

Veri fy Product

Status

Veri fy Stock Status Confirm

Acceptance of

Customer Order

Reserve Stock for

Customer

customer order

received

customer order

accepted

Accept Customer

Order

Trigger OutcomeProcess Step = Function

Process Flow

5.15.1 DIAGRAMMING CONVDIAGRAMMING CONVENTIONSENTIONS

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.

IMMTM



Element Representation

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

vacancy

identified

vacancy

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:

employee

assigned

employee

assignedPO

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

interview

cancelled

NO

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

Hire Candidate

IMMTM



5.25.2 FUNCTION CATALOGUE FUNCTION CATALOGUE vsvs PROCESS PROCESS DIAGRAMDIAGRAM

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?

Recruit Personnel

Advertise Vacancy Assess

Applications

Scedule Interviews Interview

Candidates

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

IMMTM



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.

<Break in Extract>

77 PROCESS FLOWPROCESS FLOW

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.17.1 PRECEDENCEPRECEDENCE

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.

IMMTM



7.27.2 SIMPLE PROCESS FLOWSSIMPLE PROCESS FLOWS

This section describes some of the basic ways in which Process flow is drawn on Process diagrams.

FUNCTION TO FUNCTIONFUNCTION TO FUNCTION

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.

IMMTM



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.

TRIGGER TO FUNCTIONTRIGGER TO FUNCTION

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 OUTCOMEFUNCTION TO OUTCOME

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.

IMMTM



<Break in Extract>

7.77.7 BRANCHINGBRANCHING

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.

UNCONDITIONAL BRANCHUNCONDITIONAL BRANCH An unconditional branch occurs when steps of a Process can be carried out simultaneously as shown below.

A

B

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.

A

B

C

A real life example of an unconditional branch is shown below:

Initiate IT Project

Develop Project

Plan

Determine

Software

Requirements

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

CONDITIONAL BRANCHCONDITIONAL BRANCH A conditional branch is where the route through the Process is determined by the occurrence of some state or value.

IMMTM



Arc

Verify Customer

Status

Verify Product

Statusgood

credit

rating

Accept Customer

Order

Reject Customer

Order

bad

credit

rating

customer order

rejected

Arc

Verify Customer

Status

Verify Product

Statusgood

credit

rating

Accept Customer

Order

Reject Customer

Order

bad

credit

rating

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.

Verify Customer

Status

Verify Product

Status

good credit rating

Reject Customer

Orderbad credit rating

Request Deposit

medium

credit rating

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

IMMTM



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

Verify Product

Status

Reject Customer

Order

Request Deposit

Status

Good?

YES

Status

Medium?NO

YES

NO

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.

<Break in Extract>

IMMTM



99 SWIM LANESSWIM LANES

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.19.1 SWIM LANES AS BUSINESWIM LANES AS BUSINESS SS DEPARTMENTSDEPARTMENTS

Stores

CustomerServices Verify Customer

Status

Verify ProductStatus

Verify Stock Status

ConfirmAcceptance ofCustomer Order

Reserve Stock forCustomer

customer orderreceived

customer orderaccepted

Accept CustomerOrder

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.

IMMTM



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.29.2 SWIM LANES AS LOCATISWIM LANES AS LOCATIONSONS

Warehouse

Head OfficeVerify CustomerStatus


Verify Stock Status






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

IMMTM



9.39.3 SWIM LANE SWIM LANES AS JOB ROLESS AS JOB ROLES

SeniorStoreman

Senior CSRVerify CustomerStatus


Verify Stock Status






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.49.4 SWIM LANES AND TECHNSWIM LANES AND TECHNOLOGYOLOGY

Main FrameStoresSystem

Main FrameAccountsSystem

PC BasedSales System

ManualAction

Verify CustomerStatus


Verify Stock Status ConfirmAcceptance ofCustomer Order





IMMTM



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.59.5 SWIM LANES SWIM LANES vsvs MATRICES MATRICES 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.69.6 ERRORS USING SWIM LAERRORS USING SWIM LANESNES 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.

Production

Stores


StatusVerify ProductStatus

Verify Stock Status

Production

Stores



Verify Stock Status

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:

IMMTM



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

Production

Stores



type Aproduct

Verify Stock StatusVerify ProductStatus

type B product


type C product

Production

Stores



type Aproduct

Verify Stock StatusVerify ProductStatus

type B product


type C product

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.

IMMTM



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.

process modelling extract v2

Documents