Guidance Note on Business Process Modelling Using BPMN v1p1 15-JULY

8/2/2019 Guidance Note on Business Process Modelling Using BPMN v1p1 15-JULY

1/39

Guidance Note on Business Process Modelling using BPMNVersion: 1p1| Issue date: 15-JULY-2010 | Status: DRAFT

1

Guidance Note on Business Process

Modelling using BPMN

Contents

Guidance Note on Business Process Modelling using BPMN ................................................... 1

Foreword ................................................................................................................................ 3

What is a "Process", anyway? ................................................................................................ 4

Reason for modelling ............................................................................................................. 4

What type of model to create? ............................................................................................ 5

Before starting the modelling activity ................................................................................ 5

Levels of modelling ................................................................................................................ 6

1) Illustrative modelsLevel Zero .............................................................................. 6

2) High level modelsFirst level / Level One ............................................................ 6

3) User requirements modelsSecond level / Level Two........................................... 7

4) Functional Specifications modelsThird level / Level Three ................................ 8

Responsibilities of participants .............................................................................................. 8

1) Responsibilities of the PROCESS OWNER ............................................................ 8

2) Responsibilities of the CLIENT / SME ................................................................... 9

3) Responsibilities of the MODELLER ....................................................................... 9

4) A typical example of the participants ...................................................................... 9

Result patterns ...................................................................................................................... 10

1) Balanced pattern ..................................................................................................... 10

2) Imbalanced pattern ................................................................................................. 10

3) Broken flow pattern ............................................................................................... 11

4) Broken process pattern ........................................................................................... 12

Who is doing the modelling? ............................................................................................... 13

1) Process Owner (client / SME) ................................................................................ 13

2) Active modeller (a-modeller) ................................................................................. 14

3) Backup modeller (b-modeller) ............................................................................... 14

4) Modelling coordination and tracking ..................................................................... 14

General Method of modelling .............................................................................................. 16

1) Kick-off / Set up ..................................................................................................... 16

2) Modelling and review ............................................................................................ 21

3) Acceptance ............................................................................................................. 24

Accelerated Method of modelling ........................................................................................ 25

Maturity of models ............................................................................................................... 25


2/39


2

Alignment of methodology .................................................................................................. 26

Referencing models .............................................................................................................. 26

Frequently used BPMN elements in modelling ................................................................... 28

1) Swimlanes .............................................................................................................. 29

2) Gateways ................................................................................................................ 29

3) Activities ................................................................................................................ 32

4) Events ..................................................................................................................... 34

5) Interrupting, border events ..................................................................................... 36

6) Flow objects ........................................................................................................... 36

7) Artefacts ................................................................................................................. 36

8) Other elements (non-BPMN) ................................................................................. 37

Summary in 10 lines ............................................................................................................. 39

Recommended reading material ............................................................................................... 39

Motto:

(George Edward Pelham BOX)


3/39


3

ForewordThere is a lot to read on business process modelling, this document is intended only to give a

brief summary of a possible methodology on how a business process modelling exercise can

be successfully implemented using Business Process Modelling (and) Notation (BPMN) byOMG.

Just to set things right: BPMN is not a mere collection of symbols, in that case the

specifications1

by the Object Management Group (OMG2) would be only a two page

document, but it is 316 pages.

So BPMN is better to be considered as a standardized set of rules, as the specifications define:

"The primary goal of BPMN is to provide a notation that is readily understandable by allbusiness users, from the business analysts that create the initial drafts of the processes,to the technical developers responsible for implementing the technology that will performthose processes, and finally, to the business people who will manage and monitor those

processes. Thus, BPMN creates a standardized bridge for the gap between the businessprocess design and process implementation".

In case you wish to start drawing your own models it is strongly advised to read the BPMN

specifications if not the whole of the specs, but at least from page 1 to page 141. In case you

wish to read something less technical you will find a list of recommended reading materials at

the end.

Currently the BPMN 1.2 specification is used but BPMN 2.0 is on its way, the final version of

the specification is expected to be adopted in mid 2010 (more info:http://goo.gl/Jrki).

This document intends to summarize the possibilities for the creation of a business process

model and it is believed that the methodology described can be used in the creation of the

models for describe high level processes, but also for User Requirements and FunctionalSystems Specifications (in case of IT development need).

Please be aware that the intended readership is not limited to modellers only, Process Owners

are also strongly advised to consult this document before engaging in modelling activities.

Please share your opinion(s), comment(s) with the DG TAXUD A13

in order to allow the

enhancement of this document.

1http://www.omg.org/spec/BPMN/1.2/2 Founded in 1989, the Object Management Group, Inc. (OMG) is an open membership, not-for-profit computer

industry standards consortium that produces and maintains computer industry specifications for interoperable,

portable and reusable enterprise applications in distributed, heterogeneous environments. Membership includes

Information Technology vendors, end users, government agencies and academia. OMG member companieswrite, adopt, and maintain its specifications following a mature, open process. OMG's specifications implement

the Model Driven Architecture (MDA), maximizing ROI through a full-lifecycle approach to enterprise

integration that covers multiple operating systems, programming languages, middleware and networking

infrastructures, and software development environments. OMG's specifications include: UML (Unified

Modeling Language); CORBA (Common Object Request Broker Architecture); CWM (Common

Warehouse Metamodel); and industry-specific standards for dozens of vertical markets. More information on theOMG is available athttp://www.omg.org/.3

Email: [email protected]
http://goo.gl/Jrkihttp://goo.gl/Jrkihttp://goo.gl/Jrkihttp://www.omg.org/spec/BPMN/1.2/http://www.omg.org/spec/BPMN/1.2/http://www.omg.org/spec/BPMN/1.2/http://www.omg.org/http://www.omg.org/http://www.omg.org/http://www.omg.org/http://www.omg.org/spec/BPMN/1.2/http://goo.gl/Jrki


4/39


4

What is a "Process", anyway?Yes, this is the most important question of modelling, or even before starting any activity.

According to the definition given by BusinessDictionary.com4: "Sequence of interdependent

and linked procedures which, at every stage, consume one or more resources (employeetime, energy, machines, money) to convert inputs (data, material, parts, etc.) intooutputs. These outputs then serve as inputs for the next stage until a known goal or end

result is reached."

According to the BPMM5

specification by OMG: "A set of tasks or activities performed to

achieve a given purpose or a specified result".

Modifying a bit the definition given by CHANG6, the most precise definition is the following:

A PROCESS is

a coordinated and standardised

flow of activities

performed by people or machines (including IT applications / software tools), which

traverse functional or organisational boundaries

to achieve a business objective that

creates value for

internal or external actors.

This definition is quite well applicable to the processes based on (initiated by) the customs

legislation or any legislative text. It is very important to mention that a process should be

defined and re-usable, which means the following:

the process results always the same, in the sense that the inputs, the outputs and theirpossible dependencies are defined

the process can be activated (used / instantiated) more than just one time (depending on theavailability and/or quality of inputs)

the process is available for re-use, depending on the rules more than one type of input mayactivate (use / instantiate) a process

Reason for modellingOf course there must be a reason for modelling and it can not be the modelling itself.

A Business Process Model diagram is a tool a means to an end, not a performance outcome

in its own right. The final output should be improvement in the value that the business

process creates. Thus, taking into account the definition above, the reason for modelling shall

always be the improvement of value creation. This improvement can be reached

improve coordination / standardisation through better understanding and/or simplerprocesses

improve performance of actors (people or machines) in the process through reducing thedistance and/or the number of steps in a process

4http://www.businessdictionary.com/definition/process.html5

BPMM = Business Process Maturity Model (v1.0) by OMG (http://www.omg.org/spec/BPMM/1.0/PDF/)6

[1] p.
http://www.businessdictionary.com/definition/process.htmlhttp://www.businessdictionary.com/definition/process.htmlhttp://www.businessdictionary.com/definition/process.htmlhttp://www.omg.org/spec/BPMM/1.0/PDF/http://www.omg.org/spec/BPMM/1.0/PDF/http://www.omg.org/spec/BPMM/1.0/PDF/http://www.omg.org/spec/BPMM/1.0/PDF/http://www.businessdictionary.com/definition/process.html


5/39


5

improve the performance ability of participants (actors) involved in the process throughenhancements / simplifications / upgrades

improve the recognition of value created in the process through showing the importantcomponents of success

What type of model to create?

There are two main different types of Business Process Models:

the 'AS IS' or baseline model (the current situation)

the 'TO BE' model (the intended new situation)

which are used to analyse, test, implement and thus improve the process.

The aim of modelling is to illustrate a complete process, enabling owners, managers,

consultants and staff to improve the flow and streamline the process.

It is highly recommended to create the "as-is" and "to-be" models during the modelling, but it

is not necessary by all means. Sometimes the "to-be" model proves to be enough to change a

process towards improvement.

Before starting the modelling activity

Before committing lots of resources to Business Process Modelling proper consideration

should be given to the usefulness and focus of the exercise - ask the questions:

Does the modelling have the potential to produce gains that will justify the time and effort?

Will the modelling be structured so that people will understand the outputs (not too big andcomplex as to be self-defeating)?

Do people understand why we are doing it, and "what's in it for them"?

Is the modelling activity planned all stakeholders are aware of their responsibilities anddeadlines?

As with other management tools, there is no point producing a fantastically complex model

that no-one can understand or use, just as it is a bit daft to spend hundreds of hours analysing

anything which is of relatively minor significance.

Business Process Modelling is a powerful methodology when directed towards operations

which can benefit from improvement, and when people involved are on-board and supportive.

As regarding failure sorry to say but that is very likely. According to recent (but not

necessarily representative) survey results7

the top 3 change killers are:

1. Poor leadership

2. Contentment with status quo

3. Fear of the new/unknown.

So, the advice is to be prepared to avoid the above three .

7http://pradeephenry.blogspot.com/2010/02/top-3-change-killers-results-from-my.html- Mr. Henry asked "Who

(in your experience) are the Top Three killers of Change?" at 16 LinkedIn groups. (The "who" in the question ismeant to be "what," but Mr. Henry used it like in Ken Blanchard's Who Killed Change?) Nearly 150 people

responded. (date of publication: 15 February 2010)
http://pradeephenry.blogspot.com/2010/02/top-3-change-killers-results-from-my.htmlhttp://pradeephenry.blogspot.com/2010/02/top-3-change-killers-results-from-my.htmlhttp://pradeephenry.blogspot.com/2010/02/top-3-change-killers-results-from-my.htmlhttp://pradeephenry.blogspot.com/2010/02/top-3-change-killers-results-from-my.html


6/39


6

Levels of modelling

It is very important to emphasize: BPMN is independent of any specific process modelling

methodology. The level of modelling is subject to the requirements by / intentions of the

client.

1) Il lustrative models Level ZeroIn many cases the model is not needed for the preparations of an IT development, thus it

serves only illustrative purposes.

In these cases the prepared outcome is still (preferably) a valid BPMN model, but does not

possess all the features of a Level One or more detailed model.

Usually these models are used for presenting legal texts, complex business rules or the

connections between various systems.The purpose of this model level is usually to provide a general overview to the readers /

decision makers.

2) High level models First level / Level OneThe actual intent of a high level model mostly depends on the requirement of the "client",

who might be a "business" partner, or anybody else who wishes to have a "High Level"

model. No "one-size-fits-all" solution exists, but there are some common methods andcommon content which can be identified as summarised below.

According to TEMPO8methodology the high level business model is the first documentthat describes the business process and flow of information for the TES9. This preliminarydocument is user-centric and describes how the different users interact with thesystem10. The High Level Business Model will consider ALL actors involved in the system(Users, Clients, Operation team, Maintenance Team). The purpose of this document is to

explain the complete behaviour of the systems from the end-user point of view.

Input: Business needs.

Output: System-High Level Business Model- (SYS-HBM-)

WARNING! The above definition applicable to those models which end-up in an IT solution

development! In many cases the final goal is not necessarily to develop an IT solution but to

have an overview before deciding on IT development. Thus more than one high level model

could existdepending on the purpose.

8 TEMPO: TAXUD Electronic Management of Projects Online. All references to TEMPO are made to the

March 2009 release. More information:

https://circa.europa.eu/Members/irc/taxud/tempoplus/library?l=/tempo_release_200900&vm=detailed&sb=Title

The document used is the Trans-European Systems Reference Manual (TMP-REF-TES v1p21 of 09/03/2009)

without explicit referencing in the text. http://goo.gl/bnVA9

TES = Trans-European System10 At the opposite, a system centric document would describe how the application reacts on action from the

external users.
https://circa.europa.eu/Members/irc/taxud/tempoplus/library?l=/tempo_release_200900&vm=detailed&sb=Titlehttps://circa.europa.eu/Members/irc/taxud/tempoplus/library?l=/tempo_release_200900&vm=detailed&sb=Titlehttps://circa.europa.eu/Members/irc/taxud/tempoplus/library?l=/tempo_release_200900&vm=detailed&sb=Title


7/39


7

According to the description given by SILVER11

this should be the so called "DESCRIPTIVE

MODELLING" level, which is easy to communicate, the model occasionally ignores BPMN

validation rules. The understanding of the (level 1) model requires understanding offundamental concepts such as pools and lanes, tasks and sub-processes, and sequence

flow, but not the complexities of BPMNs various flow control and event patterns.

The purpose of this model level is to provide a start state for the readiness to development,present the main actors and the most common flows in order to show the complete behaviour

for any given business system.

3) User requirements models Second level / Level Two When decision was taken to start IT development, it is necessary to create the model for user

requirements. In TEMPO the deliverable containing this model is called Business Process

Model and System Requirements, often referenced as SPM&Req.

According to TEMPO: The System Business Process Model describes completely thebusiness process and flow of information for the TES, refining and completing the High

Level Business Model created during the Feasibility Study phase (if this document isproduced, otherwise, the Business Process Model is completely created during this phase)

. The model is still user-centric.

As regarding the System Requirements, it is intended to determine in detail the expectationfrom the TES in terms of:

The users or stakeholders (functional and data requirements);

Performance (response time, expected load, data volume);

Operations (statistical, monitoring and service requirements);

Training (development of the strategy, depending on the type of system);

Testing (development of the strategy to be applied);

Security and data protection;

Communication requirements (system-to-system remote access).

The system requirements are based on the information collected from the BusinessProcess Model and from interviews with representatives of the TES stakeholders.

This level is referenced12

sometimes as "ANALYTICAL MODELLING" where the model is more

detailed (compared to level 1), showing all the steps, including exceptions paths. This level is

required to either to analyze process performance using simulation or to create detailedrequirements for an IT implementation. Level 2 modelling requires understanding ofBPMNs various decision and merge patterns, events, and exception handling patterns.

Level 2 diagrams must be both valid according to the rules in the BPMN specifications,and organized effectively as hierarchical representations of the end to end businessprocess.

The purpose of this model level is to enable the creation of the Functional Specifications

models (Level Three models) through identifying all possible requirements towards the

functioning of a system, without going deeply into the details. It is also important to indicate

links / connections to other systems.

11

Bruce Silver is member of the OMG panel responsible for BPMN. He maintains a very good blog:http://www.brsilver.com12

Description is based on the definition given by Mr. Bruce Silver.
http://www.brsilver.com/http://www.brsilver.com/http://www.brsilver.com/


8/39


8

4) Functional Specifications models Third level / Level Three In TEMPO, this level is referenced as System Functional Specification often abbreviated as

FSS. According to the document The System Functional Specification describes whatthe system has to implement to satisfy the requirements in compliance with the Business

Process Model. It includes: The Functional message specification (the list of messages to be exchanged in the

Common and External domains and the information included in the message);

The Logical Data Model (representation of the data entities, and their attributesand their relationship within the system) (optional);

State Transition Diagrams (the behaviour of the system under given conditions)(optional).

The purpose of these models is to present all the functions of the system together with the data

(and information) requirements including all the possible results. Thus at this phase the

exceptions to the normal functions are to be included too.

Responsibilities of participants

The following figure shows how many things can go wrong if responsibilities are not

addressed properly:

1) Responsibil ities of the PROCESS OWNER The PROCESS OWNER is treated here a bit different from the client, as the client functions

as the representative of the Owner in the sense of responsibilities.The Process Owner should be able to provide the right composition of the process, all process

elements should be included, unnecessary elements should not be included in the process. All

references to the necessary elements should be provided to the client.

Further to the above mentioned the Process Owner is solely responsible for the appointment

of his (hers / theirs) representative who will function as the Client throughout the

modelling exercise. The Process Owner should not just appoint the Client but should also

trust the Client and accept feedback(s).


9/39


9

2) Responsibil ities of the CLIENT / SMEThe CLIENT is the representative of the Owner, he/she is the so called Subject Matter Expert

(SME) throughout the modelling activity thus the Client should be able to understand

(perceive) the process as a whole and in details too, the Client should be able to explain the

process to the Modeller and should be able to understand the model at least to be able tovalidate the model from the process point of view.

Further to the above mentioned the Client should trust the modeller, should not interfere with

modelling at least not in the sense of BPMN application. Please, leave modelling to the

modeller!

It is also very important to be able and ready to provide feedback to the Owner in case of

need.

3) Responsibil ities of the MODELLERThe Modeller is in a relatively easy position compared to the Client as the Modeller should

only model and be able to explain the model to the Client in case of need.

As a prerequisite of the above it is of utmost importance to have necessary and well

developed skill in modelling with BPMN. Intensive and continuous (self-)training is highly

advised to wannabe and practicing BPMN modellers.

It is very important to share and discuss (modelling) issues inside the team of modellers and

involve the b-modeller during the modelling exercise.

4) A typical example of the participantsJust to show very briefly a very typical example which is really an everyday situation:

Process Owner: Customs Code Committee

Client / SME: TAXUD Unit A2

Modellers: TAXUD Unit A1


10/39


10

Result patterns

This section might be a bit technical to some readers but is very important for the

modellers. In case you are not interested in technical matters please jump to the

next section.Independently from the model level, several patterns could be identified, either for the process

as a whole or for just specific parts of the process.

It is very important to underline: in most cases there is no right or wrong model from the

modelling point of view. Regardless of the possible pattern discovered the requirement is

"only" to have a valid model. Valid in the sense of BPMN (more or less valid please see

"High level models" section), but the model shall always be valid in the sense of the process.

It is always upon the client to decide whether the result is aligned with the requirements or

not.

The pattern is not characteristic to individual processes only. Patterns can be discovered in

multi-pool models as well, the pattern recognition can help in identifying the most active(most responsible / crucial) actor in a process.

1) Balanced patternThe pattern is balanced when the different possible paths are more or less containing similarly

detailed flow. It is important to emphasize that in many case no balanced pattern would be

found but that is (preferably) not the mistake of the modeller but the result of the process

structure itself.

It is also important to note that a balanced pattern is not necessarily the desired pattern. Thereare several cases when a balanced pattern shows over-sophisticated solutions, thus the

structure shall be changed in the future 'to-be' models.

The non-balanced patterns are mentioned below.

2) Imbalanced patternWhen any of the possible paths is less defined / detailed a process would look like:


11/39


11

It is quite easy to discover the difference in detail in the case of "BLUE" and "Other than

BLUE" flows.

When the process is directed to the "BLUE" path it is quite well elaborated a lot of activities,

exceptions and even some measuring points are shown. On the other path ("Other than

BLUE") the flow is not detailed at all, no exceptions shown.

From the modelling point of view this model is valid. It is up to the client to decide whether

this is the desired situation or not, whether any changes to be made in the composition of the

model or at other parts. Please refer to the section Responsibilities of participants for more

on possible reasons and remedies.

3) Broken flow patternIt is also possible that a flow is not specified, thus considered as broken:

As it can be seen in the above Figure the "Other than BLUE" path leads to nowhere, has

neither a direct nor an indirect connection to an End event.

This pattern could be a result of many reasons:

- Wrong composition of the process (OWNER)

- Wrong perception of the process (CLIENT)

- Wrong explanation was given to the modeller (CLIENT)

- Wrong understanding of the explanation (MODELLER)

- Wrong modelling by the modeller (MODELLER)

Any of the above can be the cause, but follow-up actions are different, depending on the

participant.

In case the composition of the process is wrong, then the client (Owner) might decide to

change the process itselfbut it is totally up to the client how (if ever). In this case the model

is valid in all senses either in the sense of the process in question or in the sense of BPMN.

In case the result is caused by a client-side reason it is up to the client to alter the cause, i.e.

either enhance the perception of the process or give a better explanation to the modeller.


12/39


12

In case the result is attributed to the modeller then in the first case it is up to the client to try to

make the modeller understand better the explanation but in the second case the modeller

should sort out the wrongs at this point the role of the b-modeller (13

) can be crucial.

4) Broken process patternWhen it is not possible to reach the end through any of the flow the process is to be

considered as broken.

As it can be seen in the above Figure the "Other than BLUE" path and the BLUE path leads

to nowhere, has neither a direct nor an indirect connection to an End event. The End event is

connected to an activity with no start event at all.

This pattern could be a result of many reasons:- Wrong composition of the process (OWNER)

- Wrong perception of the process (CLIENT)

- Wrong explanation was given to the modeller (CLIENT)

- Wrong understanding of the explanation (MODELLER)

- Wrong modelling by the modeller (MODELLER)

Any of the above can be the cause, but follow-up actions are different, depending on the

participant.

In case the composition of the process is wrong, then the client (Owner) might decide to

change the process itselfbut it is totally up to the client how (if ever). In this case the modelis valid in all senses either in the sense of the process in question or in the sense of BPMN.

In case the result is caused by a client-side reason it is up to the client to alter the cause, i.e.

either enhance the perception of the process or give a better explanation to the modeller.

In case the result is attributed to the modeller then in the first case it is up to the client to try to

make the modeller understand better the explanation but in the second case the modeller

should sort out the wrongs at this point the role of the b-modeller can be crucial.

More explanation is available in the section General methodof modelling.

13The role of the "b-modeller" is further explained on page 14.


13/39


13

Who is doing the modelling?

Well, at the first glance one might think it is the modeller who is doing the modelling but I

think it is always the Process Owner who is (or should be) the person controlling all events

and activities. To be more specific: the initiation, the review and the acceptance is the sole

responsibility of the Process Owner, thus I think the most important task in modelling is

attributed to the client. The modeller is doing only the more technical part of the

modelling.

Participants (actors) in modelling:

1) Process Owner (client / SME)According to Wikipedia

14: The process owner is the person who is responsible to designthe processes necessary to achieve the objectives of the business plans that are createdby the Business Leaders. The process owner is responsible for the creation, update andapproval of documents (procedures, work instructions/protocols) to support the process.Many process owners are supported by a process improvement team. The process owneruses this team as a mechanism to help create a high performance process. The processowner is the only person who has authority to make changes in the process and managesthe entire process improvement cycle to ensure performance effectiveness. This person is

the contact person for all information related to the process.

Or a simpler but I think quite fine definition from GAO15

: an individual heldaccountable and responsible for the workings and improvement of one of the

organization's defined processes and its related subprocesses

Or to have an example from Europe16: A Process Owner is a person who has the ultimate

responsibility for the performance of a process in realizing its objectives measured by keyperformance indicators, and has the authority and ability to make necessary changes.To that end, Process Owners are designated the following tasks:

- designing and managing the processes for ensuring compliance with therequirements and achieving objectives;

- drafting, amending and maintaining appropriate documentation for their processes(e.g., procedures, work instructions);

- defining their process objectives (including quality objectives) consistent withstrategic objectives;

- managing risks related to their processes

14Source: http://en.wikipedia.org/wiki/Process_Owner#Process_Owner

15 GAO is The U.S. Government Accountability Office (GAO) is known as "the investigative arm of Congress"

and "the congressional watchdog." GAO supports the US Congress in meeting its constitutional responsibilities

and helps improve the performance and accountability of the federal government.

Source:http://www.gao.gov/special.pubs/bprag/bprgloss.htm#sectP16

Source: European Aviation Safety Agencyhttp://www.easa.europa.eu/ws_prod/g/doc/Agency_Mesures/Agency_Decisions/2009/ED%20Decision%202009

_089_E.pdf
http://en.wikipedia.org/wiki/Process_Owner#Process_Ownerhttp://en.wikipedia.org/wiki/Process_Owner#Process_Ownerhttp://www.gao.gov/special.pubs/bprag/bprgloss.htm#sectPhttp://www.gao.gov/special.pubs/bprag/bprgloss.htm#sectPhttp://www.gao.gov/special.pubs/bprag/bprgloss.htm#sectPhttp://www.easa.europa.eu/ws_prod/g/doc/Agency_Mesures/Agency_Decisions/2009/ED%20Decision%202009_089_E.pdfhttp://www.easa.europa.eu/ws_prod/g/doc/Agency_Mesures/Agency_Decisions/2009/ED%20Decision%202009_089_E.pdfhttp://www.easa.europa.eu/ws_prod/g/doc/Agency_Mesures/Agency_Decisions/2009/ED%20Decision%202009_089_E.pdfhttp://www.easa.europa.eu/ws_prod/g/doc/Agency_Mesures/Agency_Decisions/2009/ED%20Decision%202009_089_E.pdfhttp://www.easa.europa.eu/ws_prod/g/doc/Agency_Mesures/Agency_Decisions/2009/ED%20Decision%202009_089_E.pdfhttp://www.gao.gov/special.pubs/bprag/bprgloss.htm#sectPhttp://en.wikipedia.org/wiki/Process_Owner#Process_Owner


14/39


14

One might argue that the true Process Owner is the Customs Code Committee [CCC] at least

in the field of customs legislation, but it is also possible to consider the representatives of the

DG TAXUD Directorate A and Directorate B as the Process Owners in our case as they are

the one who are in close contact with the CCC, most of the time chairing those meetings,

summarizing MS comments, preparing drafts, etc.

In the below part I am referring to Process Owner (or to the representative of the ProcessOwner) as client as in the course ofmodelling the Process Owner is acting as client to the

services of the modeller(s)but all the time it should be kept clear that the client has a lot of

responsibilities (as detailed above, and discussed below).

2) Active modeller (a-modeller)The active modeller is doing a very simple task: prepares BPMN valid models based on the

inputs received from the client. The interaction between the a-modeller and the client is

described below. The modeller should have firm experience in modelling and it is an asset toknow the general subject in our case the customs legislation. No modeller should be

involved in legal modelling before (at least once or twice) had read the legal provisions

regulating the process in question.

3) Backup modeller (b-modeller)The role of the backup modeller is detailed below. In most cases the b-modeller is in close

interaction with the client, mostly it is involved in the modelling verification, control and

harmonisation.

It is highly possible that in some cases a person is the a-modeller while performing the task of

a b-modeller in other cases. The only (physical and psychological) restriction is that a person

can not be performing a- and b-modeller tasks at the same time for the same modelling

activity.

4) Modelling coordination and trackingThe modelling activity is to be coordinated and tracked by the Unit responsible for the

coordination and validation (in the current structure: this is supposed to be TAXUD

Directorate A Unit A1). This activity is not described (yet) in this document.In general it can be stated that an activity plan and distribution of modelling roles (whether a

modeller is active or backup) is necessary to be developed and updated in all times. The

coordination and tracking is a vital part of successful activities, its important role shall not be

underestimated due to relative invisibility.

It is also necessary to avoid parallel modelling of the same / similar processes which might

happen in case there are more than 4 modellers17

are working in the modelling team. This can

be ensured only through precise and disciplined planning and execution of tasks.

17 In the case of only three or two modellers the occasional parallel activities will be avoided with the proper use

of the b-modeller concept.
http://www.easa.europa.eu/ws_prod/g/doc/Agency_Mesures/Agency_Decisions/2009/ED%20Decision%202009_089_E.pdfhttp://www.easa.europa.eu/ws_prod/g/doc/Agency_Mesures/Agency_Decisions/2009/ED%20Decision%202009_089_E.pdfhttp://www.easa.europa.eu/ws_prod/g/doc/Agency_Mesures/Agency_Decisions/2009/ED%20Decision%202009_089_E.pdfhttp://www.easa.europa.eu/ws_prod/g/doc/Agency_Mesures/Agency_Decisions/2009/ED%20Decision%202009_089_E.pdfhttp://www.easa.europa.eu/ws_prod/g/doc/Agency_Mesures/Agency_Decisions/2009/ED%20Decision%202009_089_E.pdfhttp://www.easa.europa.eu/ws_prod/g/doc/Agency_Mesures/Agency_Decisions/2009/ED%20Decision%202009_089_E.pdfhttp://www.easa.europa.eu/ws_prod/g/doc/Agency_Mesures/Agency_Decisions/2009/ED%20Decision%202009_089_E.pdfhttp://www.easa.europa.eu/ws_prod/g/doc/Agency_Mesures/Agency_Decisions/2009/ED%20Decision%202009_089_E.pdfhttp://www.easa.europa.eu/ws_prod/g/doc/Agency_Mesures/Agency_Decisions/2009/ED%20Decision%202009_089_E.pdfhttp://www.easa.europa.eu/ws_prod/g/doc/Agency_Mesures/Agency_Decisions/2009/ED%20Decision%202009_089_E.pdfhttp://www.easa.europa.eu/ws_prod/g/doc/Agency_Mesures/Agency_Decisions/2009/ED%20Decision%202009_089_E.pdfhttp://www.easa.europa.eu/ws_prod/g/doc/Agency_Mesures/Agency_Decisions/2009/ED%20Decision%202009_089_E.pdfhttp://www.easa.europa.eu/ws_prod/g/doc/Agency_Mesures/Agency_Decisions/2009/ED%20Decision%202009_089_E.pdfhttp://www.easa.europa.eu/ws_prod/g/doc/Agency_Mesures/Agency_Decisions/2009/ED%20Decision%202009_089_E.pdfhttp://www.easa.europa.eu/ws_prod/g/doc/Agency_Mesures/Agency_Decisions/2009/ED%20Decision%202009_089_E.pdfhttp://www.easa.europa.eu/ws_prod/g/doc/Agency_Mesures/Agency_Decisions/2009/ED%20Decision%202009_089_E.pdfhttp://www.easa.europa.eu/ws_prod/g/doc/Agency_Mesures/Agency_Decisions/2009/ED%20Decision%202009_089_E.pdfhttp://www.easa.europa.eu/ws_prod/g/doc/Agency_Mesures/Agency_Decisions/2009/ED%20Decision%202009_089_E.pdfhttp://www.easa.europa.eu/ws_prod/g/doc/Agency_Mesures/Agency_Decisions/2009/ED%20Decision%202009_089_E.pdfhttp://www.easa.europa.eu/ws_prod/g/doc/Agency_Mesures/Agency_Decisions/2009/ED%20Decision%202009_089_E.pdfhttp://www.easa.europa.eu/ws_prod/g/doc/Agency_Mesures/Agency_Decisions/2009/ED%20Decision%202009_089_E.pdfhttp://www.easa.europa.eu/ws_prod/g/doc/Agency_Mesures/Agency_Decisions/2009/ED%20Decision%202009_089_E.pdfhttp://www.easa.europa.eu/ws_prod/g/doc/Agency_Mesures/Agency_Decisions/2009/ED%20Decision%202009_089_E.pdfhttp://www.easa.europa.eu/ws_prod/g/doc/Agency_Mesures/Agency_Decisions/2009/ED%20Decision%202009_089_E.pdfhttp://www.easa.europa.eu/ws_prod/g/doc/Agency_Mesures/Agency_Decisions/2009/ED%20Decision%202009_089_E.pdfhttp://www.easa.europa.eu/ws_prod/g/doc/Agency_Mesures/Agency_Decisions/2009/ED%20Decision%202009_089_E.pdfhttp://www.easa.europa.eu/ws_prod/g/doc/Agency_Mesures/Agency_Decisions/2009/ED%20Decision%202009_089_E.pdfhttp://www.easa.europa.eu/ws_prod/g/doc/Agency_Mesures/Agency_Decisions/2009/ED%20Decision%202009_089_E.pdfhttp://www.easa.europa.eu/ws_prod/g/doc/Agency_Mesures/Agency_Decisions/2009/ED%20Decision%202009_089_E.pdfhttp://www.easa.europa.eu/ws_prod/g/doc/Agency_Mesures/Agency_Decisions/2009/ED%20Decision%202009_089_E.pdfhttp://www.easa.europa.eu/ws_prod/g/doc/Agency_Mesures/Agency_Decisions/2009/ED%20Decision%202009_089_E.pdfhttp://www.easa.europa.eu/ws_prod/g/doc/Agency_Mesures/Agency_Decisions/2009/ED%20Decision%202009_089_E.pdfhttp://www.easa.europa.eu/ws_prod/g/doc/Agency_Mesures/Agency_Decisions/2009/ED%20Decision%202009_089_E.pdfhttp://www.easa.europa.eu/ws_prod/g/doc/Agency_Mesures/Agency_Decisions/2009/ED%20Decision%202009_089_E.pdfhttp://www.easa.europa.eu/ws_prod/g/doc/Agency_Mesures/Agency_Decisions/2009/ED%20Decision%202009_089_E.pdfhttp://www.easa.europa.eu/ws_prod/g/doc/Agency_Mesures/Agency_Decisions/2009/ED%20Decision%202009_089_E.pdfhttp://www.easa.europa.eu/ws_prod/g/doc/Agency_Mesures/Agency_Decisions/2009/ED%20Decision%202009_089_E.pdfhttp://www.easa.europa.eu/ws_prod/g/doc/Agency_Mesures/Agency_Decisions/2009/ED%20Decision%202009_089_E.pdfhttp://www.easa.europa.eu/ws_prod/g/doc/Agency_Mesures/Agency_Decisions/2009/ED%20Decision%202009_089_E.pdfhttp://www.easa.europa.eu/ws_prod/g/doc/Agency_Mesures/Agency_Decisions/2009/ED%20Decision%202009_089_E.pdfhttp://www.easa.europa.eu/ws_prod/g/doc/Agency_Mesures/Agency_Decisions/2009/ED%20Decision%202009_089_E.pdfhttp://www.easa.europa.eu/ws_prod/g/doc/Agency_Mesures/Agency_Decisions/2009/ED%20Decision%202009_089_E.pdfhttp://www.easa.europa.eu/ws_prod/g/doc/Agency_Mesures/Agency_Decisions/2009/ED%20Decision%202009_089_E.pdfhttp://www.easa.europa.eu/ws_prod/g/doc/Agency_Mesures/Agency_Decisions/2009/ED%20Decision%202009_089_E.pdfhttp://www.easa.europa.eu/ws_prod/g/doc/Agency_Mesures/Agency_Decisions/2009/ED%20Decision%202009_089_E.pdfhttp://www.easa.europa.eu/ws_prod/g/doc/Agency_Mesures/Agency_Decisions/2009/ED%20Decision%202009_089_E.pdfhttp://www.easa.europa.eu/ws_prod/g/doc/Agency_Mesures/Agency_Decisions/2009/ED%20Decision%202009_089_E.pdfhttp://www.easa.europa.eu/ws_prod/g/doc/Agency_Mesures/Agency_Decisions/2009/ED%20Decision%202009_089_E.pdfhttp://www.easa.europa.eu/ws_prod/g/doc/Agency_Mesures/Agency_Decisions/2009/ED%20Decision%202009_089_E.pdfhttp://www.easa.europa.eu/ws_prod/g/doc/Agency_Mesures/Agency_Decisions/2009/ED%20Decision%202009_089_E.pdfhttp://www.easa.europa.eu/ws_prod/g/doc/Agency_Mesures/Agency_Decisions/2009/ED%20Decision%202009_089_E.pdfhttp://www.easa.europa.eu/ws_prod/g/doc/Agency_Mesures/Agency_Decisions/2009/ED%20Decision%202009_089_E.pdfhttp://www.easa.europa.eu/ws_prod/g/doc/Agency_Mesures/Agency_Decisions/2009/ED%20Decision%202009_089_E.pdfhttp://www.easa.europa.eu/ws_prod/g/doc/Agency_Mesures/Agency_Decisions/2009/ED%20Decision%202009_089_E.pdfhttp://www.easa.europa.eu/ws_prod/g/doc/Agency_Mesures/Agency_Decisions/2009/ED%20Decision%202009_089_E.pdfhttp://www.easa.europa.eu/ws_prod/g/doc/Agency_Mesures/Agency_Decisions/2009/ED%20Decision%202009_089_E.pdfhttp://www.easa.europa.eu/ws_prod/g/doc/Agency_Mesures/Agency_Decisions/2009/ED%20Decision%202009_089_E.pdfhttp://www.easa.europa.eu/ws_prod/g/doc/Agency_Mesures/Agency_Decisions/2009/ED%20Decision%202009_089_E.pdfhttp://www.easa.europa.eu/ws_prod/g/doc/Agency_Mesures/Agency_Decisions/2009/ED%20Decision%202009_089_E.pdfhttp://www.easa.europa.eu/ws_prod/g/doc/Agency_Mesures/Agency_Decisions/2009/ED%20Decision%202009_089_E.pdfhttp://www.easa.europa.eu/ws_prod/g/doc/Agency_Mesures/Agency_Decisions/2009/ED%20Decision%202009_089_E.pdf


15/39


15

Please take a look at the following figure which makes it easier to understand why

coordination needed.

It can be seen that when the number of modellers is 4 the "distance" between modellers are

increased and with the introduction of a "Coordinator" in the middle the sharing of

information and the harmonisation of modelling can be ensured.

The need for coordination is even more obvious when there are 5 (or more) modellers:

Continuous line represents A-B modeller relation(s) while dotted line represents Modeller-

Coordinator relations.
http://www.easa.europa.eu/ws_prod/g/doc/Agency_Mesures/Agency_Decisions/2009/ED%20Decision%202009_089_E.pdfhttp://www.easa.europa.eu/ws_prod/g/doc/Agency_Mesures/Agency_Decisions/2009/ED%20Decision%202009_089_E.pdfhttp://www.easa.europa.eu/ws_prod/g/doc/Agency_Mesures/Agency_Decisions/2009/ED%20Decision%202009_089_E.pdfhttp://www.easa.europa.eu/ws_prod/g/doc/Agency_Mesures/Agency_Decisions/2009/ED%20Decision%202009_089_E.pdfhttp://www.easa.europa.eu/ws_prod/g/doc/Agency_Mesures/Agency_Decisions/2009/ED%20Decision%202009_089_E.pdfhttp://www.easa.europa.eu/ws_prod/g/doc/Agency_Mesures/Agency_Decisions/2009/ED%20Decision%202009_089_E.pdfhttp://www.easa.europa.eu/ws_prod/g/doc/Agency_Mesures/Agency_Decisions/2009/ED%20Decision%202009_089_E.pdfhttp://www.easa.europa.eu/ws_prod/g/doc/Agency_Mesures/Agency_Decisions/2009/ED%20Decision%202009_089_E.pdfhttp://www.easa.europa.eu/ws_prod/g/doc/Agency_Mesures/Agency_Decisions/2009/ED%20Decision%202009_089_E.pdfhttp://www.easa.europa.eu/ws_prod/g/doc/Agency_Mesures/Agency_Decisions/2009/ED%20Decision%202009_089_E.pdfhttp://www.easa.europa.eu/ws_prod/g/doc/Agency_Mesures/Agency_Decisions/2009/ED%20Decision%202009_089_E.pdfhttp://www.easa.europa.eu/ws_prod/g/doc/Agency_Mesures/Agency_Decisions/2009/ED%20Decision%202009_089_E.pdfhttp://www.easa.europa.eu/ws_prod/g/doc/Agency_Mesures/Agency_Decisions/2009/ED%20Decision%202009_089_E.pdfhttp://www.easa.europa.eu/ws_prod/g/doc/Agency_Mesures/Agency_Decisions/2009/ED%20Decision%202009_089_E.pdfhttp://www.easa.europa.eu/ws_prod/g/doc/Agency_Mesures/Agency_Decisions/2009/ED%20Decision%202009_089_E.pdfhttp://www.easa.europa.eu/ws_prod/g/doc/Agency_Mesures/Agency_Decisions/2009/ED%20Decision%202009_089_E.pdfhttp://www.easa.europa.eu/ws_prod/g/doc/Agency_Mesures/Agency_Decisions/2009/ED%20Decision%202009_089_E.pdfhttp://www.easa.europa.eu/ws_prod/g/doc/Agency_Mesures/Agency_Decisions/2009/ED%20Decision%202009_089_E.pdf


16/39


16

General Method of modellingThe most important is to have the Process Owner (client) involved. The initiative must come

from the client's side, otherwise according to my experiences the chance of success is

minimal. Well, some mathematical chance still exists, but if the client does not want to have a

model then no drawing will be good / accepted or no response can be expected.As regarding the 3-level approach on preparing / developing IT systems' documentation

which include business process models, please refer to the document "UR and FSS

developments_v1_1.doc" or it's latest version.

Most of the models are possible to be created in three phases with the client, which are

summarized below.

Figure 1: Phases, Actors and Activities in Modelling

1) Kick-off / Set upThe activities in this phase are described below.

Figure 2: Phase 1 overview

Define scope/process

Actors: CLIENT + MODELLER

In case the extent / scope / domain of the process in question was not specified / defined

earlier then you must start with the scoping in this first session, but be as efficient as possible

try not to waste too much time on discussing interesting cases and rare exceptions.
http://www.easa.europa.eu/ws_prod/g/doc/Agency_Mesures/Agency_Decisions/2009/ED%20Decision%202009_089_E.pdfhttp://www.easa.europa.eu/ws_prod/g/doc/Agency_Mesures/Agency_Decisions/2009/ED%20Decision%202009_089_E.pdfhttp://www.easa.europa.eu/ws_prod/g/doc/Agency_Mesures/Agency_Decisions/2009/ED%20Decision%202009_089_E.pdfhttp://www.easa.europa.eu/ws_prod/g/doc/Agency_Mesures/Agency_Decisions/2009/ED%20Decision%202009_089_E.pdfhttp://www.easa.europa.eu/ws_prod/g/doc/Agency_Mesures/Agency_Decisions/2009/ED%20Decision%202009_089_E.pdfhttp://www.easa.europa.eu/ws_prod/g/doc/Agency_Mesures/Agency_Decisions/2009/ED%20Decision%202009_089_E.pdfhttp://www.easa.europa.eu/ws_prod/g/doc/Agency_Mesures/Agency_Decisions/2009/ED%20Decision%202009_089_E.pdfhttp://www.easa.europa.eu/ws_prod/g/doc/Agency_Mesures/Agency_Decisions/2009/ED%20Decision%202009_089_E.pdfhttp://www.easa.europa.eu/ws_prod/g/doc/Agency_Mesures/Agency_Decisions/2009/ED%20Decision%202009_089_E.pdfhttp://www.easa.europa.eu/ws_prod/g/doc/Agency_Mesures/Agency_Decisions/2009/ED%20Decision%202009_089_E.pdfhttp://www.easa.europa.eu/ws_prod/g/doc/Agency_Mesures/Agency_Decisions/2009/ED%20Decision%202009_089_E.pdfhttp://www.easa.europa.eu/ws_prod/g/doc/Agency_Mesures/Agency_Decisions/2009/ED%20Decision%202009_089_E.pdfhttp://www.easa.europa.eu/ws_prod/g/doc/Agency_Mesures/Agency_Decisions/2009/ED%20Decision%202009_089_E.pdfhttp://www.easa.europa.eu/ws_prod/g/doc/Agency_Mesures/Agency_Decisions/2009/ED%20Decision%202009_089_E.pdfhttp://www.easa.europa.eu/ws_prod/g/doc/Agency_Mesures/Agency_Decisions/2009/ED%20Decision%202009_089_E.pdfhttp://www.easa.europa.eu/ws_prod/g/doc/Agency_Mesures/Agency_Decisions/2009/ED%20Decision%202009_089_E.pdfhttp://www.easa.europa.eu/ws_prod/g/doc/Agency_Mesures/Agency_Decisions/2009/ED%20Decision%202009_089_E.pdfhttp://www.easa.europa.eu/ws_prod/g/doc/Agency_Mesures/Agency_Decisions/2009/ED%20Decision%202009_089_E.pdfhttp://www.easa.europa.eu/ws_prod/g/doc/Agency_Mesures/Agency_Decisions/2009/ED%20Decision%202009_089_E.pdfhttp://www.easa.europa.eu/ws_prod/g/doc/Agency_Mesures/Agency_Decisions/2009/ED%20Decision%202009_089_E.pdfhttp://www.easa.europa.eu/ws_prod/g/doc/Agency_Mesures/Agency_Decisions/2009/ED%20Decision%202009_089_E.pdfhttp://u/Sector%20technical%20development/Modernised%20Customs%20Code/BPMhttp://u/Sector%20technical%20development/Modernised%20Customs%20Code/BPMhttp://u/Sector%20technical%20development/Modernised%20Customs%20Code/BPMhttp://u/Sector%20technical%20development/Modernised%20Customs%20Code/BPMhttp://u/Sector%20technical%20development/Modernised%20Customs%20Code/BPMhttp://u/Sector%20technical%20development/Modernised%20Customs%20Code/BPM


17/39


17

The most probably best practice is to try to work from the top to down in order to not to get

lost with the very details at the beginning. Thus a general, high-level overview can be created.

When the model is about some kind of legal process, it is usually enough to just list the legal

sources and articles in question (corresponding to the general processes), and close the first

sessionsome time is necessary for the client to elaborate the draft mentioned above.

The client should respond to the questions 'what is out of the scope for which a model have to

be created' and identify external stakeholders/processes: to define the borders of your

processes and the stakeholder which provide input or have to be provided with output,

external stakeholders may have to be consulted since they may have an influence on the

requirements.

The client should respond to the questions 'what is in', and identify internal

stakeholders/processes/activities. The internal stakeholders are going to be components/actors

of the process and have requirements.

As regarding a possible scoping approach please

take a look at the following picture:

As it can be seen the scope of the activity is

limited to F1.3, F1.3.1 and F1.3.2 processes only.

All other processes (functions) and actors are to be considered out of scope processes thus no

model is to be created for them.

It is important to mention: even if a process or

actor is considered as out of scope referencing

is very much advised to those as well in case of

need.

There is no real value in the model for the client if definitions are given by the modeller. In

that case the client will very likely will not understand the model at all.


18/39


18

Define timeframe


One of the most important tasks is to agree in the timeframe for the activities and deliverables.

In this document the deliverables mentioned are always models, they are marked with an (*)

in the small table below. It is always good to have a short list with the following (minimum)

elements:

Start of activities [____DATE____]

Overview* delivered by client [____DATE____]

1st

Internal modeller discussion [____DATE____]

Initial model* delivered by modeller [____DATE____]

First review [____DATE____]

2nd

Internal modeller discussion [____DATE____]

Beta-model* delivered by modeller [____DATE____]

Second review [____DATE____]

Final model* delivered by modeller [____DATE____]

Acceptance (end of activities) [____DATE____]

According to some experience the whole activity can fit into 10 consecutive working days18

and it takes approximately 5 man-days for the client, 4 man-days for the a-modeller and 2

man-days for the b-modeller to start and finish the modelling of a (relatively well) defined

process.

Prepare and deliver process overview

Actor: CLIENT

At this session the client is supposed to present it's general requirement, he/she/they is/are

expected to provide the modeller some kind of draft description or map of the process. The

form of that information is absolutely irrelevant, that can be a result of an interview or

responses to a questionnaire (developed by the modeller) or even an excel table (as shown

belowFigure 3) or whatever simple list, drawing, etc.

18All calculations on time-allocation are indicative. Time demand should be calculated during this meeting.


19/39


19

Figure 3: "Start-up" draft sample

Experience shows: the discussion on the draft overview can be done in maximum of 2 hours

(6 man-hours). Try to avoid the involvement of any outside-scope information focus on the

very subject only. For this it is highly recommended that a clear definition of the domain inquestion is established earlier.

Correlation table method

In case the client is not familiar with the creation of draft, a possible option is to ask him/her

to create a correlation table.

There are only two simple steps to create a correlation table:

1. List processes and put them in a table showing all the listed processes on the X and theY axis

2. Put correlation markers into the intersections

A sample of a simple table is shown here:


20/39


20

How to interpret this table? Well, at first it might look too complicated but it can be

interpreted quite easily after some practice. For example it is clearly indicated you MUST

wake up in order to perform all other activities, and you might have to take shower in order towake up. You MUST to get out of the bed in order to take a shower but you have quite a good

chance to find toothpaste and toothbrush in the bed well it is not the tidiest household ,

and you might have breakfast in bed too.

General recommendation is on the interpretation is the rows show whether and how much a

Y axis element is required to perform an element on the X axis. In the same time columns

show what X axis element is needed (and how much) to achieve positive result for a Y axis

element.

It is very important to emphasize: as any interpretation of reality, the table approach is not

necessarily helpful or easy to perform. Be careful!

List method

Sometimes it is also very good as a preparation to compile various lists, before asking the

modeller to start modelling.

The most useful lists are:

- List of actors: persons / roles / IT systems involved in the process

- List of inputs: what are the common inputs of the process, are there exceptions, whatare their characteristics which is the actor most involved in the supplying of the

input in question

- List of outputs: what are the common outputs of the process, are there exceptions,what are their characteristicswhich is the actor most involved in the further usage of

the output in question

- List of links: what other processes are linked to the process in questions, either on theinput or the output side. Is there a process (are there processes) which are in the

middle of the process in question? (sub-processes)

- Group (if possible) the elements on lists: try to create (at least) common andexception groups in order to help the modeller and others to understand the

composition of the process.


21/39


21

2) Modelling and review

Figure 4: Phase 2 - overview

Internal discussion on overview provided by the client

Actors: Active and Backup MODELLER

In my observation it is very important to avoid modelling alone. Thus the concept of the

backup modeller is introduced to the modelling activity. The b -modeller helps the active

modeller (a-modeller) in the initial analysis of the draft overview provided by the client. The

b-modeller can help in the identification of patterns19

already discovered and in the alignment

to existing models of other processes.

This activity is estimated to consume maximum 1 man-day (4 man-hours of both modellers).

Prepare and deliver initial model

Actors: MODELLER

The active modeller prepares the initial model of the process, based on the previous

discussion with the client, taking into consideration the findings of the internal analysis of the

process overview.

In all of the graphical modelling activities it is very strongly advised for all the modellers to

stick to the "stencil" i.e. use only those graphical elements which were agreed upon by all the

modellers.The modeller should clearly indicate his (hers) questions on unfinished flows and/or unclear

parts in the initial model and the initial model should be sent to the client (for answers during

the review) and the b-modeller.

This activity is estimated to consume at least 4 man-days.

19For more information on general patterns I recommend to visithttp://is.ieis.tue.nl/research/patterns/patterns.htm
http://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htm


22/39


22

First review

Actors: MODELLER + CLIENT

During this activity the initial model is orally presented to the client and revised. In optimal

case the answers are given to the questions by the modeller.

Depending on the complexity of the subject this reviewing might consist of multiple sessions

but the deadline determined earlier should be respected (or should be modified accordingly).

It is necessary for the client to check and confirm the model provided as a whole to ensure

improvement and correctness from a legal (process) point of view. It therefore would be

helpful to keep the following questions in mind when reading the models and indicate doubts

or change requests to the modeller:

a. Are the elements in the correct order? Regarding the flow and the end of theprocess, the outcome might be identical when the elements are rearranged, but for

the practical approach within a process a change might be crucial.

b. Does the related article contain implicit rules not yet covered by the model?

c. Are all the links to other articles/processes/areas within the necessity for customsprovisions mentioned in the model? This is crucial for the future establishment of

the overall process and the "MCC-process-flow". Please pay attention especially

for the generic provisions (guarantees, authorisations, decision taking process,

customs declaration).

Out of the experience gained from the discussions between the legal experts and the modellers

and the combination of their interests reflecting in the BPM-diagrams created, the following

basic ideas principles needs to be stressed:

Although the task focuses on certain fields of modelling, either in legal or businessprocess aspects, it is advisable not to lose track of the whole. Since especially in themodelling on article basis previous and subsequent steps as well as links to other

provisions have to be respected, or the scope of an article doesn't cover a step of business

process, but a horizontal issue, a general definition or dimension parallel to the business

process steps (supervision, customs controls) it is considered as necessary to widen the

scope and try to incorporate aspects serving the purpose of the work, which is to

understand what is going to happen and track possible gaps. Apart, when amending the

models based on the answered questions it doesn't allow remaining in a fixed setting.

However, a balance of the different aspects has to be respected to claim the work and not

get lost in details.

BPM is not a substitute to the legal text! Basis for the customs administrations is and willbe in future the provisions set in force.

BPM can additional to the explanatory notes and the guidelines explain and clarify the

content and the purpose of the legal basis and be used for the development of the law as

well as for technical development. Therefore, it has its right to exists and can be consulted

in parallel to the provisions.

There is more than one way to model a process. Even different diagrams can reflect thesame content and lead to the same results. The same applies to the granularity of detail,

whereas it has to be avoided to oversimplify the diagrams. The advantage of increasing

the ability to create a correct model goes in parallel with hiding the problems and gaps in

the process, which leads to the devaluation of the spirit and purpose of the tool.
http://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htm


23/39


23

It is understood, that the development of provisions use several organisational andgrammatical principles as well as those with regards to content. These are proven in the

legal environment and the public administrations for ages. This comprises e.g. references

to general terms, negative listings or implicit rules. The expectation connected to BPM in

contrast is to get a clear picture of the processes concerned and how is to be acted in

detail. The shift to more commitment cannot be avoided, especially when it comes to IT-implementation, as systems are not familiar with general terms. Vagueness will be an

obstacle on this way. The sooner explicit paths can be identified the earlier a better

planning for exercising and implementation can be established. In future, the passage from

procedural ideas to the "to-be" situation will be easier to establish.

This activity is estimated to consume at least 1 man-day.

After the revision the modeller refines the initial model, adopts the findings of the review

meeting and thus creates the beta-model (ready for the second and final review).


Internal discussion on beta-model

Actors: Active and Backup MODELLER

During this activity the b-modeller reviews the beta-model, if necessary suggests

modifications to the beta-model although I think it is not very likely in case the team is

experienced and worked together previously on many models. The most probable

achievement is the update of the b-modeller of the current state of play. Also possible that the

b-modeller would have answers to some of the questions of the a-modeller in case those open

questions were not answered already by the client.Hopefully no questions remain unanswered after this stage.


After this meeting the (revised) beta-model is to be sent to the client.

Second review

Actors: MODELLER + CLIENT

The beta model is discussed during this meeting with the client. In case there are openquestions there should be an agreement reached between the client and the modeller how to

represent those in the final model.

After this meeting a final model should be prepared by the modeller and sent to the client and

to the b-modeller.
http://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htm


24/39


24

3) Acceptance

Figure 5: Phase 3 - overview


As by this time the model was (ought to have been) discussed many times the acceptance

should be performed by the client.

The form of acceptance is not set (yet) in the case of a High Level model, usually the model

is considered as accepted when it is sent by client to other (here unspecified or yet unknown)

stakeholders who have the possibility to give their reflections on the model. As the HighLevel model is usually a supportive supplement to a legal text, most probably it will be

always the legal text which will be discussed by those stakeholders. It is no point to discuss a

model without discussing the legal provisions it is based upon. In case the legal text is

changed then the model should be changed accordinglybut that activity should be treated as

a new round.

In case a model was requested by a Family during the MCCIP drafting activity the model is

to be accepted according the rules on acceptance by the Family in question.

In case of models for User Requirements (UR [SPM&Req]) or Functional Systems

Specifications (FSS) the acceptance takes the form of the acceptance of the UR or FSS

documents. In that case the same applies mutatis mutandis as stated above.Models with accepted status should be collected and documented (activity to be described inthe document on modelling coordination and tracking)
http://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htm


25/39


25

Accelerated Method of modelling

As it was presented in the previous section the General Method (GM) will lead to firm results

all the time. But without question the GM needs relatively higher amount of time

compared to the Accelerated Method, which can be presented like this:

As it can be seen from the Figure above, the process owner (Client / SME) is involved only in

the discussion of the process overview, the review of the Beta Model and the Acceptance.

All other activities are performed mainly by the a-modeller with the involvement of the b-

modeller.

Maturity of models

This section might be a bit technical to some readers but is very important for themodellers. In case you are not interested in technical matters please jump to the

next section.

Whatever is the level of modelling, besides the validity of a model it could be important to

know the maturity of a model.

In simple words: the more expertise is incorporated into a model the more mature it is. The

maturity represents the reliability of the specific model i.e. how well it represents the actual

process itself.

If the simple responsibilities cited again here one might discover the crucial points for

achieving the most reliable models.
http://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htm


26/39


26

A simple methodology exist to represent the maturity of a model is to show how many times

the above steps were performed. To give an example: a model with a maturity level "000010"

shows it was not based on any interaction with the Client or the Owner, it (the model) is a

result of the modeller's work, it represents:

There was 0 (zero) involvement of the Owner in the composition of the process

There was 0 (zero) involvement of the Client in the perception of the process There was 0 (no) expalanation by the client, thus there is a great possobility of

misinterpretation by the modeller.

There was 0 (no) understanding of the explanation by the modeller

There was 1 (one) model created by the modeller, but as no previous steps were performed,the modelat least according to my understandingis not very trustworthy.

There was 0 (no) understanding of the model by the client, most probably as a result of nopresentation.

So basically this "000010" model is a simple drawing by the modeller without any

consultation with the client. I suggest to leave this out from any official document.

It is advised to show the maturity level on any model, in order to allow the reader to be awareof any possible faults.

Alignment of methodology

One of the most crucial factors of successful modelling is the alignment of methodologies in

case a team of modellers is working on a complex project.

It is the responsibility of Coordination and Tracking to continuously monitor the activity of

the individual modellers and it is also very important to assign carefully the a and b

modeller tasks, in order to create a safety-net of knowledge, i.e. ensure the share ofinformation and continuous development of modelling techniques.

Referencing modelsIn case many models were / about to be prepared there is a very important factor to consider:

how to reference other models which are connected to the actual one.

There is not a clear structure / recommendation established so far, but it is suggested to

prepare first a general overview before starting the whole activity: a kind of planning frame

and create identification of all processes on that frame.

Here is an example, based on sample functions (processes) of the customs legislation:
http://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns/patterns.htmhttp://is.ieis.tue.nl/research/patterns

Documents

Guidance Note on Business Process Modelling Using BPMN v1p1 15-JULY