BPM for business analysts: modelling procedure

BPM for business analysts:
Modelling procedure
A. Samarin
See also http://fr.slideshare.net/samarin/bpm-
for-developers

© A. Samarin 2013 BPM for business analysts: Modelling procedure 2
Example of unstructured BPMN (1)

• 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
Reasons for a diagramming style

• Horizontal vs. vertical timeline
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

• 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

• 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

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

• 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

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

• An example of deliverables
BPM for business analysts: Modelling procedure 19
Name Value Comment
Name 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 TreatAbsenceRequestFinish
This event can be used
to trigger some HR-
specific processes
Input business objects Nothing
Output business objects AbsenceRequest
Used business objects
RoleDefinition, Employee,
Absence, and AbsenceRequest
© A. Samarin 2013

Name Value Comment
Other resources involved: rules Roles dependencies
Some logic is necessary
to define the “peers” for
a given requestor
Other resources involved: roles
This process owner
This process initiator
Requestor
Requestor’s peers
Requestor’s supervisor
HR representative
HR 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 engine
This service may be
useful for implementing
some business logic
© A. Samarin 2013

Name Value Comment
Other resources involved:
documents
Possibly, some quality
documents
KPIs
Agreed execution time
Number of requestor’s interactions
Number of failed requests for
absence
Choice of implementation As a process
Related processes
TreatAnnouncementAbsence
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
Structuring phase (1)

• Steps

• Steps and artefacts

– 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)

Name Value Comment
Steps Step01 Recoding of proposed absence(s) and check of it
(them) with the requestor's peers
Step02 Obtention of approval from the requestor's
supervisor
Step03 Performance of HR formalities
Check-points CP01
CP02
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 Comment
Automated activities Pre- and post- activities for the
whole process
In 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
Re-construction phase (1)

• The diagram

– 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

• 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)
Instrumentation phase (1)

• The diagram

– an executable diagram for coordination of all building blocks
– a formal description of the automated activities (as WDSL)
– business logic
– all testing scenarios

• 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
General recommendations

BPM for business analysts: modelling procedure

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (10)

Similaire à BPM for business analysts: modelling procedure

Similaire à BPM for business analysts: modelling procedure (20)

Plus de Alexander SAMARIN

Plus de Alexander SAMARIN (15)

Dernier

Dernier (20)

BPM for business analysts: modelling procedure