INFS3604 Business Process Management Week 3 PDF

INFS3604 Business Process Management Week: 3 Advanced Process Modelling The slides in this presentation have been adapted from supporting materials provided with the text: Dumas M. et al., 2018, Fundamentals of Business Process Management, Springer Verlag Berlin Heidelberg Lecturer: George Joukhad...

INFS3604 Business Process Management Week: 3 Advanced Process Modelling The slides in this presentation have been adapted from supporting materials provided with the text: Dumas M. et al., 2018, Fundamentals of Business Process Management, Springer Verlag Berlin Heidelberg Lecturer: George Joukhadar E-mail: [email protected] Copyright Notice Copyright • There are some file-sharing websites that specialise in buying and selling academic work to and from university students. • If you upload your original work to these websites, and if another student downloads and presents it as their own either wholly or partially, you might be found guilty of collusion — even years after graduation. • These file-sharing websites may also accept purchase of course materials, such as copies of lecture slides and tutorial handouts. By law, the copyright on course materials, developed by UNSW staff in the course of their employment, belongs to UNSW. It constitutes copyright infringement, if not academic misconduct, to trade these materials. Country Acknowledgement of Country UNSW Business School acknowledges the Bidjigal (Kensington campus) and Gadigal (City campus) the traditional custodians of the lands where each campus is located. We acknowledge all Aboriginal and Torres Strait Islander Elders, past and present and their communities who have shared and practiced their teachings over thousands of years including business practices. We recognise Aboriginal and Torres Strait Islander people’s ongoing leadership and contributions, including to business, education and industry. UNSW Business School. (2021, July 24). Acknowledgement of Country [online video]. Retrieved from https://vimeo.com/369229957/d995d8087f Process Modeling in the BPM Lifecycle Process identification Examples for BPM lifecycle and process mining 35h B 30h 15h A 5m 3m 10m 5m D Process architecture E 30m 2h 10m C 15m A 1.5h 10min B C D E Conformance and performance insights Process discovery As-is process model Process monitoring Process analysis Insights on weaknesses and their impact Executable process model Process implementation To-be process model Process redesign Learning Outcomes • Understand and use sub-processes to produce quality process models • Appreciate the value of documenting processes using hierarchical (sub-process) structures. • Understand and implement BPMN 2.0 notation for subprocesses. Week 3: Advanced Process Modeling Contents ▪ ▪ ▪ ▪ ▪ ▪ BPMN main elements (Recap of week 2) Process Decomposition (Chp 3) Rework and Repetition (Chp 4) Handling Events (Chp 4) Handling Exceptions (Chp 4) Recap BPMN Main Elements - Recap Flow Objects Activity Connections Message Association Gateway Event Flow Artifacts Pool Pools & lanes Lane Data Object Data Store BPMN Gateways Exclusive (XOR) Parallel (AND) Inclusive (OR) Exclusive decision take one branch Parallel split take all branches Inclusive decision take one or several branches depending on conditions Exclusive merge Proceed when one branch has completed Parallel join proceed when all incoming branches have completed Inclusive merge proceed when all active incoming branches have completed Week 3: Advanced Process Modeling Contents ▪ ▪ ▪ ▪ ▪ ▪ BPMN main elements (Recap of week 2) Process Decomposition (Chp 3) Rework and Repetition (Chp 4) Handling Events (Chp 4) Handling Exceptions (Chp 4) Recap Process decomposition An activity in a process can be decomposed into a “sub-process” Expanded Sub-process Task Collapsed Sub-process Activities Use this feature to: 1. 2. Improve understanding by breaking down large models Identify parts that should be: • repeated • executed multiple times in parallel • interrupted, or • compensated Anything wrong with this model? Does this look better? Identify possible sub-processes Acquire raw materials Ship and invoice Solution The refactored model In signavio Linking the sub-process in Signavio Sub-processes ❑ An activity in a process can invoke a separate sub-process ❑ Use this feature to: 1. Decompose large models into smaller ones, making them easier to understand and maintain Guideline: Multi-level modeling Level 1: value chain • Simple linear description of the phases of the process • No gateways • Each activity chain is a sub-process Level 2+: expand each activity in the value chain, add incrementally the following: • • • • Decisions, handoffs (lanes, pools) Parallel gateways, different types of events Data objects & data stores And as much detail as you need, and no more Guideline: Multi-level modeling (cont.) At each level, decompose according to: • Logical milestones towards achieving the outcome of the process • Major objects used in the process Decompose until processes are of “reasonable” size • e.g. up to 20 nodes (tasks+events+gateways) per model Non-BPMN value chain “chevron” notation - (e.g. Signavio, ARIS) Collapsed process model Value chain with sub-processes Consider resubmission Purchase Request process rejected Check purchase request for 1st approval Purchase Request approved rejected Check purchase request for 2nd approval approved Send approved request to requestor Purchase Order process Make copy of purchase request Approved Purchase Request Forward to purchase department Value Chain in Signavio Value Chain in Signavio When should we decompose a process model into sub-processes? Process Decomposition When should we decompose a process model into sub-processes? This then begs the question: • What are the quality attributes of a process model? • Readability • Understandability • Accuracy • Completeness Use sub-processes when the model becomes too large: • Hard to understand • Increased error probability Week 3: Advanced Process Modeling Contents ▪ ▪ ▪ ▪ ▪ ▪ BPMN main elements (Recap of week 2) Process Decomposition (Chp 3) Rework and Repetition (Chp 4) Handling Events (Chp 4) Handling Exceptions (Chp 4) Recap Block-structured repetition: Loop Activity BPMN also provides the loop activity construct to allow the repetition of a task or sub-process Task Loop Sub-process Loop More on rework and repetition XOR-join: entry point XOR-split: exit point Structured cycle (SESE fragment) SESE = Single Entry Single Exit fragment, i.e. a fragment delimited by a single entry node and a single exit node (there are no other incoming arcs into the fragment or outgoing arcs from the fragment) Example: block-structured repetition Completion condition Until Response is approved Assign Ministerial Enquiry Finalise Ministerial Response Investigate Ministerial Enquiry Ministerial Enquiry received Ministerial Enquiry finilized Prepare Ministerial Response Enquiry investigated Review Ministerial Response Response reviewed Must have a decision activity Parallel repetition: multi-instance activity The multi-instance activity provides a mechanism to indicate that an activity is executed multiple times concurrently Multi-Instance Task Multi-Instance Sub-process Useful when the same activity needs to be executed for multiple entities or data items, such as: • Request quotes from multiple suppliers • Check the availability for each line item in an order separately • Send and gather questionnaires from multiple witnesses in the context of an insurance claim Example: multi-instance activity Obtain Quote from Supplier A Procurement In procurement, typically a quote is to be obtained from all preferred suppliers (assumption: five preferred suppliers exist). After all quotes are received, they are evaluated and the best quote is selected. A corresponding purchase order is then placed. Obtain Quote from Supplier B ... Obtain Quote from Supplier C Obtain Quote from Supplier D Obtain Quote from Supplier E Select best quote Place PO ... With multi-instance activity - Solution Procurement Obtain Quote from Supplier A cardinality For each supplier Obtain Quote from Supplier B ... Obtain Quote from Supplier C Obtain Quote from Supplier D Obtain Quote from Supplier E Select best quote Place PO ... ... Obtain Quote Select best quote Place PO ... Week 3: Advanced Process Modeling Contents ▪ ▪ ▪ ▪ ▪ ▪ BPMN main elements (Recap of week 2) Process Decomposition (Chp 3) Rework and Repetition (Chp 4) Handling Events (Chp 4) Handling Exceptions (Chp 4) Recap Events handling In BPMN, events model something instantaneous happening during the execution of a process They affect the process flow: • Start • Intermediate • End BPMN event types Start Intermediate End Untyped Event – Indicates that an instance of the process is created (start) or completed (end), without specifying the cause for creation/completion Start Message Event – Indicates that an instance of the process is created when a message is received End Message Event – Indicates that an instance of the process is completed when a message is sent Intermediate Message Event – Indicates that an event is expected to occur during the process. The event is triggered when a message is received or sent Catching Example: message events Court Administration P&E Court Listings For all Judges Check P&E Judge Availability Check Court Calendar Court Calendar Received Court Calendar Change Request Request Sittings List Sittings List Received Change P&E Schedules Yearly Schedule Sent Judiciary Start/catching event (receive) Intermediate catching event (receive) Resolve P&E Judge Availability End/throwing event (send) Comparison with sending/receiving tasks = Receive invoice = Send invoice = Send invoice ≠ Receive invoice Invoice received Invoice sent Invoice sent Invoice received So, when to use what? Use message events only when the corresponding activity would simply send or receive a message and do nothing else (i.e. when activity does not really represent a unit of work) Temporal events (timer events) Start Intermediate End Start Timer Event – Indicates that an instance of the process is created at certain date(s)/time(s), e.g. start process at 6pm every Friday Intermediate Timer Event – Triggered at certain date(s)/ time(s), or after a time interval has elapsed since the moment the event is enabled (delay) Timer events are catching events only The process does not generate the timer, but reacts to it Coming back to our scenario… PO handling A Purchase Order (PO) handling process starts when a PO is received. The PO is first registered. If the current date is not a working day, the process waits until the following working day before proceeding. Otherwise, an availability check is performed and a PO response is sent back to the customer. Next working day weekend/ holiday Register PO PO Received weekday Check Availability Send PO Response PO fulfilled Recap: Message and Timer events Start Intermediate Catching Catching Throwing process starts upon message received message received during the process message sent during the process process starts when time event occurs time event occurred (to model delay) End Throwing process ends upon message sent Racing events: Event-based decision With the XOR-split gateway, a branch is chosen based on conditions that evaluate over available data → The choice can be made immediately after the token arrives from the incoming flow Sometimes, the choice must be delayed until an event happens → The choice is based on a “race” among events Two types of XOR split: data-driven XOR-split event-driven XOR split Empty pentagon enclosed in a double-line circle Exercise 4.6: Stock replenishment Model the following process. A restaurant chain submits a purchase order (PO) to replenish its warehouses every Thursday. The restaurant chain’s procurement system expects to receive either a “PO Response” or an error message. However, it may also happen that no response is received at all due to system errors or due to delays in handling the PO on the supplier’s side. If no response is received by Friday afternoon or if an error message is received, a purchasing officer at the restaurant chain’s headquarters should be notified. Otherwise, the PO Response is processed normally. data-driven XOR-split event-driven XOR split Empty pentagon enclosed in a double-line circle Exercise 4.6: Stock replenishment Solution Recap: message and timer events Start Intermediate Catching Untyped: indicate start point, state changes or final states. Message: Receiving and sending messages. Timer: Cyclic timer events, points in time, time spans or timeouts. End Throwing Week 3: Advanced Process Modeling Contents ▪ ▪ ▪ ▪ ▪ ▪ BPMN main elements (Recap of week 2) Process Decomposition (Chp 3) Rework and Repetition (Chp 4) Handling Events (Chp 4) Handling Exceptions (Chp 4) Recap Process abortion Exceptions are events that deviate a process from its “normal” course The simplest form of exception is to notify that there is an exception (negative outcome) This can be done via the Terminate end event: it forces the whole process to abort (“wipes off” all tokens left behind, if any) Example 1: terminate event Signal the negative outcome… Example 2: terminate event Abort the process by removing all tokens… If a terminate event is triggered from within a sub-process, it will not abort the parent process Exception handling Handling exceptions often involves stopping a sub-process and performing a special activity Types of exceptions for an activity (task/sub-process): Internal: something goes wrong inside an activity, whose execution must thus be interrupted. Handled with the Error event External: something goes wrong outside the process, and the execution of the current activity must be interrupted. Handled with the Message event (e.g customer cancelled the order) Timeout: an activity takes too long and must be interrupted. Handled with the Timer event All these events are catching intermediate events. They stop the enclosing activity and start an exception handling routine. Let’s extend our PO handling process PO handling A PO handling process starts when a PO is received. The PO is first registered. If the current date is not a working day, the process waits until the following working day before proceeding. Otherwise, an availability check is performed and a PO response is sent back to the customer. Next working day weekend/ holiday Register PO PO Received weekday Check Availability Send PO Response PO fulfilled 62 Let’s extend our PO handling process PO handling Next working day weekend/ holiday Register PO PO Received weekday Check Availability Send PO Response PO fulfilled A PO change request may be received anytime after the PO is registered. This request includes a change in quantity or line items. When such a request is received, any processing related to the PO must be stopped. The PO change request is then registered. Thereafter, the process proceeds as it would do after a normal PO is registered. Further, if the customer sends a PO cancelation request after the PO registration, the PO processing must be stopped and the cancelation request must be handled. Solution: exception handling PO handling Handle PO Next workingNext day working day weekend/ holiday weekend/ holiday Register PO PO Received weekday weekday Check Availability Check Send PO Availability Response PO Registered Send PO Response PO fulfilled PO Change received Register PO Change PO Cancel received Handle PO Cancelation PO canceled Response sent PO fulfilled Internal exception: error event Start Intermediate End Error Event – Indicates an error: the end version generates an error event while the catching intermediate version consumes it when attached to the boundary of an activity Must be attached to the activity’s boundary Example: internal exception PO handling Consider again our “PO Handling process” example with the following extension: if an item is not available, any processing related to the PO must be stopped. Thereafter, the client needs to be notified that the PO cannot be further processed. Handle PO Next working day weekend/ holiday weekday Register PO PO Received Check Availability Send PO Response PO Registered Response sent PO Change received Register PO Change PO Cancel received Handle PO Cancelation PO canceled PO fulfilled Solution: internal exception PO handling Throwing and catching error events must have the same label Handle PO Handle PO Nextworking working day Next day Items not available weekend/ weekend/ holiday holiday PO PO Received Received Check Check Availability Availability weekday weekday Register PO Register PO PO PO Registered Registered PO Change received Register PO Change Send POSend PO Response Response Items PO Response available Response fulfilledPO sentsent fulfilled Items not available PO Cancel received Handle PO Cancelation PO canceled Notification sent Must catch an error event thrown from within the same activity Exercise 4.10: activity timeout Order-to-transportation quote Once a wholesale order has been confirmed, the supplier transmits this order to the carrier for the preparation of the transportation quote. In order to prepare the quote, the carrier needs to compute the route plan (including all track points that need to be traversed during the travel) and estimate the trailer usage. By contract, wholesale orders have to be dispatched within four days from the receipt of the order. This implies that transportation quotes have to be prepared within 48 hours from the receipt of the order to remain within the terms of the contract. Solution: activity timeout Order-to-transportation quote More on the PO handling example… PO handling Handle PO Next working day Items not available weekend/ holiday weekday Register PO PO Received Check Availability Items available PO Registered PO Change PO Cancel received received Register PO Change Send PO Response Response sent Items not available Handle PO Cancelation PO canceled Notification sent The customer may send a request for address change after the PO registration. When such a request is received, it is just registered, without further action. PO fulfilled Non-interrupting boundary events Sometimes we may need to trigger an activity in parallel to the normal flow, i.e. without interrupting the normal flow. This can be achieved by using non-interrupting boundary events Must be attached to the activity’s boundary Solution: non-interrupting boundary events PO handling Handle PO Next working day Items not available weekend/ holiday weekday Register PO PO Received Check Availability Items available PO Registered PO Change PO Cancel received received Register PO Change Handle PO Cancelation Send PO Response Response sent Address change received Items not available PO canceled Notification sent Update customer address Customer address updated PO fulfilled Week 3: Advanced Process Modeling Contents ▪ ▪ ▪ ▪ ▪ ▪ BPMN main elements (Recap of week 2) Process Decomposition (Chp 3) Rework and Repetition (Chp 4) Handling Events (Chp 4) Handling Exceptions (Chp 4) Recap Recap ▪ In this lecture we have learned about: ▪ ▪ ▪ ▪ ▪ ▪ BPMN sub-processes Repetition markers: loop marker and parallel multi-instance marker Events: timer, message and error events Event-based choice gateway Boundary events: interrupting and non-interrupting Error events (throw and catch) And once I’ve got a model, what’s next? ▪Process analysis techniques ▪ Read Chapter 5 of your textbook.