1. Marlon Dumas marlon.dumas ät ut . ee
MTAT Business Process Management (BPM) (for Masters of ETM) Lecture 1: Introduction
Marlon Dumas
marlon.dumas ät ut . ee

2. Course Objective
The objective of this course is to introduce the principles and methods of business process management.
The course emphasises the role of business process modelling as an instrument to understand and analyse business operations, and to drive the design of Information Technology solutions to support the automation of business processes.

3. Structure of the Course
Four sessions
17.02 – Introduction to BPM and BPMN
17.03 – Process Analysis & Improvement
14.04 – Process Lifecycle Management
09.06 – Project Presentations and Exam
Two homeworks worth 10 points each
Project (30 points) – to be released on 14.04
Exam (50 points)

4. Readings and Resources
Recommended textbook
Manuel Laguna and Johan Marklund. Business Process Modeling, Simulation and Design, Prentice Hall, (esp. Chapters 1, 2 and 3)
Other readings & resources listed in the course pages:
For communication, we will use this message board:

5. Agenda for Today Time Contents 10.00-11.30 Introduction to BPM
Break
The BPM Lifecycle
Lunch Break
BPMN – with a coffee break at 15:45-16:00

6. Introduction to Business Process Management
Part I
Introduction to Business Process Management

7. BPM: What is it?
Body of methods to design, analyze, execute and monitor business operations involving humans, software, information and physical artifacts using process models.
Business Process Management (BPM) is the art and science of overseeing how work is performed in an organization in view of ensuring consistent outcomes and identifying and taking advantage of improvement opportunities. In this context, the term ``improvement'' may take different meanings depending on the objectives of the organization. Typical examples of improvements include reducing costs, reducing execution times and reducing error rates. Importantly, BPM is not about improving the way individual activities are performed, but rather, it is about managing entire chains of events, activities and decisions that ultimately add value to the organization.
Within the broad context of the above definition, BPM regroups a body of methods for managing business operations on the basis of process models. Process models represent the understanding that people in the organization have about how work is done or should be done. They act as the bridge between business operations and IT systems. They allow us to understand how IT systems contribute to adding value to the organization by streamlining its work practices.

8. So What is a (Business) Process
Collection of logically-related events, activities and decisions, that involve a number of actors and resources, and that collectively lead to an outcome that is of value to an organization or its customers.
Examples:
Order-to-Cash
Procure-to-Pay
Claim-to-Settlement (Insurance)
Fault-to-Resolution
Events correspond to things that happen ``atomically'', meaning that they have no duration. For example, the arrival of a plant to the depot is an event. This event may trigger the execution of series of activities. For example, when a plant arrives, the site engineer inspects the plant. This inspection is an activity, in the sense that it takes time. When an activity is rather simple and takes relatively little time, we call it a task. For example, if the inspection that the site engineer performs is quite simple -- e.g. just checking that the plant received corresponds to what was ordered -- we can say that the ``plant inspection'' is a task. If on the other hand the inspection of the plant requires many steps -- such as checking that the plant fulfills the specification included in the purchase order, checking that the plant is in working order, and checking the plant comes with all the required accessories and safety devices -- we will treat it as an ``activity''. The distinction between task and activity is not always clear-cut. This is why, very often people will use the term task and activity interchangeably.
Order-to-cash: This is a process that starts when a customer places an order to purchase a product or a service, and ends when the product or service in question has been delivered and the corresponding payment has been received. An order-to-cash process encompasses activities such as purchase order verification, shipment (in the case of physical products), delivery, invoicing, payment receipt and acknowledgment.
Quote-to-order: This process typically precedes the order-to-cash process. It starts from the point when a ``request for quote'' is received from a customer, to the point when the customer places a purchase order. The order-to-cash process takes the relay from that point on. The combination of a quote-to-order and the corresponding order-to-cash process is called a quote-to-cash process.
Procure-to-pay: This is a process that starts when a stakeholder within an organization -- typically an employee -- determines that a given product or service needs to be purchased. It ends when the product or service has been delivered and paid for. A procure-to-pay process includes activities such as approving the purchase, obtaining quotes, selecting a supplier, issuing a purchase order, receiving the goods (or consuming the service), checking and paying the invoice. Procure-to-pay can be seen as the dual of quote-to-cash in the context of business-to-business interactions. For every procure-to-pay process there is a corresponding quote-to-cash process on the supplier's side.
Issue-to-resolution. This is a process that starts when a customer raises a problem, such as a complaint related to a defect in a product or an issue encountered when consuming a service. The process continues until the customer, the supplier, or preferably both of them, agree that the issue has been resolved. A variant of this process can be found in insurance companies that have to deal with ``insurance claims''. This variant is often called claim-to-resolution.

9. “My washing machine won’t work!” fault-report-to-resolution process
Warranty?
Service
Dispatch
Technician
Call Centre
Customer
Parts
Store
Customer
Customer
VALUE
The execution of a process leads to one or several \emph{outcomes}. For example, the above process leads to a plant being used by BuildIT, as well as a payment being made to the plant's supplier. These outcomes deliver \emph{value} to the key actors involved in the process, which in this example are BuildIT and the supplier. In some cases, this value is not achieved or is only partially achieved. For example, when a plant is returned, no value is gained, neither by BuildIT nor by the supplier. This corresponds to a \emph{negative outcome}, as opposed to a \emph{positive outcome} that delivers value to the actors involved.
fault-report-to-resolution process
© Michael Rosemann

10. Background to BPM Organisational Management - Adam Smith (1776)
Observation: “a number of specialized workers, each performing a single step in the manufacture of a pin, could make far more pins in a day than the same number of generalists.”
Quoted from Hammer & Champy 1993
It is worth noting that Adam Smith himself acknowledged the potential limitations of the functional organization of work, especially the threat of over-specialization.

11. Limitations of Functional Organisation
Focus on skills and resource utilization rather than outcomes
Reward systems tailored to functional units, not the overall firm
Group behavior and cultures fostering an “us versus them” mentality (silos)

12. Complementarity of Functional and Process Views
Business Environment
Economy
Culture
Regulatory
Organisation System
Other
Stakeholders
Resources
Performance Planned
Performance Managed
Financial
Function A
Function B
Function C
Human
Resources
Materials
Technology
Business Processes
Customers
[after Rummler 1984]

13. Why BPM?
“The first rule of any technology used in a business is that automation applied to an efficient operation will magnify the efficiency. The second is that automation applied to an inefficient operation will magnify the inefficiency.”

14. Why BPM?
Improving Business Processes = #1 business priority for CIOs internationally, 4 years in a row…
© Gartner Group, 2009 CIO Survey

15. Why BPM? Process Change Yields Information Technology Business Value
Enables
Yields
Process
Change
Index Group (1982)

16. How to engage in BPM? Two complementary BPM approaches:
Continuous Process Improvement (CPI)
Does not put into question the current process design, but rather seeks to identify issues and resolve them incrementally, one step at a time and one fix at a time
Business Process Re-Engineering (BPR)
Put into question the fundamental assumptions and principles of the existing process design
Aims to achieve breakthrough, for example by removing costly tasks that do not directly add value

17. The Ford Case Study (Hammer 1990)
Ford needed to review its procurement process to:
Do it cheaper (cut costs)
Do it faster (reduce turnaround times)
Do it better (reduce error rates)
Accounts payable in North America alone employed > 500 people and turnaround times for processing POs and invoices was in the order of weeks
Hammer, M., (1990). "Reengineering Work: Don't Automate, Obliterate", Harvard Business Review, July/August, pp. 104–112.

18. The Ford Case Study
Automation would bring some improvement (20% improvement)
But Ford decided not to do it… Why?
Because at the time, the technology needed to automate the process was not yet available.
Because nobody at Ford knew how to develop the technology needed to automate the process.
Because there were not enough computers and computer-literate employees at Ford.
None of the above

19. The correct answer is … Mazda’s Accounts Payable Department

20. How the process worked? (“as is”)

21. How the process worked? (“as is”)

22. How the process worked? (“as is”)

23. How the process worked? (“as is”)

24. How the process worked? (“as is”)

25. How the process worked? (“as is”)

26. Reengineering Process (“to be”)

27. Reengineering Process (“to be”)

28. Reengineering Process (“to be”)

29. Reengineering Process (“to be”)

30. Reengineering Process (“to be”)

31. Reengineering Process (“to be”)

32. The result… 75% reduction in head count
Material control is simpler and financial information is more accurate
Purchase requisition is faster
Less overdue payments
 Why automate something we don’t need to do?

33. Principles of BPR
Have those who use the output of the process perform the process
Subsume information-processing work into the real work that produces the information
Treat geographically dispersed resources as if they were centralized
Link parallel activities instead of integrating their results
Capture information once and at the source
Regarding the first principle, it is worth citing examples of process improvement patterns such as Self-Service and Vendor-Managed Inventory Control.
Regarding the second principle, we can refer back to the idea of performing PO matching at delivery, rather than postponing this till the invoice is received
Regarding, the fifth principle, self-service is again a typical example, particularly the ability for customers or workers to enter data themselves that goes directly into the organization’s databases

34. Part II
The BPM Lifecycle

35. How to engage in BPM? The BPM Lifecycle
Opportunity assessment
Process modelling (as-is)
Process analysis
Process re-design (to-be)
Process implementation
Process monitoring/controlling
Process Modeling Tools
Process Management Systems

36. How to engage in BPM?
Phase 1: Opportunity assessment
Define the strategic goals, link them to measurable objectives and quantify the benefits
Profit maximizing firms
Non-profit organizations
Overarching goal is usually to
maximize long term shareholder value
A common goal is survival and
growth while satisfying customer needs
Maximize revenues and
minimize costs
Must use resources efficiently while
understanding customer needs
Satisfying customer needs in an efficient way
© Laguna & Marklund

37. Classification of process metrics
Cost
Cost per execution
Resource utilization
Waste
Time
Cycle time
Waiting time / time spent in non-value-added tasks
Quality
Error rates (negative outcomes, wrong info)
Missed promise

38. Phase 2: Process Identification and “As Is” Modeling

39. Phase 3: Analysis Qualitative analysis Scenario analysis
Cause-Effect-Analysis
Issue Register
Quantitative Analysis
Cycle Time Analysis
Capacity Analysis
Queuing Theory
Process Simulation

40. Phase 4: Re-design Strategy / Goals Capabilities As Is To-Be
Issues
Barriers
Guidelines
Capabilities IT
Knowledge
People
Ability to change
Culture
To-Be
Best Practice
Reference
Models
Bench
marking
Ideal
models
Study
tours

41. The Devil’s Rectangle
Costs
Time
Flexibility
Quality

42. Basics of Process Re-Design: Activity Classification
A key step in process re-design is classifying of the process activities into value-adding and non-value adding
Crucial in identifying waste and inefficiencies in existing processes
Activity
Value-Adding
Non-Value Adding
Handoff
Delay
Rework
Business Value Adding
Control
Policy compliance
© Laguna & Marklund

43. Activity Classification
Customer value-adding activities
Essential in order to meet customer expectations
Activities the customer would be willing to pay for
Involves doing the right things right
Performing the right activities
Doing them correctly, with high efficiency
Business value adding activities
Control activities
Do not directly add customer value but are essential to conducting business
Non-value adding activities
Activities the customer is not willing to pay for
© Laguna & Marklund

44. Activity Classification
Elimination of non-value adding activities is a key first step in redesigning business processes
Often achieved through task or activity consolidation
Task and activity consolidation reduces
Hand-offs
Need for control activities
Process complexity
© Laguna & Marklund

45. Phases 5-6. Automation & Monitoring – When Technology Kicks in..

46. Exercise – Claims Handling in a Large Insurance Company
Claims handling for replacement of automobile glass
Set up procedure
The CEO appoints an executive sponsor to lead the project
Team members are handpicked by the CEO and the sponsor
The team creates a flowchart of the existing process
Under the existing process the client may have to wait 1-2 weeks before being able to replace the damaged auto glass
Goal – A radical overhaul and improvement of the process to shorten the client waiting time
© Laguna & Marklund

47. Overview of the existing claims process
Client
Local
independent
agent
Approved
glass
vendor
Claims
processing
center
Request additional information
Pay
Notify agent
File claim
Give instructions
Forward
claim
Request quote
Provide quote
© Laguna & Marklund

48. Existing claims process
Client notifies a local agent that she wishes to file a claim. She is given a claims form and is told to obtain a cost estimate from a local glass vendor.
When the claims form is completed the local agent verifies the information and forwards the claim to a regional processing center.
The processing center logs the date and time of the claim’s arrival. The data is entered into a computer-based system (for record keeping only) by a clerk. The claim is then placed in a hard copy file and passed on to a claims representative.
a) If the claims representative is satisfied with the claim it is passed along to several others in the processing chain and eventually a check is issued and sent to the client.
b) If there are problems with the claim the representative mails it back to the client for necessary corrections.
5. When the client receives the check she can go to the local glass vendor and replace the glass.
© Laguna & Marklund

49. Exercise: Value-Adding Activity Identification
June 2009 exam, question 5(b)

50. Introduction to Business Process Modeling
Part II
Introduction to Business Process Modeling

51. Compliance / Risk Management Enterprise Architecture
Process Modeling: Why?
Process Improvement
Compliance / Risk Management
Process
Documentation
Knowledge Management
Enterprise Systems
Process Cost Analysis/Simulation
Enterprise Architecture
Workflow Management
Document Management
Software
Evaluation/
Selection
© Michael Rosemann

52. Popular Process Modelling Purposes
Recker et al. (2005)

53. Process Modeling Languages
For business analysts
Business Process Modelling Notation (BPMN)
Event-driven Process Chains (EPC)
IDEF0, IDEF3
Flowcharts, data-flow diagrams (system analysis)
UML Activity Diagrams (system analysis)
For business programmers
Business Process Execution Language (BPEL)
Yet Another Workflow Language (YAWL)
And many, many more…

54. Modelling Purpose vs. Detail
Abstract Models
EPC, BPMN
Communication, simulation, activity-based costing…
Detailed Models
BPEL, YAWL…
Data types, conditions, data mappings, fault handling…
Integration, testing, deployment…

55. Business Process Modeling Notation (BPMN)
OMG Standard, supported by many tools:
Bizagi Process Modeller (free download for Windows)
Signavio (
TIBCO Business Studio (free download, quite large)
IBM Websphere Business Modeler
ARIS
Oracle BPA
Business Process Visual Architect (Visual Paradigm)
Metastorm ProVision
Savvion Business Modeller (Progress Software).
For simple drawing, you can use:
Visio (available through MS Academic Alliance)
yEd ( )

56. BPMN from miles…
A process model in BPMN is called a Business Process Diagram (BPD)
A BPD is essentially a graph consisting of four types of elements (among others):

57. Example
An Order Management process is triggered by the reception of a purchase order from a customer. The purchase order has to be checked against the stock re the availability of the product(s) requested. Depending on stock availability the purchase order may be confirmed or rejected. If the purchase order is confirmed, the goods requested are shipped and an invoice is sent to the customer.

58. Order Management Process in BPMN

59. A little bit more on gateways …
Exclusive Decision / Merge
Indicates locations within a business process where the sequence flow can take two or more alternative paths.
Only one of the paths can be taken.
Depicted by a diamond shape that may contain a marker that is shaped like an “X”.
Parallel Fork / Join
Provide a mechanism to synchronize parallel flow and to create parallel flow.
Depicted by a diamond shape that must contain a marker that is shaped like a plus sign.

60. Revised Order Management Process

61. BPMN Exercise 1: Claims Notification process at a car insurer
When a claim is received, it is first checked whether the claimant is insured by the organization. If not, the claimant is informed that the claim must be rejected. Otherwise, the severity of the claim is evaluated. Based on the outcome (simple or complex claims), relevant forms are sent to the claimant. Once the forms are returned, they are checked for completeness. If the forms provide all relevant details, the claim is registered in the Claims Management system, which ends the Claims Notification process. Otherwise, the claimant is informed to update the forms. Upon reception of the updated forms, they are checked again.

62. Process Modelling Viewpoints
Who?
Organization
What?
Function
When?
Process
Which?
Data / Service / Product

63. Process Modelling Viewpoints
Functional perspective
What tasks/function are happening in the process?
Control-flow perspective
In what order do they occur?
Resource perspective (also called organisational perspective)
Who performs which activity?
Data perspective
What data are created/produced by the process?
“Process-modelling (*synonymous to process mapping) is an
approach, for visually depicting how businesses conduct their operations;
defining and depicting business processes, including entities, activities,
enablers and the relationships between them (Gill)
“Business process modelling is the documentation, analysis and design of the structure of a business or business sector, its aims and objectives, the mechanisms and resources used to deliver them; the constraints it must work within, and its relationships with the environment in which it operates” (DAVIES)
“A process model includes a set of activities arranged in a specific order, with the clearly identified inputs and outputs. The output may be either a product or service. Each activity in a process takes an input and transforms it into an output with some value to a customer. Ideally, every transformation occurring in the process should add value to the input and create an output that is useful to a downstream recipient”
(Zakarian and Kusiak)
IN GENERAL TERMS ..
Process modeling is an approach for visually depicting how businesses conduct their operations; defining and depicting business processes including entities, activities, enablers and the relationships between them
(Curtis, Keller and Over, 1992; Gill, 1999, p.5).

64. Organisational Elements in Process Models
Basic abstractions:
Resource (participant, actor, user, agent) A resource can execute certain tasks for certain cases. Human and/or non-human (e.g. printer).
Resource class: Set of resources with similar characteristics
A resource class is typically either a:
Role (skill, competence, qualification) Classification based on what a resource can do or is expected to do (Manager, Finance Officer, etc.)
Group (department, team, office, business unit) Classification based on the organization (Sales Dept., Accounts Payable, Accounts Receivable, etc.)

65. Resource Modelling in BPMN
In BPMN, resource classes are captured using:
Pools – independent organisations or organizational units (e.g. customer, supplier, East-Tallinn Hospital, Tartu Clinic)
Lanes – tightly connected roles or groups (e.g. Sales Department, Marketing Department, Clerk, Manager, Engineer, …)

66. BPMN Elements – Pools
Pools represent business process participants. They are used to partition a set of activities.
Can be a business entity or a business role.
Sequence flows cannot cross the boundaries of a Pool.
Interaction between Pools are captured through Message Flow (dashed lines with an arrow)
A Pool will extend the entire length of the Diagram.

67. Order Management example (ctd.)
The Order Management process now includes the customer as a process participant...
The Order Management process is started when a customer places a purchase order. The purchase order has to be checked against the stock re the availability of the product(s). Depending on stock availability the purchase order may be confirmed or rejected. If the purchase order is confirmed, the goods requested are shipped and an invoice is sent to the customer. The customer makes then makes the payment.

68. Order Management BPD with Poola

69. BPMN Elements – Swimlanes
Lanes represent sub-partitions within a pool. They are used to organize and categorize activities.
Horizontal vs. vertical
Meaning is not specified by BPMN, Lanes are often used for internal roles (e.g., Manager, Associate), systems (e.g., an enterprise application), an internal department (e.g., shipping, finance), etc.
Both Sequences Flow and Message Flow can cross the boundaries of Lanes.
Lanes can be nested:
E.g., an outer set of Lanes for company departments and then an inner set of Lanes for roles within each department.
A Pool will extend the entire length of the Diagram.

70. Order Management example (ctd.)
The process now includes two departments within the supplier organization...
The purchase order received by the Sales & Distribution department has to be checked against the stock. The order details are sent to the Warehouse department that returns an availability notification. If the purchase order is confirmed, the Warehouse department collects the shipping details from the customer and ships the goods. The Sales & Distribution department sends an invoice to the customer who then makes the payment.

71. Corresponding BPMN Model
Note: Strictly applied, BPMN does not allow message flows to happen across the same pool, but in practice, it’s not uncommon

72. BPMN Exercise 2: Lanes, Pools
Claims Handling process at a car insurer
A customer submits a claim by sending in relevant documentation. The Notification department checks the documents for completeness and registers the claim. The Handling department picks up the claim and checks the insurance. Then, an assessment is performed. If the assessment is positive, a garage is phoned to authorise the repairs and the payment is scheduled (in this order). In any case (whether the outcome is positive or negative), a letter is sent to the customer and the process is considered to be complete.

73. BPMN Artifacts
Data Objects are a mechanism to show how data is required or produced by activities.
Represent input and output of a process activity.
Annotations are a mechanism for the modeller to provide additional text information to the diagram reader.
Text annotations do not affect the flow of the process.
Groups are a visual mechanism to logically group diagram elements informally.

74. BPMN Connections
Associations are used to link artifacts such as text or data objects with flow objects.
Are depicted by a dotted line.
Can be directed or undirected.
They can be used to show inputs and outputs of activities.

75. Order Management example (ctd.)
Let’s have a look at some artifacts...
The Purchase Order document serves as an input to the stock availability check. Based on the outcome of this check, the status of document is updated, either to “approved” or “rejected”.
Include the relevant documents in the process model. Also, for visualization purposes, all parts of the processes that use or update the purchase order should be highlighted.

76. Order Processing Model with Artifacts

77. BPMN Exercise 3: Artifacts
The report related to the car accident is searched within the Police Report database and put in a file together with the claim documentation. This file serves as input to a claims handler who calculates an initial claim estimate. Then, an action plan is created based on a checklist available in the Document Management system. Based on the action plan, a claims manager tries to negotiate a settlement on the claim estimate. The claimant is informed of the outcome, which ends the process.
Please depict all relevant documents in the model. Also visualize activities that are performed by the claims handler.

78. Part III
BPMN Continues

79. BPMN Main Elements - Recap
Swimlanes
Connections
Flow Objects
Artifacts
Check the BPMN Poster:

80. BPMN Flow Elements – Recap

81. BPMN Gateways – Recap
Exclusive (XOR)
Exclusive decision take one branch
Exclusive merge Proceed when one branch has completed
Parallel (AND)
Parallel split take all branches
Parallel join proceed when all incoming branches have completed
Inclusive (OR)
Inclusive decision take one or several branches depending on conditions
Inclusive merge proceed when all active incoming branches have completed

82. Example: Exclusive and Parallel Gateways

83. Example: Inclusive gateways

84. Alternative: Conditional flows

85. BPMN Exercise 4
Map the following process fragment using inclusive gateways and/or conditional flows:
When a claim is received, it is registered. After registration, the claim is classified leading to two possible outcomes: simple or complex. If the claim is simple, the policy is checked. For complex claims, both the policy and the damage are checked independently.

86. Complex gateways
Sometimes, it is not necessary to wait for all active branches to complete:
In an order placement process, a quote is sought from two preferred suppliers in parallel. As soon as one of them provides a quote, the order placement process may proceed. The second quote, if any, is ignored.

87. Complex gateway example

88. Sub-processes
A task in a process can be decomposed into a “sub-process”.
Use this feature to:
Break down large models into smaller ones, making them easier to understand and to explain
Identify parts of a process model that should be:
repeated
executed multiple times in parallel
cancelled, or
compensated.

89. Sub-processes: example

90. Fragment of the SCOR model
Process hierarchies
Fragment of the SCOR model

91. Repeated Subprocess: Example
PO Protocol taken from
A customer sends a purchase order (PO) and expects to receive a “PO response”. In the “PO response”, each line item is marked as “accepted”, “rejected” or “pending”. If some line items are left pending, the customer expects to receive a “PO Update” later. Again, this “PO Update” marks line items as “accepted”, “rejected”, or “pending”. If some line items are left pending, the customer waits for another PO-Update, and so on until no line items are left pending.

92. Alternative: Arbitrary cycles
Another way of capturing “repetition” is through “cycles”
Choice between looping or cycles is often a matter of taste, but if it is possible to meaningfully cluster the activities to be repeated as a sub-process, looping is more suitable.

93. Exercise 5: Repetition
After a claim is registered, it is examined by a claims officer. The claims officer then writes a “settlement recommendation”. This recommendation is then checked by a senior claims officer who may mark the claim as “OK” or “Not OK”. If the claim is marked as “Not OK”, it is sent back to the claims officer and the examination is repeated. If the claim is OK, the claim handling process proceeds.

94. Event types

95. Event types (cont.)

96. Modelling with events - Example
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.
Anytime during the process, the customer may send a “PO change request”. When such a request is received, it is just registered, without further action.

97. Modelling with events - Example

98. Event-based decision
With the XOR-split gateway, a branch is chosen based on expressions that evaluate over available data
 The choice can be made immediately after the incoming flow fires
Sometimes, the choice must be delayed until something happens  choice is based on a race between events
This is why BPMN distinguishes data-driven and event-driven XOR-splits

99. Event-based decision – Example
After a purchase order is sent, a customer can receive either a “PO Response” or an error message. It may happen that no response is received at all. If no response is received after 24 hours or if an error message is received, the purchasing officer should be notified. Otherwise, the PO Response is processed normally.

100. Event-based decision – Example

101. Exercise 5
In the context of a claim handling process, it is sometimes necessary to send a questionnaire to the claimant to gather additional information. The claimant is expected to return the questionnaire within five days. If no response is received after five days, a reminder is sent to the claimant. If after another five days there is still no response, another reminder is sent and so on until the completed questionnaire is received.

102. Exception handling
Exceptions are events that deviate a process from its “normal” course
Handling exceptions often involves stopping a sub-process and performing a special activity
Achieved using two event nodes:
An “end error event” that stops the enclosing subprocess execution
An “intermediate error event” attached to the enclosing subprocess – this is where the process execution will continue after the error

103. Exception handling – Example
Consider the previous “PO Change Request” example with the following variation: When a PO Change Request is received, it is first checked to determined if it can be accepted. If it is accepted, any processing related to the PO must be stopped. The PO change request is then registered. Thereafter, the process proceeds as it would after a “normal” PO is registered.

104. Exception handling – Example

105. Exercise 6 Extend the claim handling process as follows:
After checking the insurance policy, a possible outcome is that the insurance is invalid. In this case, any processing is cancelled and a letter is sent to the customer. In the case of a complex claim, this implies that the damage checking is cancelled if it has not yet been completed.

106. Modelling conventions
Why use modelling conventions?
To reduce variety
Increase the comparability of models
Support the analysis (with clear syntax, sematic and layout standards)
Acceleration and simplification (just start and ‘Go’) …
Different types of modelling conventions?
Organisational level
Project level

107. Modelling Guidelines Typical categories of guidelines:
Naming conventions for processes, tasks and events
Guidelines for layout and usage of tasks, events, lanes and pools
Process elements “to be avoided”

108. Naming conventions for processes and tasks
Names should be 1-3 words long
Begin with a verb followed by business object name and possibly an adjective (e.g. Issue Driver Licence, Renew Driver Licence via Offline Agencies)
Avoid generic verbs such as Handle, Record…
Avoid prepositions (to, from, for)
Avoid naming business areas which are already named in a lane/pool

109. Verbs to avoid
Update, Create, Read, Delete, Record, Download, Transmit: Too technical. Try Amend, change, generate, retrieve, remove, capture, register, forward
Send: Could merely be a message flow from one business process to another.
Process, Handle, Manage: Too generic, would not reflect the specific objective of the process. Try disseminate, distribute, etc.
Input: Why do we have to input data? Maybe there is an opportunity for process optimisation here…

110. Naming conventions for events
For start/intermediate message events: indicate what is being sent or received (e.g. Invoice Received)
For end message events indicate what is being sent (e.g. Order Sent)
For time events, indicate frequency or deadline, e.g. Monthly, Weekly, Invoice Due.
Event names (except for timer events): should begin with a noun followed by a past participle

111. Usage and layout guidelines
A task must always have at least one incoming and one outgoing flow
Input flows should come from the left or from the top
Output flows should come out of the right or the bottom
A process model should contain at least one pool
Pools must be laid out horizontally
A pool may appear multiple times in a diagram to improve presentation, but the name of the repeated pool must be italicised.
Use link events to split large diagrams across multiple pages

112. Homework (10 points) See homework in course web page:
Can be completed in teams of up to 4 members
To be submitted by by 14 March at 9:00am (hard deadline)