This document provides an overview of business process management and modeling techniques. It begins with recapping principles of BPM from the previous session. It then discusses why process decomposition and exception handling are important. The remainder of the document focuses on Business Process Model and Notation (BPMN) including flow objects, connection objects, artifacts, events, functions, naming conventions, and common modeling structures like EPC, VACD, and FAD. It emphasizes using BPMN to clearly communicate business processes and the importance of hierarchy and rules in process modeling. Sample organization charts and process models are also included.

1. BUSINESS PROCESS MANAGEMENT
SESSION 2 - BPMN
<V1.0>

2. 1/15/2013 2
Contents
• Recap of Session 1
• Why a Process Decomposition
• Exceptions
• BPM Notations
• Model Structure
• Samples

3. 1/15/2013 3
Recap of Session 1

4. 1/15/2013 4
Principles of BPM
• Organize around outcomes not tasks
• Correct and improve processes before
(potentially) automating them
• Establish processes and assign ownership
• Standardize processes across the enterprise
• Enable continuous change
• Improve existing processes, rather than build
radically new or ‘perfect’ processes

5. 1/15/2013 5
Business Drivers of BPM
• Perceived or Expected Benefits:
• Reduce staff and office overhead
numbers
• Process business critical activities
faster
• Reduce the number of errors and
exceptions
• Reduce overall IT costs
• Reduce duplications
• Increase visibility into operational
efficiencies and bottlenecks
• Reduce business risks
• Improve customer service and
retention

6. 1/15/2013 6
Why Model Processes
Understand and control existing processes
Measure time, cost and resources needed to
existing processes
Improve current processes
Streamline, identify missing process steps,
rationalize existing processes
Design new processes
Realize business requirements and design new
processes
Based on changing business environment, new
processes may be needed
Communicate existing and new processes
Automate processes

7. 1/15/2013 7
Charting v/s Modeling
• Flowcharting creates a graphical representation of the
sequence and key elements of a business process
• Process modeling extends this by
• Mapping dependencies and related flows
• Adding data intelligence to the steps
• Enabling simulation of flows to check for efficiencies and
bottlenecks
• Enabling reuse of mapped chart elements
• Supporting future monitoring of improved processes

8. 1/15/2013 8
Process Levels
WHAT
HOW

9. 1/15/2013 9
BPM Life Cycle
Design
Re-
Modeling
Engineering
Business
Process
Management
Optimizatio
Execution
n
Monitoring

10. 1/15/2013 10
Important thing to remember
Make Processes ASAP
ASAP = AS SIMPLE AS POSSIBLE
This helps maintain AGILITY and reduce RISK
MANAGEMENT

11. 1/15/2013 11
Do you have visibility into your processes and corporate objectives?

12. 1/15/2013 12
Why a Process Decomposition

13. 1/15/2013 13
Process Decomp
• Process Decomposition is the break up of a process to
activity level
• Every project should have a Process Decomp
• Process Decomp helps at later stages when improvisation
has to be implemented
• Process Decomp keeps a running score of all the
processes under a function

14. 1/15/2013 14
Example of a Process Decomp

15. 1/15/2013 15
Exceptions

16. 1/15/2013 16
Exception Handling
• Always account for Exceptions, business is not a blue sky
scenario – there are always exceptions in every process
• Exceptions have to be handled – we have to define the
process to resolve the exceptions
• If you don’t find Exceptions in the process – somebody
has not shared info or something’s not right

17. 1/15/2013 17
BPM Notations

18. 1/15/2013 18
BPM Notations
• BPMN helps to explain business processes both internal
and external through a Business Process Diagram.
• BPMN helps organizations the ability to communicate the
processes in a standard manner.
• BPMN helps to bridge the understanding ‘GAP’ between
various departments internal / external. For example the
gap in understanding business processes by IT
developers

19. 1/15/2013 19
Flow Objects
• Flow objects define the behavior of the
Name
process
• Flow Objects are
• Activities – are the actions that are carried out Activity
as part of business
Name
• Event – are the process triggering objects that
affect the flow of the process and have a
cause and a result
Event
• Gateways – are the controlling objects that
diverge or converge the flow Name
Gateway

20. 1/15/2013 20
Connection Objects
• Connections are used to connect two or
more objects in a process
• Connection Objects are
Sequence
• Sequence Lines – to show in which order the Flow
activities are performed
• Associations – are used to associate a role, text,
Association
artifact to a flow object
• Message Lines – represents how message flows
between the objects Message Flow

21. 1/15/2013 21
Artifacts
• Artifacts are
• Group – to put similar activities under a Group
group
• Annotations – are used to proved additional
text information Text Annotation
• Data Objects – are used to show how data
is required or produced at each step

22. 1/15/2013 22
What is an Event
• An Event is something that happens during the course of a
business process and affects its execution
Event
• An Event has a CAUSE and an IMPACT
• All activities are triggered by an Event. for example purchase
order received. This is an Event

23. 1/15/2013 23
3 Stages of Life of an Event
• Events have Three stages
• Start Event - begins the process
• Intermediate Event - these happen during the process, between Start and
End Events
• End Events - terminate the event
If we use a tool like ARIS, we can avoid the multiple notations by
using the standard Event notation

24. 1/15/2013 24
Naming Convention - EVENT
• An event marks the beginning and end of any process.
• It’s a trigger that initiates the process.
• Each process should start with an event and end in an event.
• It indicates the changing state of the world as the process
proceeds.
• Events usually follow functions unless they are trivial and do
not convey anything significant.
• Events describe the function is completed.
• Events do not indicate the next function.
• The convention for an event is Noun-Verb, written in simple
past tense. For example: Order Entered or Price Calculated.

25. 1/15/2013 25
What is an Function
• Functions indicate the tasks or activities that are carried out in
the business process.
Function
• Functions have inputs (material or information) and outputs
(different material or information) and usually utilize
resources. Thus, they are carried out by either people or
systems.
• Functions should not convey unambiguous information to the
reader; it should be specific and convey the right information.
The usage of short forms such as ent. instead of enter should
be avoided.

26. 1/15/2013 26
Naming Convention - Function
• The convention for a function is Verb-Noun. For example: Enter Order
or Calculate Price.
• It is written as Action (such as Enter, Calculate) followed by the
Information Item (such as Order, Price).
• The function is to be written in active voice, do not write the Functions
in passive voice, for example
Route Planning is
Done Plan the Route

27. 1/15/2013 27
Naming Convention - Function
• Activity is a piece of work performed within a business
process.
• There are two types of Activity
• Tasks - is atomic within a business process. For example Take Order
• Sub Process - an activity that can be decomposed into other smaller
activities. For example Generate Bill, this is when you take the items
ordered list, check the price, apply promotions, apply other discounts
• As a rule - Sub Processes ALWAYS begin with a NONE
START EVENT and end with a NONE END EVENT

28. 1/15/2013 28
Naming Convention - Function
• Functions are activities that have to be carried out, do not
word them as Events (outcome in past tense).
• For example,
With Authorization Cancel SO after
SO is cancelled Authorization

29. 1/15/2013 29
BPMN Notations

30. 1/15/2013 30

31. 1/15/2013 31
Rules
• ARIS has three basic rules: AND, XOR & OR.
• While XOR & OR are used in making decisions, AND is
used to split and join branches.
• When to use the three rules, depends on whether they
follow or precede the function.

32. 1/15/2013 32
OR Operator
OR Following a Function OR Preceding a Function
Single Input – Multiple Output Multiple Input – Single Output
OR Decision OR Trigger
One or many possible paths will be Any one Event, or combination of Events,
followed will
as a result of the decision trigger the Function

33. 1/15/2013 33
XOR Operator
XOR Following a Function XOR Preceding a Function
Single Input – Multiple Output Multiple Input – Single Output
XOR Decision XOR Trigger
One, but only one, of the possible paths One, but only one, of the possible Events
will will
be followed be the trigger

34. 1/15/2013 34
AND Operator
AND Following a Function AND Preceding a Function
Single Input – Multiple Output Multiple Input – Single Output
AND Branch AND Branch Trigger
Process flow splits into two or more All Events must occur in order to trigger
Parallel the
paths following Function

35. 1/15/2013 35
Split Rule
• To join back the branches split by a rule, use the same end object
(event/function) on all the split branches preceding the rule.
• The object (event/function) following the join must be different from the
one used preceding the join. For eg., if there are events preceding the
join, the object that follows after the join is a function and vice-a-versa, as
shown below:

36. 1/15/2013 36
Do’s and Don’ts
• Avoid OR/XOR following an Event.
• Functions taking the decision are always followed by Rules. AND split
is usually made after an Event and recombined after events, though
you can recombine and then insert a single event at times.
• The “Join” should be made using the same Rule that was used for the
“Split”.
• Avoid “Do Nothing” paths, shown below:

37. 1/15/2013 37
Artifacts
• BPMN provides three Artefacts that help
us to add extra information to the models
WHERE
WHAT WHO
• Text Annotation - text added to the diagram
to increase understanding
• Group - a way to group together parts of a
process
• Data Objects - Way to show data and
documents that are changed by the process
Always attach Notes, RASCI to the key functions for
traceability

38. 1/15/2013 38

39. 1/15/2013 39
Model Structures

40. 1/15/2013 40
Introduction to Model Structure
• Tools like ARIS provide more than 150 pre-defined
models to work with
• The models available are
• EPC: Detail modelling of processes at various levels of hierarchy
• FAD: For defining the relationship between a Function and the
resources needed to execute it and the data it transforms
• Organization Chart: A hierarchical model of the business
organization
• Technical Terms Model: Models the hierarchical and relational
structure of information used by the business
• Value Added Chain Diagram (VACD): Models a hierarchy of high-
level functions that add value to the business along with the
organizational units that have a role in those functions

41. 1/15/2013 41
EPC – Event Driven Process Chain
• EPC’s are an accurate representation of the real world
• Important rules to bear in mind when constructing an EPC:
• Every EPC model should have a start event and an end event. The
models cannot start or end with a function.
• Functions and events alternate. Avoid connecting functions to functions,
except at times when the events are trivial and do not convey something
significant and could be skipped. Events should never connect to events.
• Avoid bringing-in additional Events/ triggers in middle of a process; it
leads to lots of interconnections and confusion. Check whether the process
is really dependent on this trigger in order to proceed or if this Event could
lead to triggering a separate new EPC.
• A function or event can have ONLY ONE arrow coming in and/or going
out. Whereas, Rules/ connectors such as XOR & OR can have either:
• Multiple incoming connections and a single outgoing connection
• A single incoming connection and multiple outgoing connections
• Connectors cannot have multiple incoming and outgoing connections.

42. 1/15/2013 42
VACD – Value Added Chain Diagram
• The VACD represents a high-level view of the functions that add value to
a business and the rough order in which they proceed. In addition to the
rough process flow, we can also represent some of the high level
hierarchy associated with these functions.
• The main objects in a VACD are functions, but with a different symbol as
compared to those used in the EPC.
Function Function
In EPC In VACD
• But you can copy and paste theses functions back and forth between
VACD and EPC, the symbol will automatically change depending on the
model in which they are used.
• The difference is that the functions in a VACD are connected together
• without intervening events or rules.

43. 1/15/2013 43
FAD – Function Allocation Diagram
• Function Allocations in the Event-Driven Process Chain
(EPC) models enable the EPC to be put in context with
the resources required to deliver the process and the
environment in which it operates.
• Thus, FADs can be assigned at the right places in the
process (but only to functions), to indicate the relationship
between the Business Process and environment/
resources such as organization, systems, documents and
technical terms as shown below.

44. 1/15/2013 44
FAD
Relationship between Function and its environmental
components and resources

45. 1/15/2013 45
Incorrect FAD
Customer Service Advisor
is a position in the Sales
Department and it is
incorrect to show both
responsible for the
function

46. 1/15/2013 46

47. 1/15/2013 47
Model Hierarchy
• The models to be used for these 4 levels are:
• Level 1- VACD
• Level 2- VACD
• Level 3- VACD supported by FAD to model RACI, Risks, SOP, KPI
• Level 4- EPC or VACD
• Level 5- EPC (where level 4 is a VACD)

48. 1/15/2013 48
Level 1 Process - VACD
• Also known as MEGA Processes

49. 1/15/2013 49
Level 2 Process - VACD
• Level 1 – Buy Process is decomposed into Level 2
• Introduce Assortment
• Master Data Maintenance
• Vendor Management Strategy

50. 1/15/2013 50
Level 3 Process – VACD can be
supported by FAD
• Level 2 – Introduce Assortment Process is decomposed
into Level 3
• Construct Assortment and Planogram
• Edit Assortment and Planogram

51. 1/15/2013 51
Level 4 Process – VACD can be
supported by FAD
• Level 3 – Construct Assortment and Planogram Process
is decomposed into Level 4
APPLICATIO
N ROLES

52. 1/15/2013 52
Level 5 Process
• Level 5 is modelled using an EPC.
• This is an optional level which can be used when the 4
Levels are not enough to decompose the process to the
desired detail.
• If there is a Level 5 in the process decomposition in that
case level 4 has to be a VACD.

53. 1/15/2013 53
SAMPLES

54. 1/15/2013 54
Organization Structure in ARIS

55. 1/15/2013 55
VACD
Value Added Chain Diagram

56. 1/15/2013 56
Order Booking Process in ARIS

57. 1/15/2013 57
EPC
Event Driven Process Chain

58. 1/15/2013 58
Recap
• Processes generally begin with an Event and flow through
to Business Results
• All tasks / activities are assigned to a ROLE
• A model should display how data / objects are transferred
and where they are going
• Process can be modeled in a hierarchical manner – sub
processes

59. 1/15/2013 59
Assignment
• Business Scenario
• The company is into selling Furniture
• Company sells through Store, Catalogue, Online
• Customer books order, pays and await delivery
• Customers can call the call center for
• Quotes
• Delivery Updates
• Installation appointment
• Complaints
• Returns
Create a Process Decomp for this business – Level 4

60. 1/15/2013 60

61. 1/15/2013 61
Please contact:
Session 3
Process Design Naval Vithalani
Process Cost Analysis tonaval@yahoo.com
Process Optimization
Session 4 Thank You
ARIS - Introduction