BPM for business analysts: modelling procedure

BPM for business analysts:Modelling procedure

A. Samarin

See also http://fr.slideshare.net/samarin/bpm-for-developers

http://fr.slideshare.net/samarin/bpm-for-developers



BPM for business analysts: Modelling procedure 2© A. Samarin 2013

Example of unstructured BPMN (1)





BPM for business analysts: Modelling procedure 5

• Diagram is a communication (between people) tool

• Good diagram should be understood in less than 30 seconds

• Processes are better understood by focusing on the decisions to make, the issues to solve, and the results to produce, than on the administrative ordering of steps

© A. Samarin 2013

Reasons for a diagramming style


• Horizontal vs. vertical timeline

© A. Samarin 2013

Diagramming style in BPMN (1)

Timeline


• Our use of colours for BPMN constructions is as follows:

– brown (or orange): orchestration or execution-related gateways, events and activities

– cyan: important events, e.g. start and finish, and check-points

– blue: automated activities

– green: human intellectual human activities

– yellow: human validation human activities

– red: human administrative human activities

– grey: groups or activities of undefined / mixed nature

© A. Samarin 2013



• All BPMN constructions shall be consistently named:

– start event Start

– finish event Finish

– intermediate events: check-point (CP##), etc.

– gateways: G##

– activities: Activity## or meaningful names

– sub-processes: Group## or meaningful names

© A. Samarin 2013



• We use several pools in the following way:

– in the middle of a diagram: a pool for the coordination of activities – COOR## (where ## stands for 01, 02, and so on)

– above the orchestration pool: some pools for manual activities – HUMAN## (where ## stands for 01, 02, and so on)

– below the orchestration pool: some pools for automated activities – SERVICE##

– at the bottom of a diagram: a pool for the environment – DISPATCH

© A. Samarin 2013



• it treats human and automated activities equally

• it is primarily for capturing the flow of control within a building block, but not for optimisation

• it is a tool for both business and IT (maybe with coaching by a process analyst)

• it provides validation by simulation

• it provides validation by quick prototyping – real services can be invoked

• it is visual programming

© A. Samarin 2013

Principles of the modelling procedure


• In block-diagrams the same block must occur only once (as people interpret those diagrams as flow of data)

• Business processes are flow of control thus the same activity may occur more then one time

© A. Samarin 2013

Want to avoid block-diagrams


• Its purpose is:

– to analyse a building block (what it is supposed to do)

– to synthesise its implementation (how it does this) as explicit coordination of other building blocks (processes or activities)

• It is iterative: we can apply it until we only have left indivisible building blocks (i.e. activities)

• Artefacts are constructed recursively, like Russian dolls

© A. Samarin 2013

The modelling procedure (1)


• It is similar to solving a puzzle: everyone has his/her own way

• There are a few practical tips

– make the edges first

– group together pieces with a similar colour or pattern

– collect them into clusters

– use the latter as “centres of crystallisation”

– then fill in the rest

© A. Samarin 2013



• But, there are a few real-life difficulties: you have

– to do many puzzles at the same time

– to use pieces from other puzzles

– to cut new pieces

– to optimise the number of pieces

– to transform some puzzles

– etc.

• It should be a lot of fun!

• LEGO started from 10-20 different pieces; now they offer about 1000 different pieces

© A. Samarin 2013



Four phases


– complete a standard HR form with details of the absence requested

– validate the proposed absence with your peers (e.g. those who need to provide back up for you)

– submit the completed form to your supervisor for approval

– transfer the completed, approved, form to the HR department for registration in a time-accounting system

– announce the approved absence to a business partner

© A. Samarin 2013

Example: request for absence


• The purpose

– to analyse a building block as a whole

– to discover its functional characteristics and some related artefacts

• The method

– the business story behind this building block should be carefully analysed to recognise its artefacts

• Recommendations

– don’t go into excessive detail for each artefact; this can be done later

– define your list of deliverables

© A. Samarin 2013

Blackboxing phase (1)


• The deliverables

– the name of this building block

– the business story which explains what this building block does

– the nomenclature of incoming and outgoing business events

– the nomenclature of the input business objects

– the nomenclature of the output business objects

– the nomenclature of the business objects

– the resources involved, e.g. rules, roles, services, documents

– any guidance (instructions, KPIs) needed for correct functioning

– the choice of implementation: is it an indivisible service to be implemented via a programming language or a process?

– related processes

© A. Samarin 2013


• An example of deliverables



Name Value CommentName of this building block TreatAbsenceRequest

Business story See chapter 6

Process owner Somebody from the HR department

Incoming business events TreatAbsenceRequestStart Generated by the HR department

Outgoing business events TreatAbsenceRequestFinishThis event can be used to trigger some HR-specific processes

Input business objects Nothing

Output business objects AbsenceRequest

Used business objectsRoleDefinition, Employee, Absence, and AbsenceRequest

© A. Samarin 2013




Name Value Comment

Other resources involved: rules Roles dependenciesSome logic is necessary to define the “peers” for a given requestor

Other resources involved: roles

This process owner This process initiatorRequestorRequestor’s peersRequestor’s supervisorHR representativeHR data owner

The naming of these roles is not defined in this book

Other resources involved: other services

An HR system

The enterprise calendar

A business rules engineThis service may be useful for implementing some business logic

© A. Samarin 2013




Name Value CommentOther resources involved: documents

Possibly, some quality documents

KPIs

Agreed execution timeNumber of requestor’s interactionsNumber of failed requests for absence

Choice of implementation As a process

Related processesTreatAnnouncementAbsence

If a staff member becomes sick, then this process may be used to “inform” the business system of this fact

TerminateAbsence

© A. Samarin 2013


• The purpose

– to analyse a building block from within to determine its internal structure and its major artefacts

• The method

– determine the main (added-value) steps

– classify artefacts for these steps

– add check-points between steps

• Recommendations

– don’t have more than 7 steps

– avoid loop-back over check-points

– avoid too much detail

© A. Samarin 2013

Structuring phase (1)


• Steps

© A. Samarin 2013



• Steps and artefacts

© A. Samarin 2013




– the nomenclature of the steps

– the nomenclature of the check-points

– the nomenclature of the (mainly) human activities(if any)

– the nomenclature of the (mainly) automated activities (if any)

© A. Samarin 2013





Name Value CommentSteps Step01 Recoding of proposed absence(s) and check of it

(them) with the requestor's peersStep02 Obtention of approval from the requestor's

supervisorStep03 Performance of HR formalities

Check-points CP01CP02

Human activities For the requestor The requestor selects his/her absence(s) with the help of the enterprise calendar and the HR system

For the peers Each peer has to confirm that he/she has been informed about the proposed absence(s)

For the supervisor The supervisor has to confirm that he/she agrees or does not agree with proposed absence(s)

For HR representative The HR representative has to control and, possibly, enter the proposed absence(s) into the HR system

© A. Samarin 2013




Name Value CommentAutomated activities Pre- and post- activities for the

whole processIn accordance with the PDP pattern

Pre- and post- support for the requestor

In accordance with the AHA pattern

Report for the supervisor All information pertinent to the proposed absence(s) is collected in an aggregated document for the supervisor

HR system update May be used instead of the HR representative

© A. Samarin 2013


• The purpose

– to synthesize an initial version of the formal coordination: some kind of process skeleton

• The method

– add intra-step logic

– start formalising the business objects involved

– collect test scenarios

• Recommendations

– consider implementation of human activities as simple forms

© A. Samarin 2013

Re-construction phase (1)


• The diagram

© A. Samarin 2013




– formalised (as XSD) business objects

– an executable diagram for the coordination of some activities

– descriptions of all human activities (prototypes for user interface, roles, etc.)

– routing logic

– some testing scenarios

© A. Samarin 2013



• The purpose

– to enrich the process skeleton by adding more automated activities

• The method

– add pools

– apply different practical patterns

– use a business rule engine if available

– collect test scenarios

• Recommendations

– work iteratively (step-by-step)

© A. Samarin 2013

Instrumentation phase (1)


• The diagram

© A. Samarin 2013




– an executable diagram for coordination of all building blocks

– a formal description of the automated activities (as WDSL)

– business logic

– all testing scenarios

© A. Samarin 2013



• Adjust the modelling procedure for your needs, e.g. collection of artefacts during different phases

• Bring downstream information needs upstream

• Ensure 100 % quality at the beginning of the process - input quality control

• Work collaboratively (business & IT) on each phase

• Try to become “executable” as early as possible

• Automate testing

© A. Samarin 2013

General recommendations

Technology

BPM for business analysts: modelling procedure