Process Modelling Extract V2

IMMTM
INTEGRATED
MODELLING
METHOD
Process Modelling
John Owens
The development of
IMM™has brought A business mo del l ing method for
Business Modelling into pr ofessi on al ana l ysts and business
the 21st Century 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
TM
IMM – 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

TM
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 Complex Process Flows 30
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

TM
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 on Data Flow 54
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

TM
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 ‘Replace’ Concept 70
15.4 No Such Thing as a High Level Process 71
16 B U S I N ESS PROCEDURE & WORKFLOW 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

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

customer Accept Verify Verify Verify Reserve Confirm order
order Customer Customer Product Stock Stock for Customer confirmed
received Order Status Status Status Customer Order
3.2 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

TM
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 This is the result that the Process is preferred to achieve
Outcome and can be thought of as concise way of expressing the
objective for the Process. Every Process must have one
Preferred Outcome.
Non- This represents a desired Outcome for the Process if the
preferred Preferred Outcome is not achievable. A Process may
Outcome 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 Each step in a Process must be a Function from the
Steps 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.

TM
Element Definition
Process This defines the order in which the Process steps should
Flow 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.

TM
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 Process Step = Function Outcome
customer order Accept Customer Verify Customer Verify Product Verify Stock Status Reserve Stock for C onfirm customer order
received Order Status Status C ustomer A cceptance of accepted
C ustomer Order
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.

TM
Element Representation
Trigger The drawing convention for a Trigger is a block arrow

pointing to the right, for example:
vacancy v acancy
identified identified
If using colour then the Trigger should be green with

black text.
Preferred Preferred Outcomes are drawn as block arrows
Outcome pointing to the left, for example:
em ployee PO em ployee
as signed 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 Non-Preferred Outcomes are drawn as block arrows
Outcome pointing to the left, for example:
interview NO interview
cancelled 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 Offer Position to
Candidates 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 Hire Candidate
Candidate

TM
5.2 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 Sc edule Interviews Interview Selec t a Candidate Offer Position to Hire Candidate
Applications Candidates 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 & There is no Trigger and no Outcome, both essential
Outcome 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.

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

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

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

TM
<Break in Extract>
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.
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 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.

TM
Accept Customer Verify Customer Verify Product

Order Status Status
good
credit
rating
Arc bad
credit
rating
Reject Customer customer order

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 Product
Status
Verify Customer Request Deposit

Status
medium
credit rating
Reject Customer
Order
bad 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’.

TM
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 Reject Customer

Status Status
Status Order
Good? NO Medium? NO
YES YES
Verify Product Request Deposit

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

TM
9 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 SWIM LANES AS BU SINE SS

DEPAR TMEN TS
Customer
Services customer order Accept Customer Verify Customer Confirm customer order
received Order Status Acceptance of accepted
Customer Order
Stores
Verify Product Verify Stock Status Reserve Stock for
Status 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.

TM
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 Accept Customer Verify Customer Confirm customer order
Customer Order
Warehouse
Verify Product Verify Stock Status Reserve Stock for
Status 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).

TM
9.3 SWIM L ANE S AS JO B RO LES
Senior CSR
customer order Accept Customer Verify Customer Confirm customer order
Customer Order
Senior
Storeman Verify Product Verify Stock Status Reserve Stock for
Status 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 Verify Stock Status Confirm customer order
received Acceptance of accepted
Customer Order
PC Based
Sales System Accept Customer
Order
Main Frame
Accounts Verify Customer
System Status
Main Frame
Stores Verify Product Reserve Stock for
System Status Customer

TM
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 Verify Product
Status 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:

TM
• 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
type A
Services Verify Customer Verify Product
product
Status Status
Stores
Verify Product Verify Stock Status
Status
type B product
Production
Verify Product
type C 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.

TM
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

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Process Modelling Extract V2

Uploaded by

Copyright:

Available Formats

IMMTM

Copyright © John Owens 2009

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

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.1 Getting Started 11

6.3 B u ilding the Diagram 15

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

7.2 S i m ple Process Flows 19

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.8 More Complex Process Flows 30

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

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

9.6 Errors Using Swim Lanes 47

10 DETAIL FOR PROCESS ELEMENTS 48

10.2 Process Step (Function) 49

10.3 Outcome (Preferred) 49

10.4 Outcome (Non-Preferred) 50

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 on Data Flow 54

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.1 Effectiveness and Efficiency 60

13.2 R a n k ing Non-Preferred Outcomes 61

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

14 A D D I NG FUNCTIONS TO THE FUNCTION CATALOGUE

14.1 Adding Functions 64

14.2 R e p l a c ing Functions 64

15 LEVELS OF PROCESS MODEL 68

15.1 C o n v entional Approach 68

15.3 The ‘Replace’ Concept 70

15.4 No Such Thing as a High Level Process 71

16 B U S I N ESS PROCEDURE & WORKFLOW 7 2

17 USING CASE TOOLS 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