Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Mini-course at VFU - Architecting modern digital systems - 2

25 views

Published on

A small source for IT students at the VFU, Varna.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Mini-course at VFU - Architecting modern digital systems - 2

  1. 1. Architecting digital systems Module 2 Business Process Management Alexander Samarin
  2. 2. © A. Samarin 2018 Architecting digital systems - Module 2 2 Be ready for common (mis-)understanding
  3. 3. • Organisation functioning can be considered as business activity flows spanning the applications, employees, customers and partners within and beyond its boundaries • Business activity is a unit of work • Organizations create “big” emergent functionality by coordinating several “small” existing functionalities • Business process is an explicitly-defined coordination for guiding the purposeful enactment of business activities – Business process is a plan of work with some variations and its execution with some necessary corrections • Business Process Management (BPM) is managing business by/via/using business processes © A. Samarin 2018 Architecting digital systems - Module 2 3 Definitions
  4. 4. • The business is driven by events • For each event there is a process to be executed • Process coordinates execution of activities • The execution is carried out in accordance with business rules © A. Samarin 2018 Architecting digital systems - Module 2 4 Process anatomy (1)
  5. 5. • Each business activity operates with some business objects • A group of staff member (business role) is responsible for the execution of each activity • The execution of business processes produces audit trails • Audit trails (which are very detailed) are also used for the calculation of Key Performance Indicators (KPIs) • There is a goal for each process © A. Samarin 2018 Architecting digital systems - Module 2 5 Process anatomy (2)
  6. 6. • No explicit separation between “process template” (i.e. planning of work) with “process instance” (i.e. observed work) • Process transforms inputs into output • Business process is consider as a flowchart ONLY • Business process equals to BPMN • End-to-end process can be expressed as a flowchart • Business process is just an illustration of the real work • All process models are wrong but some may be useful © A. Samarin 2018 Architecting digital systems - Module 2 6 Wide-spread misunderstandings about business processes
  7. 7. • Process template – an abstract description/plan of a process • Process instance – enactment of a process template • Different variations of relationship between template and instance © A. Samarin 2018 Architecting digital systems - Module 2 8 Process templates and instances (1) Templates and their versions Instances
  8. 8. Time Template v1 Template 3Template v2 Instance 1.1 Instance 1.2 Instance 1.3 Instance 2.4 Instance 2.6 Instance 2.5 Instance 3.7 Instance 3.8 © A. Samarin 2018 Architecting digital systems - Module 2 9 Process templates and instances (2)
  9. 9. © A. Samarin 2018 Architecting digital systems - Module 2 10 Variant 1 – classic (one template is used for many instances)
  10. 10. © A. Samarin 2018 Architecting digital systems - Module 2 11 Variant 2 – tailoring (a template is adjusted for each instance)
  11. 11. © A. Samarin 2018 Architecting digital systems - Module 2 12 Variant 3 – reactive (no initial template and next activity is selected based on the current situation)
  12. 12. © A. Samarin 2018 Architecting digital systems - Module 2 13 Variant 4 – proactive planning (similar to variant 3, but a few next activities [fragment] are executed together)
  13. 13. © A. Samarin 2018 Architecting digital systems - Module 2 14 Variant 5 – scenario-based (similar to variant 4, but a few scenarios are considered) Process fragments are used; those may be patterns
  14. 14. • Coordination between business activities – In the context of enterprise functioning, business activities must be coordinated – Coordination maybe strong (e.g. as in the army) or weak (e.g. as in an amateurs football team) – Coordination maybe implicit or explicit – Coordination maybe declarative (laws) and imperative (orders) © A. Samarin 2018 Architecting digital systems - Module 2 15 Enterprise as a system of processes
  15. 15. • Orchestration-centric – temporal-based – flow-chat-based – pattern-based • State-centric – life-cycle-based • Decision-centric – rule-based – behaviour-based – managerial – instinct-based © A. Samarin 2018 Architecting digital systems - Module 2 16 About coordination techniques (1)
  16. 16. • Various – resource-based – goal-based – event-based © A. Samarin 2018 Architecting digital systems - Module 2 17 About coordination techniques (2)
  17. 17. • decomposition cascade • assembling cascade • combine cascade © A. Samarin 2018 Architecting digital systems - Module 2 18 About coordination techniques (3)
  18. 18. • Based on coordination, let us think about “levels of cohesion” between activities and thus find out coordination constructs (in addition to activities) 1. process patterns (coordination within processes) 2. processes 3. cluster of processes (coordination between processes) 4. system of processes (coordination between clusters of processes) © A. Samarin 2018 Architecting digital systems - Module 2 20 Coordination constructs
  19. 19. • Business case: typical “claim processing” process – claim, repair, control, invoicing, and assurance to pay © A. Samarin 2018 Architecting digital systems - Module 2 21 Process fragments – patterns SI PAR SI IPS Click for animation
  20. 20. • Business concern: Interactions between two independent parties – public administration and partner (citizen, local business, etc.) • Logic – partner submits some documents (including forms) to administration – administration checks those documents – administration may request partner to provide more documents or to carry out some corrections – administration checks those documents again – and so on © A. Samarin 2018 Architecting digital systems - Module 2 22 Process pattern: Submission Interface (SI)
  21. 21. © A. Samarin 2018 Architecting digital systems - Module 2 23 SI animated diagram Click for animation
  22. 22. • Simple event-based (which looks like a state machine) © A. Samarin 2018 Architecting digital systems - Module 2 24 Coordination between processes (1)
  23. 23. 1. state-machine 2. synchronous invocation 3. asynchronous invocation 4. fire and forget 5. parallel processes 6. co-processes (pattern SI) © A. Samarin 2018 Architecting digital systems - Module 2 25 Coordination between processes (2)
  24. 24. • CLOPs are usually functional processes which are implemented a particular business function, e.g. Field Services • And a “halo” of extra processes 1. monitoring 2. operating 3. management © A. Samarin 2018 Architecting digital systems - Module 2 26 CLuster Of Processes (CLOP)
  25. 25. © A. Samarin 2018 Architecting digital systems - Module 2 27 Enabler group, supporting group and customer group of clusters
  26. 26. • Coordination for business objects such as products – a product life-cycle which requires some future work (e.g. the technical service of a car after every 20 000 km) – aka scheduling – the influence of the eco-system on the product, e.g. the end of support/production for some components of a particular product – technology progress, e.g. the availability of a cheaper material for/component of a particular product © A. Samarin 2018 Architecting digital systems - Module 2 28 Coordination between CLOPs (1)
  27. 27. • coordination for business objects such as resources – if a resource is not available then any processes that use that resource need to wait (in a queue) for it – a resource requires replenishment if its capacity is below a defined threshold © A. Samarin 2018 Architecting digital systems - Module 2 29 Coordination between CLOPs (2)
  28. 28. • coordination for business objects such as customers – offering new services and products as the result of field servicing – changing of legal conditions (to renegotiate a maintenance contract) – marketing campaigns © A. Samarin 2018 Architecting digital systems - Module 2 30 Coordination between CLOPs (3)
  29. 29. © A. Samarin 2018 Architecting digital systems - Module 2 32 Implicit coordination between CLOPs (1)
  30. 30. © A. Samarin 2018 Architecting digital systems - Module 2 33 Implicit coordination between CLOPs (2)
  31. 31. © A. Samarin 2018 Architecting digital systems - Module 2 34 Implicit coordination between CLOPs (3)
  32. 32. • The life-cycle of all business objects should be considered as a process © A. Samarin 2018 Architecting digital systems - Module 2 35 Make relationships between CLOPs explicit (1)
  33. 33. • An enterprise-wide event dispatcher should be available © A. Samarin 2018 Architecting digital systems - Module 2 36 Make relationships between CLOPs explicit (2)
  34. 34. • The explicit link between two CLOPs may be established via the life-cycles of a few business objects and an enterprise-wide event dispatcher © A. Samarin 2018 Architecting digital systems - Module 2 37 Make relationships between CLOPs explicit (3)
  35. 35. © A. Samarin 2018 Architecting digital systems - Module 2 38 Functional view at a system of processes (1)
  36. 36. © A. Samarin 2018 Architecting digital systems - Module 2 39 Functional view at a system of processes (2)
  37. 37. © A. Samarin 2018 Architecting digital systems - Module 2 40 Functional view at a system of processes (3)
  38. 38. document-centric processes human-centric processes supporting processes core business processes lead processes life-cycle as a process customer-experience as a process policy as a process project as a process system-of-processes Iceberg of processes © A. Samarin 2018 Architecting digital systems - Module 2 41
  39. 39. © A. Samarin 2018 Architecting digital systems - Module 2 42 Modelling demo
  40. 40. • 3 kinds of flow objects – Activity – Gateway – Event • 3 ways of connecting – Sequence flow – Message flow – Association • Two types of container – Pools – Lanes (swimlanes) © A. Samarin 2018 Architecting digital systems - Module 2 43 BPMN basic set shapes conditional sequence flow
  41. 41. © A. Samarin 2018 Architecting digital systems - Module 2 44 Example of unstructured BPMN (1)
  42. 42. © A. Samarin 2018 Architecting digital systems - Module 2 45 Example of unstructured BPMN (2)
  43. 43. © A. Samarin 2018 Architecting digital systems - Module 2 46 Example of unstructured BPMN (3)
  44. 44. © A. Samarin 2018 Architecting digital systems - Module 2 47 Example of workflow-like models
  45. 45. • 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 • Different people in similar situations should produce similar diagram © A. Samarin 2018 Architecting digital systems - Module 2 48 Reasons for a diagramming style
  46. 46. • Horizontal vs. vertical timeline © A. Samarin 2018 Architecting digital systems - Module 2 49 Diagramming style in BPMN (1) Timeline
  47. 47. © A. Samarin 2018 Architecting digital systems - Module 2 53 Diagramming style in BPMN (5) P a r t i c i p a n t s
  48. 48. • 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 2018 Architecting digital systems - Module 2 54 The modelling procedure (1)
  49. 49. • 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 2018 Architecting digital systems - Module 2 55 The modelling procedure (2)
  50. 50. • 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! © A. Samarin 2018 Architecting digital systems - Module 2 56 The modelling procedure (3)
  51. 51. © A. Samarin 2018 Architecting digital systems - Module 2 57 Four phases
  52. 52. • 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 2018 Architecting digital systems - Module 2 58 Blackboxing phase
  53. 53. • 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 2018 Architecting digital systems - Module 2 59 Structuring phase (1)
  54. 54. • Steps © A. Samarin 2018 Architecting digital systems - Module 2 60 Structuring phase (2)
  55. 55. • Steps and artefacts © A. Samarin 2018 Architecting digital systems - Module 2 61 Structuring phase (3)
  56. 56. • 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 2018 Architecting digital systems - Module 2 62 Re-construction phase (1)
  57. 57. • The diagram © A. Samarin 2018 Architecting digital systems - Module 2 63 Re-construction phase (2)
  58. 58. • 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 2018 Architecting digital systems - Module 2 64 Instrumentation phase (1)
  59. 59. • The diagram © A. Samarin 2018 Architecting digital systems - Module 2 65 Instrumentation phase (2)
  60. 60. • 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 2018 Architecting digital systems - Module 2 66 General recommendations
  61. 61. © A. Samarin 2018 Architecting digital systems - Module 2 67 Five lenses for business processes Classic values-streams with their phases and main capabilities (value-streams are, in effect, a sequence of business transactions) Clusters as coordination (primarily event-based) of classic processes, almost no routing logic Classic processes as coordination of stages (logical fragments, often process patterns) Instrumentation with automated activities L1 Value- steams L2 Clusters-of- processes L3 Coordination of fragments L4 Coordination of activities L5 Automation of activities and processes Fragments as coordination of human activities (with associated roles); use of process patterns
  62. 62. L1 Value- steams L2 Clusters-of- processes L3 Coordination of fragments L4 Coordination of activities L5 Automation of activities and processes © A. Samarin 2018 Architecting digital systems - Module 2 68 Combination of modelling approaches Departmental projects to implement processes of a particular business domain with a BPM-suite tool. Quick enterprise-wide “landscape” project to develop L1 and L2 processes and establish common practices (modelling procedures, patterns, etc.).
  63. 63. L1 Value- steams L2 Clusters-of- processes L3 Coordination of fragments L4 Coordination of activities L5 Automation of activities and processes © A. Samarin 2018 Architecting digital systems - Module 2 69 Events to link not yet executable and already executable processes Explicit but not yet executable L2 processes can be used to extract business events. Some of those events can initiate explicit and executable processes L3, L4 and L5.
  64. 64. L1 Value- steams L2 Clusters-of- processes L3 Coordination of fragments L4 Coordination of activities L5 Automation of activities and processes © A. Samarin 2018 Architecting digital systems - Module 2 70 Events are very useful Explicit but not yet executable L2 processes can be used to extract business events for generating KPIs and for detecting performance problems (bottlenecks, etc.) via process mining techniques.
  65. 65. • Supporting processes (HR, accounting, IT, general services) are rather typical and straightforward • Core processes are a potential place for a mixture of BPM, ACM, decision management and business events • Enabling processes (they implement common functionality for core processes) are, usually, in between • Governance / Leadership processes • Recommendations – Use APQC as a checklist for supporting, enabling and G/L processes – Concentrate on core processes to understand the coordination nature of them (flow-charts, scheduling, events, rules, etc.) © A. Samarin 2018 Architecting digital systems - Module 2 71 Core, enabling and supporting process
  66. 66. © A. Samarin 2018 Architecting digital systems - Module 2 72 Customer example (1)
  67. 67. © A. Samarin 2018 Architecting digital systems - Module 2 73 Customer example (2)
  68. 68. © A. Samarin 2018 Architecting digital systems - Module 2 76 EXAMPLE
  69. 69. • Pierre and Aline are in the situation of divorce. Their son – Laurent. • Pierre moves to an address. Aline and Laurent move to anotehr address. New addresses are announced to OCP (population department) or AFC ( fiscal department) or, probably, DIP (education department). • All these departments exchange addresses. © A. Samarin 2018 Architecting digital systems - Module 2 77 Example: Moving of a family
  70. 70. • Complexity N*(N-1)/2 © A. Samarin 2018 Architecting digital systems - Module 2 78 Exchange between N sources - problem OCP AFC … … DIP
  71. 71. • Complexity N © A. Samarin 2018 Architecting digital systems - Module 2 79 Exchange between N sources - solution DIPAFCOCP Coordination process …
  72. 72. © A. Samarin 2018 Architecting digital systems - Module 2 80 Comparison in 3D
  73. 73. © A. Samarin 2018 Architecting digital systems - Module 2 81 Coordination process (between three departments – OCP, AFC and DIP) Click for animation
  74. 74. © A. Samarin 2018 Architecting digital systems - Module 2 82 Execute a request for change (in each source) Click for animation
  75. 75. © A. Samarin 2018 Architecting digital systems - Module 2 83 Big picture in 3D
  76. 76. © A. Samarin 2018 Architecting digital systems - Module 2 84 Moving a family (1) OCP Coordination process …AFC DIP Click for animation Pierre (father)
  77. 77. © A. Samarin 2018 Architecting digital systems - Module 2 85 Moving a family (2) OCP Coordination process …AFC DIP Aline (mother) Laurent (son) AFC_1 DIP_1 Passer auprès des juristes Click for animation Délai_1
  78. 78. © A. Samarin 2018 Architecting digital systems - Module 2 86 Big picture in 3D
  79. 79. © A. Samarin 2018 Architecting digital systems - Module 2 87 Instantiation of change: implicit vs. explicit (e.g. by e-gov portal) OCP Coordination process …AFC DIP Explicit Implicit OCP Coordination process …AFC DIP Click for animation
  80. 80. © A. Samarin 2018 Architecting digital systems - Module 2 88 Questions?
  81. 81. • An enterprise is a complex, dynamic and adaptive system; one can improve it by: – measuring – observing – deciding – implementing © A. Samarin 2018 Architecting digital systems - Module 2 89 Feedback improvement loop 1 2 3 4
  82. 82. © A. Samarin 2018 Architecting digital systems - Module 2 90 Process improvement disciplines
  83. 83. © A. Samarin 2018 Architecting digital systems - Module 2 91 Process-oriented view of an enterprise (before BPM)
  84. 84. © A. Samarin 2018 Architecting digital systems - Module 2 92 Process-oriented view of an enterprise (with BPM)
  85. 85. © A. Samarin 2018 Architecting digital systems - Module 2 93 BPM suite components
  86. 86. • A graphical environment to manipulate with diagrams and other artefacts © A. Samarin 2018 Architecting digital systems - Module 2 94 Process designer / modeller
  87. 87. • Management of process templates and instances by a system administrator © A. Samarin 2018 Architecting digital systems - Module 2 95 Execution engine console (1)
  88. 88. • Access to audit trail of a process instance © A. Samarin 2018 Architecting digital systems - Module 2 96 Execution engine console (2)
  89. 89. • Access to BPM for a « normal user » © A. Samarin 2018 Architecting digital systems - Module 2 97 Worklist (1)
  90. 90. © A. Samarin 2018 Architecting digital systems - Module 2 98 Worklist (2)
  91. 91. • Business Event Management (BEM) • A business rules engine (BRE) and decision management • Enterprise content management (ECM) system • Collaboration facilities • An Enterprise Service Bus (ESB) to provide a service- oriented integration layer © A. Samarin 2018 Architecting digital systems - Module 2 99 BPM suite components (optional)
  92. 92. © A. Samarin 2018 Architecting digital systems - Module 2 100 BPM suite components (extended list)
  93. 93. © A. Samarin 2018 Architecting digital systems - Module 2 101
  94. 94. • Template-based – static connection of “flow objects” or sequence relationship (predecessor and successor) – similar to a river (upstream and downstream) – process template is an abstract description of a process © A. Samarin 2015 BPM fundamental - Module 6 102 Four types of coordination logic (1)
  95. 95. • Token-based – token marks elements which active at a particular time – dynamic connection of “flow objects” or synchronisation (wait for) / chronologic relationship – similar to a “flock” of ducks (split and join) – several tokens may co-exist © A. Samarin 2015 BPM fundamental - Module 6 103 Four types of coordination logic (2) Click for animationClick for animation
  96. 96. • Event-based – non-structured synchronisation between tokens – exchange of messages (signals, errors, etc.) – exception handling © A. Samarin 2015 BPM fundamental - Module 6 104 Four types of coordination logic (3) Click for animation Wait for (catch) a message event Generate (throw) a message event
  97. 97. • Instance-based – process instance is an enactment of a process template – each instance may have different behaviour of tokens – process instances may be coordinated via event-based coordination logic © A. Samarin 2015 BPM fundamental - Module 6 105 Four types of coordination logic (4) Click for animation
  98. 98. • Start event produces a token • End (or finish) event consumes a token • Intermediate token means that something happened within a business process engine © A. Samarin 2015 BPM fundamental - Module 6 106 Event types Click for animation
  99. 99. • Too many events details • Recommendations to use: – Mainly “message” – Sometimes “empty”, “error” and “timer” © A. Samarin 2015 BPM fundamental - Module 6 107 Event details Throw message Catch messageStart message End message Click for animation
  100. 100. © A. Samarin 2015 BPM fundamental - Module 6 108 Combination of activities and events (1) Called “boundary” events - timer
  101. 101. © A. Samarin 2015 BPM fundamental - Module 6 109 Combination of activities and events (2) Called “boundary” events - message
  102. 102. • It has at least one activity! © A. Samarin 2015 BPM fundamental - Module 6 110 Simplest useful process Click for animation
  103. 103. • Activity02, Activity03 and Activity04 will be executed in parallel; the process will only be continued when each of them is completed • Logic of tokens is used © A. Samarin 2015 BPM fundamental - Module 6 111 Parallel gateway Click for animation
  104. 104. • A single activity Activity02 or Activity03 or Activity04 will be executed. The choice is based on the logic defined within the gateway G01 • Logic of tokens is used © A. Samarin 2015 BPM fundamental - Module 6 112 Exclusive gateway Click for animation
  105. 105. • Several activities can be executed in parallel • It covers functionality of parallel and exclusive gateways • Logic of tokens is used © A. Samarin 2015 BPM fundamental - Module 6 113 Inclusive gateway Click for animation
  106. 106. © A. Samarin 2015 BPM fundamental - Module 6 114 Duplications in BPMN standard (1)
  107. 107. © A. Samarin 2015 BPM fundamental - Module 6 115 Duplications in BPMN standard (2)
  108. 108. © A. Samarin 2015 BPM fundamental - Module 6 116 Duplications in BPMN standard (3)
  109. 109. © A. Samarin 2015 BPM fundamental - Module 6 117 Duplications in BPMN standard (4)
  110. 110. • Send an offer to a prosper client and bait for 3 possible intermediate events 1. Agreed 2. Disagreed 3. No reply for some time then time-out © A. Samarin 2015 BPM fundamental - Module 6 118 Exclusive event-based gateway Short variant
  111. 111. • Process fragment is a compound activity • Also called “sub-process” © A. Samarin 2015 BPM fundamental - Module 6 119 Process fragments
  112. 112. © A. Samarin 2015 BPM fundamental - Module 6 120 Start and end events within process fragment maybe omitted
  113. 113. • Repeating conditions may be different in different systems © A. Samarin 2015 BPM fundamental - Module 6 121 Repeatable process fragments (1) Click for animation
  114. 114. • Be explicit within fragments; the exclusive gateway G01 which is used to specify two branches – one to continue the loop and one to exit it © A. Samarin 2015 BPM fundamental - Module 6 122 Repeatable process fragments (2) Click for animation
  115. 115. • Catching errors and time-outs © A. Samarin 2015 BPM fundamental - Module 6 123 Process fragment as logical grouping Click for animationClick for animation
  116. 116. • Activities B and C are executed in parallel © A. Samarin 2015 BPM fundamental - Module 6 124 Process fragment PF00 (sub-process) as a parallel gateway
  117. 117. • Flow connector represents the sequence of activities within the same pool • Message connection represents the communication between activities in separate pools © A. Samarin 2015 BPM fundamental - Module 6 125 Connectors Click for animation
  118. 118. • Message flow may be connected to a pool itself © A. Samarin 2015 BPM fundamental - Module 6 126 Connecting two pools (1)

×