Process

Modeling
best practices
Process Modeling – best practices

© Jean Vercruysse. All rights reserved.

This free guide is reserved for newsletter subscribers.

Do you want to recommend it? Forward
the URL below. Thank you!

www.effic.be

2
Process Modeling – best practices

Table of contents

Introduction 4
Process mapping 5
Analysis of the organisation and its environment 5
1. Organisational goals 5
2. Business environment 5
3. Stakeholders 6
4. Organisation structure 7
5. Resources / Assets 7
6. Process map or value chain 8
Process modeling 10
Modeling notations 10
Activity diagrams (UML) 10
EPC (Event-driven Process Chain) 10
BPMN (Business Process Model and Notation) 10
Process modeling best practices 11
Modeling approaches 12
Interviews and workshops 15
Process discovery with process mining 17

3
Process Modeling – best practices

Introduction
The aim of this document is to guide you on
how to start applying BPM (Business Process
Management).

Indeed, one of the first and most important

steps in a BPM journey is to map the
overview of the many business processes of
your organisation as they are (called “as-is”).
Modeling these as-is processes serves many
valuable purposes, as described in Effic’s blog “9 reasons to model your
business processes”.

This document does not describe how to improve the business

processes, like BPR (Business Process Re-engineering - or Redesign),
resulting in the “to-be” processes. It does not prescribe a specific
modeling notation (like BPMN) or convention either.

For specific know-how on BPR, continuous process improvement, specific

modeling notations, company modeling conventions, or any other BPM
activity, feel free to contact us.

As you will notice here below, we distinguish process mapping, which is

obtaining an overall - say high-level - view of all processes of an
organisation, from process modeling, that aims at describing each of
these processes individually in more details.

4
Process Modeling – best practices

Process mapping
The aim of process mapping is to obtain an overview of all business
processes within the organisation, resulting in - one or several1 - value
chain(s).

Analysis of the organisation and its environment

To obtain an overview of all the existing business processes, it is
advisable to analyse the business environment first. Though there is not
only 1 method, following approach has proved successful based on our
broad experience. Determine respectively the:

1. Organisational goals
Processes serve the realisation of the organisation’s goals and objectives.
Hence, if Mission, Vision, organisational Objectives and Strategy are
clearly defined and up-to-date, this will certainly help. If (one of) those
have to be elucidated or to be updated, then it is highly recommended to
do this first.

Should you not know how to start with, feel free to contact Effic for this
purpose.

2. Business environment
Given the fact that a process’ primary purpose is to deliver output to
customers (even if these are citizens or other stakeholders), an

1
The number of value chains usually depends on the number of entities, e.g.
“business units”, subsidiaries, etc.

5
Process Modeling – best practices

understanding of the market, market segments and the products &

services is essential.

Consumer  market   Midsized  companies   Large  companies  

 
Gas   variant  1   variant  3   variant  5  

Power   variant  2   variant  4   variant  6  

This ideally results in a so called “product-market-combination” matrix.

This is a table with product or services on the one axis and the markets or
market segments on the other. Indeed, each product-market combination
may lead to a specific process variant, like illustrated here above for an
energy distribution company.

An even more in depth analysis of the market dynamics, like Porter’s 5

forces may be useful for an even better understanding, but is not
mandatory.

3. Stakeholders
The overall stakeholders and their respective stakes should be defined,
as these will need to be identified for each individual process anyway
(see further). A distinction should be made between:

Internal  stakeholders  
like shareholders, boards, employees,... which most probably intervene
during the process execution.

6
Process Modeling – best practices

External  stakeholders    
like suppliers, governmental instances, clients,... which either impact or
are impacted by the business processes.

The schema below is useful to identify the many stakeholders:

Governmental authorities Society

Market environment

Own organisation
Supplying Buying
organisations organisations
Involved departments

Process external Internal Internal Process external

supplier supplier Process customer customer

4. Organisation structure
At least a basic description of how the organisation is divided in functional
domains - better known as an organisation chart - will help to have a
better understanding of how processes flow through which “parts” of the
organisation and how - roughly - the bulk of work is organised.

5. Resources / Assets
An overview of the main resources or assets that are used to execute the
processes, like for instance (this list is however not exhaustive)

★ human resources
★ (core and other) competences and knowledge
★ materials: raw and auxiliary materials, main semi-finished products,...

7
Process Modeling – best practices

★ machines and specific tools

★ (specific) methods and procedures
★ information on its own as well as information management systems
★ capital & financial means

6. Process map or value chain

After exploring all these organisational elements, one should now be able
to draw a process map or the value chain. This should contain and
distinguish following types of processes:

A.  Primary  or  core  processes  

These are the processes which directly deliver output (i.e. products or
services) and value to customers.

B.  Support  processes  
These processes do not deliver output directly to customers, but ‘support’
the primary or core processes.

C.  Management  processes  
Such processes control the correct execution of the primary and the
supporting processes.

A ‘traditional’ value chain looks as follows:

8
Process Modeling – best practices

Be aware that an organisation may have several value chains. Even a

medium business may distinguish business units (like for example
manufacturing, wholesale and retail activities), resulting in quite different
value chains.

9
Process Modeling – best practices

Process modeling
Once you have mapped all the business processes in one - or several -
map(s) or value chain(s), the main work still has to start: modeling the
many individual processes.

Modeling notations
There are many modeling notations to describe a process visually.
However, we limit the enumeration to only those mainly used nowadays.

Activity diagrams (UML)

These are the well-known ‘flow-charts’, illustrated by rounded rectangles
and so-called diamonds. See also en.wikipedia.org/wiki/Activity_diagram.
Though this kind of charts may still be used in practice, their use is not
very recommended given their rather poor “semantic value”.

EPC (Event-driven Process Chain)

EPC diagrams were very common within ERP - more particularly SAP -
projects. Though these are still often used in tools like ARIS, which used
to have an historical relation with SAP, their importance decreased since
the upswing of BPMN as a standard. For more on EPC, see also
en.wikipedia.org/wiki/Event-driven_process_chain.

BPMN (Business Process Model and Notation)

This notation - owned and managed by OMG, a not-for-profit technology
standards consortium - really has become the standard for business

10
Process Modeling – best practices

process modeling. For any documentation and specification on BPMN,

see the corresponding OMG site: http://www.omg.org/bpmn/index.htm.

Another reason to recommend the BPMN notation is that processes

modeled with BPMN 2.0 may produce executable code. Several BPMS
(Business Process Management Suites) platforms enable the
implementation of a process from the BPMN model, indeed. While
previous BPMN models first needed to be ‘translated’ to BPEL (Business
Process Execution Language).

Process modeling best practices

Notice that regardless of the modeling notation, a process is always - by
definition - a series of ‘activities’ or ‘tasks’. According to best practices,
these activities should at least:

• start with a verb, ideally followed by the corresponding ‘direct object’;

ex. “write the manual”.
• be “atomic”, meaning that an activity should represent only 1 unit of
o work: if you need more than 1 verb, it is not atomic
o time: an activity executed with a considerable interval in
between is most probably not atomic
o capacity: an activity executed by 2 different persons or 2
different machines is usually not atomic
o location: an activity executed at 2 different locations is probably
not atomic either
Example: if you name a task “write and print the manual” it can hardly
be atomic because it is more than 1 verb, it may occur at different

11
Process Modeling – best practices

times, at different locations and it can even be carried out by different

persons (i.e. the one writing it, the other printing it).
• describe what should be done, but not how. Indeed, an activity should
not be confused with a procedure. The activity indicates what should
be done, while the procedure explicits how the activity should be
done.
Example: for an activity “Take a back-up of the database” (i.e. what
should happen), you may need to follow a complete procedure (how it
should be executed). Possibly documented by a manual describing
how to take the back-up in the system, including screenshots
expliciting which menus to be used.

With regards to the specific notation used, it is obvious that the process
model should be sound and semantically correct (i.e. fully according to
the notation rules).

It is however not the purpose of this document to explain the semantic of

the (many) notations. For the BPMN notation, see the link mentioned in
the respective paragraph here above. Or do not hesitate to contact us to
learn how to model with BPMN.

Modeling approaches
Before describing approaches, let us first enumerate most important
elements which should be identified either during, or ideally (just) before
starting modeling. These elements are sometimes grouped in a graph
called “Turtle diagram”.

12
Process Modeling – best practices

• Process trigger(s): what will actually trigger the process to start its
execution? In BPMN terms, this is the “start event”.
• End state of the process: indicates when a process finishes its
execution. In BPMN terms, this is called the “end event”.
• Process input(s): what will be the input(s) which will be transformed
during the process?
• Process output(s): what will be produced at the end of the process
execution? Notice that trigger and start event, versus end state and
end event may be the same, but could be different as well. When the

13
Process Modeling – best practices

trigger is a “time trigger” for instance, you still may need an input as
well.
• Process objective(s): though one may think this is the same as process
output(s), it is not. Even more: an output may even not respond to the
objective.
For example: the development of a (software) application should
suppose to make a process even more efficient. However, even
though the application is developed according to requirements, the
output may be OK, while the objective is not achieved because the
requirement were not correctly defined (cause these do actually not
enable the process to be more efficient).
• Process stakeholders: who are the specific stakeholders for this
process? Ideally, you also describe their respective stakes. Also notice
that specific stakes may be conflicting with the overall organisational
stakes.
For example: employees may prefer to keep an activity being
executed manually because of ‘job protection’ reasons, while this has
a negative impact on the productivity of the process and thus of the
overall organisation’s performance.
• Business rules: does the process contain (specific) business rules?
Particularly when it contains rather complex rules, it is better to keep
these out of the process itself; for instance by means of decision tables
- or in more elaborated tools like Business Rule Management Systems,
when available.
• Actors or participants: although these may be considered as
“stakeholders”, you can better distinguish them. Moreover, actors may
also be categorised in their role through the RACI (Responsible,
Accountable, to be Consulted, to be Informed) principle. This may even

14
Process Modeling – best practices

be assigned at the activity level. Notice that so called swim lanes in

process diagrams only indicate who executes (carries out) the activity;
not who is responsible.
• Means: machines, systems, resources, methods, materials, etc. used
for the process. Those may be identified at the more detailed activity
level, later (during or even after the basic process modeling) to enrich
the process model even further.
• Locations: particularly when an organisation has many locations
(subsidiaries, sites,...), it may also be important to specify where the
process or its activities take place.

Interviews and workshops

Interviews  versus  workshops?  

The more traditional way of obtaining the information needed to model
the processes is by interviewing the actors, possibly also external
stakeholders.

However, interviews with

individual persons is often
less effective and less
efficient than organising a
workshop with all process
actors together.

Indeed, as modeling is
often a ‘subjective’

15
Process Modeling – best practices

representation of the reality, having all actors together somehow forces

the participants to agree on the modeling results.

On the other hand, the modeler may become the “plaything” of divergent
views on the process. Hence, our recommendation is to work through
workshops rather than by individual interviews whenever possible.

Brown  paper  sessions  versus  modeling  directly  in  tools  

Though modeling right away in the modeling software during the
workshop may seem to be more efficient for following reasons:

★ the modeler does not have to model the processes after the workshop
★ participants instantly see the modeling result according to the
modeling notation, and this may help to avoid later meetings to agree on
the final model.

There are also disadvantages to this ‘direct approach’:

• the modeler has to focus on the correct semantic of the tool, and loses
some attention on what is being told by the participants
• while the modeler is spending time and focus on modeling in the tool
(which often takes more time than sticking a post-it note on a brown
paper), the participants tempt to lose their attention; particularly when
smartphones or similar devices (laptops, tablets) are allowed during the
workshop.

Don’t hesitate to contact us for more information on how to prepare and

how to lead modeling workshops even more successfully.

16
Process Modeling – best practices

Process discovery with process mining

A more recent way of modeling business processes is with the aid of
process mining. Let us first explain what process mining is.

Process  mining  and  process  discovery  in  a  nutshell  

Process mining is a process management technique that allows for the
analysis of business processes based on event logs. The basic idea is to
extract knowledge from event logs recorded by an information system.

Process discovery allows to reconstruct process models automatically

and quite objectively (i.e. based on how the processes have really been
executed in the past).

Advantages  of  discovery  by  process  mining              

According to a survey by J. Claes and G. Poels, the main benefits of
process mining, related to discovery are:

• objectivity: fact-based and ‘facts never lie’

• speed and efficiency: once the event logs are available, it is only a
matter of applying the correct algorithm(s)
• completeness: process discovery algorithms enables to see any
process variants and exceptions, which may be even unknown by
actors during a workshop
• transparency: a process discovered by means of process mining also
provides lots of valuable side information like times of execution of
activities, overall process throughput times, how many cases followed
which process path, etc.

17
Process Modeling – best practices

Challenges  of  process  mining  

Process mining is unfortunately only possible when event logs are
available. Hence, these are the main challenges:

★ data access: even when sure that event logs exist, one should know
how to access and extract these from information systems
★ data preparation: event logs are seldom ‘ready for use’, i.e. these

may be spread over different systems, as business processes often are

supported by several applications.
★ data quality: before claiming that the process obtained thanks to
discovery through process mining, one should make sure that the data
are reliable.

When event logs are quite easily obtainable and reliable, it is

recommended to use process discovery algorithms to model the “as-is”
business processes. Even though you better discuss these diagrams
obtained through process mining with the persons you would interview
anyway. A concluding workshop may still be desirable to make sure that
everybody is on the same page.

18
Process Modeling – best practices

Feel also free to contact us for more information on how to use process
mining (for process discovery, and for process improvement as well).

Or any further question about BPM, Operational Excellence, Lean

management, Six Sigma, Lean innovation, etc. ? Drop your questions
through e-mail [email protected] or via the Effic contact page and we will
come back to you quickly.

19
 and now…
it’s up to you!

Questions and feedback are welcome.