Process Modeling e-book - Effic

Process Modeling

best practices

Process Modeling – best practices

2

© 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


3

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


4

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.


5

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.


6

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.


7

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

Supplying organisations

Own organisation Buying

organisations Involved departments

Process external supplier

Internal supplier Process Internal

customer Process external

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


8

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


9

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.


10

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


11

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


12

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


13

• 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


14

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


15

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’


16

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.


17

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.


18

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.


19

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.

Questions and feedback are welcome.

and now… it’s up to you!

Process Modeling e-book - Effic

Documents

Transcript of Process Modeling e-book - Effic