Introduction to BPMN

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

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

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

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

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: “E-mail received”, “3 o’clock”, “Warehouse empty”, “Critical error”, ...

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

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

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 …

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.

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”, ...

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”, “E-mail message”, “XML document”, ...

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.

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.

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.

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

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

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

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

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 + + +

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

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)

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

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

BPMN Patterns: Resources Workflow patterns from Stephen A. White paper “Process Modeling Notation and Workflow Patterns” Available from http://www.bpmn.org/ 2. BPMN patterns from Bruce Silver article series “BPMN and the Business Process Expert” Available from https://www.sdn.sap.com/irj/sdn/wiki?path=/display/BPX/Process+Modeling+with+BPMN+Article+Series

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

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

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

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

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

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

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

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

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

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

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

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

Timer and Message Event Patterns

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

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

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

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

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

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

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

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 …

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

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 +

The End Questions?