BPM for business analysts: modelling procedure
-
Upload
alexander-samarin -
Category
Technology
-
view
2.522 -
download
1
description
Transcript of BPM for business analysts: modelling procedure
BPM for business analysts:Modelling procedure
A. Samarin
See also 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 3© A. Samarin 2013
Example of unstructured BPMN (2)
BPM for business analysts: Modelling procedure 4© A. Samarin 2013
Example of unstructured BPMN (3)
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
BPM for business analysts: Modelling procedure 6
• Horizontal vs. vertical timeline
© A. Samarin 2013
Diagramming style in BPMN (1)
Timeline
BPM for business analysts: Modelling procedure 7
• 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
Diagramming style in BPMN (2)
BPM for business analysts: Modelling procedure 8
• 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
Diagramming style in BPMN (3)
BPM for business analysts: Modelling procedure 9
• 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
Diagramming style in BPMN (4)
BPM for business analysts: Modelling procedure 10
• 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
BPM for business analysts: Modelling procedure 11
• 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
BPM for business analysts: Modelling procedure 12
• 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)
BPM for business analysts: Modelling procedure 13
• 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
The modelling procedure (2)
BPM for business analysts: Modelling procedure 14
• 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
The modelling procedure (3)
BPM for business analysts: Modelling procedure 15© A. Samarin 2013
Four phases
BPM for business analysts: Modelling procedure 16
– 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
BPM for business analysts: Modelling procedure 17
• 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)
BPM for business analysts: Modelling procedure 18
• 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
Blackboxing phase (2)
• An example of deliverables
BPM for business analysts: Modelling procedure 19
Blackboxing phase (3)
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
• An example of deliverables
BPM for business analysts: Modelling procedure 20
Blackboxing phase (4)
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
• An example of deliverables
BPM for business analysts: Modelling procedure 21
Blackboxing phase (5)
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
BPM for business analysts: Modelling procedure 22
• 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)
BPM for business analysts: Modelling procedure 23
• Steps
© A. Samarin 2013
Structuring phase (2)
BPM for business analysts: Modelling procedure 24
• Steps and artefacts
© A. Samarin 2013
Structuring phase (3)
BPM for business analysts: Modelling procedure 25
• The deliverables
– 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
Structuring phase (4)
• An example of deliverables
BPM for business analysts: Modelling procedure 26
Structuring phase (5)
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
• An example of deliverables
BPM for business analysts: Modelling procedure 27
Structuring phase (6)
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
BPM for business analysts: Modelling procedure 28
• 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)
BPM for business analysts: Modelling procedure 29
• The diagram
© A. Samarin 2013
Re-construction phase (2)
BPM for business analysts: Modelling procedure 30
• The deliverables
– 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
Re-construction phase (3)
BPM for business analysts: Modelling procedure 31
• 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)
BPM for business analysts: Modelling procedure 32
• The diagram
© A. Samarin 2013
Instrumentation phase (2)
BPM for business analysts: Modelling procedure 33
• The deliverables
– 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
Instrumentation phase (3)
BPM for business analysts: Modelling procedure 34
• 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