BPM for business analysts: modelling procedure

  • 2,726 views
Uploaded on

 

More in: Technology , Business
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
2,726
On Slideshare
0
From Embeds
0
Number of Embeds
30

Actions

Shares
Downloads
125
Comments
0
Likes
3

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. BPM for business analysts: Modelling procedure A. Samarin See also http://fr.slideshare.net/samarin/bpm- for-developers
  • 2. © A. Samarin 2013 BPM for business analysts: Modelling procedure 2 Example of unstructured BPMN (1)
  • 3. © A. Samarin 2013 BPM for business analysts: Modelling procedure 3 Example of unstructured BPMN (2)
  • 4. © A. Samarin 2013 BPM for business analysts: Modelling procedure 4 Example of unstructured BPMN (3)
  • 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 BPM for business analysts: Modelling procedure 5 Reasons for a diagramming style
  • 6. • Horizontal vs. vertical timeline © A. Samarin 2013 BPM for business analysts: Modelling procedure 6 Diagramming style in BPMN (1) Timeline
  • 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 BPM for business analysts: Modelling procedure 7 Diagramming style in BPMN (2)
  • 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 BPM for business analysts: Modelling procedure 8 Diagramming style in BPMN (3)
  • 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 BPM for business analysts: Modelling procedure 9 Diagramming style in BPMN (4)
  • 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 BPM for business analysts: Modelling procedure 10 Principles of the 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 BPM for business analysts: Modelling procedure 11 Want to avoid block-diagrams
  • 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 BPM for business analysts: Modelling procedure 12 The modelling procedure (1)
  • 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 BPM for business analysts: Modelling procedure 13 The modelling procedure (2)
  • 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 BPM for business analysts: Modelling procedure 14 The modelling procedure (3)
  • 15. © A. Samarin 2013 BPM for business analysts: Modelling procedure 15 Four phases
  • 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 BPM for business analysts: Modelling procedure 16 Example: request for absence
  • 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 BPM for business analysts: Modelling procedure 17 Blackboxing phase (1)
  • 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 BPM for business analysts: Modelling procedure 18 Blackboxing phase (2)
  • 19. • An example of deliverables BPM for business analysts: Modelling procedure 19 Blackboxing phase (3) 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
  • 20. • An example of deliverables BPM for business analysts: Modelling procedure 20 Blackboxing phase (4) 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
  • 21. • An example of deliverables BPM for business analysts: Modelling procedure 21 Blackboxing phase (5) 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
  • 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 BPM for business analysts: Modelling procedure 22 Structuring phase (1)
  • 23. • Steps © A. Samarin 2013 BPM for business analysts: Modelling procedure 23 Structuring phase (2)
  • 24. • Steps and artefacts © A. Samarin 2013 BPM for business analysts: Modelling procedure 24 Structuring phase (3)
  • 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 BPM for business analysts: Modelling procedure 25 Structuring phase (4)
  • 26. • An example of deliverables BPM for business analysts: Modelling procedure 26 Structuring phase (5) 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
  • 27. • An example of deliverables BPM for business analysts: Modelling procedure 27 Structuring phase (6) 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
  • 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 BPM for business analysts: Modelling procedure 28 Re-construction phase (1)
  • 29. • The diagram © A. Samarin 2013 BPM for business analysts: Modelling procedure 29 Re-construction phase (2)
  • 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 BPM for business analysts: Modelling procedure 30 Re-construction phase (3)
  • 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 BPM for business analysts: Modelling procedure 31 Instrumentation phase (1)
  • 32. • The diagram © A. Samarin 2013 BPM for business analysts: Modelling procedure 32 Instrumentation phase (2)
  • 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 BPM for business analysts: Modelling procedure 33 Instrumentation phase (3)
  • 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 BPM for business analysts: Modelling procedure 34 General recommendations