1. Introduction to BPMN

2. Standard communication language
Why Do We Need BPMN?
Standard communication language
Reuse/availability of knowledge, resources, tools
Consolidate models …
Graphical notation
A picture is worth a thousand words!
But you cannot draw a picture for any thousand words!
Allows visualization of XML-based business process descriptions, e.g. BPEL4WS

3. BPMN stands for Business Process Modeling Notation.
What Is BPMN?
BPMN stands for Business Process Modeling Notation.
BPMN provides a standardized language that is readily understandable by all stakeholders
Business analysts that create the initial drafts of the processes;
Excellence people who monitor and optimize those processes;
Developers responsible for implementing systems.
BPMN defines business process modeling diagram, its symbols, their meaning and composition rules.
Language: semantics and meaning, simplify language to be accessible to business people

4. BPMN Scope
BPMN will be constrained to support only the concepts of modeling that are applicable to business processes.
BPMN does NOT cover:
Organizational structures and Resources
Functional breakdowns
Data and information models
Strategy
Business Rules
These can be covered in additional textual documents.
Mention that you should use textual documentation for overcoming BPMN limitations

5. The four basic categories of BPMN elements are: 1) Flow Objects
Event, activity, gateway
2) Connecting Objects
Sequence flow, message flow, association
3) Swimlanes
Pool, lane
4) Artifacts
Data object, group, annotation

6. An event is something that “happens” during the process
Events
An event is something that “happens” during the process
These events affect the flow of the process and usually have a cause (trigger) or an impact (result)
There are three main types of events, based on when they affect the flow: start, intermediate, and end
Events can be further specialized by trigger/result type: timer, message, link, cancel, error, terminate, …
Examples: “ received”, “3 o’clock”, “Warehouse empty”, “Critical error”, ...

7. Notation for Major Event Types
Message
Arrives from a participant and causes the process to continue if it was waiting for the message, or changes the flow for exception handling
Timer
A specific time-date or a specific cycle (e.g., every Monday at 9am) can be set or it can be used within the main flow to act as a delay mechanism
Error
Used for error handling – both to set (throw) and to react to (catch) errors.
Cancel
Used for canceling a task or subprocess, and should always be attached to the boundary of activity
Link
A mechanism for connecting end of one process to the start or intermediate event of another process
Terminate
Immediately ends all the activities in the process

8. An activity is a generic term of work that company performs.
Activities
An activity is a generic term of work that company performs.
An activity can be atomic (task) or non-atomic (compound)
The types of activities are: process, sub-process, and task
Processes are contained in the pool (one per pool)
Examples: “Send a letter”, “Write a report”, “Calculate the interest”, ...
Task/sub-process special attributes
Looping
Ad Hoc
Multiple instances
Compensation

9. Notation for Major Activity Types
Modelers can use additional annotations to differentiate:
Reusable processes vs. internal process
Human tasks vs. automated tasks (service tasks)
Risk points …

10. Expanded Sub-process vs. Collapsed Sub-process
Modelers can visualize sub-process activities on the parent process diagram inside the sub-process symbol.
Showing the details of a process with another business process diagram is more common
Expanding details should be used only for internal sub-processes
Reusable sub-processes should always be visualized as collapsed
Graphically showing the details of a process with another Business Process diagram is considered 'decomposing' the process. You can continue to decompose a process without any restriction -- creating a child diagram for a process, and child diagrams for the processes on the first child diagram, etc. Processes that you draw on 'child' diagrams are considered sub-processes. The lowest-level process, which you do not decompose further, is considered a task.

11. Gateways
A gateway is used to control the divergence and convergence of sequence flow – it will determine branching, merging, splitting and joining of paths
Examples: “Condition true?”, “Choose color”, ...

12. Types of artifacts: data object, annotation, group
Artifacts are used to provide additional information about the process.
Types of artifacts: data object, annotation, group
Examples: “A letter”, “ message”, “XML document”, ...

13. Connecting Objects
Sequence Flow is used to show the order that activities are performed in a process
Message Flow is used to show the flow of messages between two entities that are prepared to send and receive them.
Association is used to associate information and artifacts with flow objects.

14. A Pool represents a Participant in the Process
Lanes and Pools
A Pool represents a Participant in the Process
specific business entity
e.g, a company
a more general business role
e.g., a buyer, seller, or manufacturer
A lane is a sub-partition within a Pool. Lanes are often used for
Internal roles (e.g, manager, associate)
Systems (e.g.., an enterprise application)
Internal departments (e.g., sales, shipping)
Lanes are used to organize and categorize activities within a Pool. The meaning of the Lanes is up to the modeler. BPMN does not specify the usage of Lanes. Lanes are often used for such things as internal roles (e.g., Manager, Associate), systems (e.g., an enterprise application), an internal department (e.g., shipping, finance), etc. In addition, Lanes can be nested or defined in a matrix. For example, there could be an outer set of Lanes for company departments and then an inner set of Lanes for roles within each department.

15. Lanes and Pools Sample
Model the flow of events of a process in the organization, with a concentration on where the processes are performed and where the events take place in the BPMN Business Process diagram. Use 'lanes' and 'pools' to partition the model and show where (in which department or organizational unit) each event and process occurs. Each lane and pool is not only shown graphically, but also it may contain a hyperlink to information on the particular department or organizational unit, such as the roles it provides.

16. A Minimal Subset of BPMN Elements for Modeling Workflows
Keep lanes, remove multiple instance, add X notation, leave default sequence flow

17. Naming Conventions Uniqueness Naming Activities
Every name should be unique (e.g. having two elements with same name on the diagram means, that the same element is used multiple times)
Start name with the unique identifier – upper-case letter denoting element type [P|T|S|E|G|D] + sequence number (e.g. “G01 Eligible?“)
Naming Activities
Verb + (adjective/descriptor) + noun (e.g. Verify Account)
Naming Gateways and Flows
Question (e.g. “Account Eligible?”)
Answer to the question of Gateway for given outgoing Flow (e.g. “Yes”)
Naming Events
Message Name | Date / Duration | Error Name (e.g. Change Request, 1 Week, Authorization Error)
Naming Data Objects
Singular Noun (e.g. Loan Application, Loan Agreement)
General Considerations
Names should not be too long – avoid longer than 5 word names
Names should be in English – avoid local alphabet characters and special characters
Avoid redundancy in naming (e.g., do not include the word Process in the Process name)
If name consists of several words, use English title capitalization rules

18. Organizing Business Process Models
Processes should be organized by the business functions
Example business functions for organizing processes:
Customer Interactions
Channels, Operational CRM, Operational Risk Management, ...
Business Lines
Payments, Financing, Lending, Investment Management, Markets, ...
Control & Management
Business Intelligence & Business Development, Risk Management, Resource Management & Support (administration, HR, IT), ...
Business process model versions should be tracked
Major versions are published versions
Minor versions are corrections for major versions
Business process versions should contain
Top-level diagram – shows the main end-to-end flow and external entities, and
Several levels of more detailed diagrams
Textual document(s) describing process details

19. Modeling Guidelines
Processes begin with triggering start event(s), and work their way through to significant business results represented by ending event(s)
Use intermediate
Timer events for waiting for external events
Empty events for denoting states of process or involved data objects
Message events for responses from external entities
A complete model should display data objects used or produced by the activities
Avoid too many process elements – use a hierarchy of sub-processes to hide details
Keep registry of main model elements
Processes, Sub-Processes, Roles (Pools), Tasks, Gateways (Business Rules), Data Objects

20. Use pools for participants in the process (roles)
Using Pools and Lanes
Use pools for participants in the process (roles)
Whole process is in one pool (pools can be connected only with message flows)
Use lanes within a pool to organize activities + + +

21. Make your diagrams valid – BPMN has rules, follow them
Best Practices
Make your diagrams valid – BPMN has rules, follow them
Make the important information visible in the diagram
Label everything that needs to be referred
Show exception handling logic explicitly
Use tasks to represent work
Specify task types:
User (human) task
Service (automated) task
Don’t use tasks to route work between roles
Sequence flows route work to different swimlane

22. Use gateways to represent routing logic
Best Practices (cont.)
Reserve the verbs “Send” and “Receive” for activities that deal with messages (signals to and from external entities)
Use gateways to represent routing logic
Gateways do not perfrom work!
Avoid multiple start event
Use multiple end events (in sub-processes) to classify end states (e.g. Success and Failure)
Succeed the sub-process with the gateway with the outbound flows with same labels as end events
Use subprocesses to scope events (for exception handling)

23. Some BPMN Rules A single start point in each process
No “black hole” activities without outgoing sequence flows
No “miracle” activities without incoming sequence flows
Each sequence flow going from exclusive data-based OR gateway should be named by condition
Each sequence flow going from exclusive event-based OR gateway should be connected to event
Each activity should have only one outgoing sequence flow (not counting flows from attached events) …
Examples of these rules

24. Some BPMN Style Conventions
Always use gateways for choosing between alternative sequence flows or splitting an activity
Main sequence flow of activities should be
from left to right
from top to bottom
Avoid "slalom"
Clearly visualize the primary scenario
Leave alternative branches on the sides
Limit your BPM diagrams to 52 activities
Use grouping and decomposition to visualize complex processes
Focus on only the most important artifacts
Putting too much emphasis on data objects makes sequence flow obscure

25. BPMN Patterns: Resources
Workflow patterns from Stephen A. White paper “Process Modeling Notation and Workflow Patterns”
Available from
2. BPMN patterns from Bruce Silver article series “BPMN and the Business Process Expert”
Available from

26. Workflow Pattern – Sequence
A series of activities connected by sequence flows
This is the simplest and the most common pattern

27. Workflow Pattern – Parallel Split
Allows to perform activities concurrently, rather than serially
A single path through the process is split into two or more paths so that multiple activities will start at the same time
The concurrent behavior starts after the AND-split

28. Workflow Pattern – Synchronization
Combines the paths that were generated by a Parallel Split
The final set of activities within the flows must be completed before the process can continue
The process behavior gets back to sequential after the AND-merge

29. Workflow Pattern – Exclusive Choice
The flow is “split” into two or more exclusive alternative paths
Only one of the alternative paths may be chosen to continue
One of the flows going from the OR-merge is activated based on data
Typically, it is used in combination with the OR-split pattern

30. Workflow Pattern – Simple Merge
A set of alternative paths is joined into a single path
After the OR-join the activities are not based on conditions

31. Workflow Pattern – Discriminator
Another way of combining paths generated from a Parallel Split
The point where a set of parallel flows come back together
Only the first incoming flow is passed through the Discriminator OR-merge

32. Workflow Pattern – Arbitrary Cycles
Allows sections of a process to be repeated in a loop
A gateway controls whether to repeat a section or to continue

33. Workflow Pattern – Implicit Termination
Allows a specific path of a process to be concluded without ending other parallel paths
This is opposed to some notations that required the whole process to end when any end node is reached
All BPMN End Event types except Terminate end just one path

34. Workflow Pattern – Multi-Instance
Describes that a specific activity can be instantiated a known number of times in parallel
The further step needs synchronization, i.e. all activity instances should end for the process to continue with the subsequent activity

35. Workflow Pattern – Loop
Allows to repeat activity sequentially for a number of times
After the last copy of activity is done the process can continue

36. Workflow Pattern – Deferred Choice
Represents a type of exclusive decision that is based on an event that occurs during the process
Once the event occurs (i.e., the choice is made), then the other alternative paths will be disabled

37. Workflow Pattern – Cancel Activity
Describes two competing activities
When one of the activities completes, the other activity should stop

38. Timer and Message Event Patterns

39. Attached Event Pattern
Attached event means if the event occurs, interrupt the activity and proceed on exception flow
If activity completes before the event occurs, take the normal flow

40. Multiple Start Events Pattern
Starts the process differently based on the received event
The start point is followed by event-based gateway, which is followed by multiple possible events

41. Internal Business Error Pattern
The exception is detected internally by logic in a process activity that completes normally but with a bad business result
Simply follow that activity with a gateway that tests the business result
One branch out of the gateway leads to the happy path, and the other branch leads to the exception path

42. Timeout Exception Pattern
A second common exception is when a process activity is not completed by a particular date/time or after specified duration
This is timeout exception pattern based on an attached timer event
In an attached timer event, the clock starts when the activity is first enabled
If the activity completes before that duration expires, the normal flow out of the activity is enabled
If not, the activity is aborted and the flow out of the timer event is enabled

43. System Fault Pattern
A system fault means the process activity cannot complete successfully because of a technical problem
It is not the same as completing with a bad business result
Typically system faults are exceptions on automated activities, or in BPMN parlance, service tasks
An error intermediate event attached to a service task indicates the system fault pattern
Possibility to annotate things, annotate risk points, important to differentiate between automated and manual activities

44. Unsolicited External Business Exception Pattern
Uses an attached message event, which catches the signal from the external entity
If the exception signal occurs while the activity it is attached to is running, the activity is aborted and processing continues on the exception flow

45. Solicited Response Exception Pattern
An event gateway pauses the process to wait for a response
The normal response on one gate represents the happy path
An exception response, such as item out of stock, could be placed on another gate to define the exception path
No response at all within a specified timeout interval would be modeled as a timer event

46. How Can We Benefit from BPMN Modeling Tool?
Repository of reusable model artifacts
Visualize in appropriate level of details
Validate models for completeness and correctness
Process simulation
Process documentation reports
Incremental development and process optimization
Teamwork for modeling and maintaining large systems …

47. AS IS vs. TO BE Business Processes
Typically, business process should be modeled in two version
AS IS version – defines the existing process and points out the inefficient places that need to be improved
TO BE version – define the proposed new process, which includes improved (automated or reordered) parts
Typically, modelers differentiate AS IS from TO BE either by
Keeping processes in different places in model repository
Using different colors
Using graphical icon annotations

48. Top-Down vs. Bottom-Up Modeling Approach
Top-down approach should be preferred for new processes
Begin with describing the process at a high level by defining main activities (sub-processes)
Then describe sub-processes where needed
Bottom-up approach is useful for analysis of existing processes
Describe the process in details as it is
Then generalize and group activities into sub-processes +

49. The End
Questions?