Business analysts and developers new to BPM sometimes struggle with the art of discovering, modeling, understanding and explaining business processes.
(If you are going to Oracle Open World 2014 next week, drop by our booth at Moscone South #624 and we will give you AVIO’s laminated job aid that describes the different BPMN artifacts that Oracle BPM 11g and 12c use.)
BPM Process patterns use these artifacts to provide a time proven and simple technique to shorten the learning curve and improve productivity and quality of the processes designed. The patterns described here were created using Oracle BPM’s BPMN process modeling tool.
Process patterns are example fragments of processes that show how to connect activities together to solve various and common workflow problems. Like words that are combined to form sentences, these patterns are combined to form complete processes and illustrate some of the best thoughts on modeling business processes today. Professor Wil van der Aalst’s Workflow Patterns article written in 2002 noted that processes have common and reusable patterns. These process patterns are broken down into these six categories that gradually grow in complexity:
- Procedural Patterns
- Advanced Branching and Synchronization Patterns
- Structural Patterns
- Multiple Instance Patterns
- State Based Patterns
- Cancellation Patterns
Procedural Patterns
Sequence Pattern
This is the most common and obvious of all the patterns. When business analysts begin to model the way things work today (“As-Is” process) usually much of the process looks like activities strung together in a series. Instances (individual items of work flowing through the process) step through the activities one by one.
In this example individuals in the Account Manager role review the orders going through the process. Once reviewed, Finance Clerks then check the credit and then Warehouse Clerks check the inventory to ensure the items are in stock.
Although most processes contain at least one sequence pattern, a recommended practice during process walk-through sessions is to question the use of this pattern before it makes it into the BPM production (“Should Be”) process for three reasons.
- If activities are done one after the other, the amount of time it takes to accomplish the three activities can be quite long. The activities may be able to be done simultaneously in parallel (discussed later in the Parallel Split pattern).
- Each activity might have many other sequence flows (lines) coming out of them to handle different business rules. For example, during the process walk-through ask, “What happens if the customer’s credit check fails?”
- The third question that should be asked when you see this pattern is “Do all account managers really need to see all the orders to be reviewed?” The reason this is an important topic of discussion during a process walkthrough is because most BPM implementations use a shared queue as the default. All account managers would indeed see all the orders unless the specific account manager assigned to the order was designated upstream of the Review Order activity.
Exclusive Choice Pattern
Every activity in the process should be examined to see if there might be more than one sequence flow leaving it. As an instance leaves an activity, it normally exits through one and only one sequence flow leaving the activity.
As shown in this example, it might be determined that there are two paths that could occur after the “Credit Check Ok?” Exclusive Gateway (yes or no). Depending on the credit score found in the Check Credit activity, the instance either flows to the Check Inventory (passed the credit check) or Notify Customer activity (failed the credit check).
The Business Process Modeling Notation (BPMN) standard shown here uses the Exclusive Gateway to represent the beginning of the Exclusive Choice pattern.
As shown below, there can be many sequence flows representing many different business rules leaving a single Exclusive Gateway. In this insurance claim process, the Exclusive Choice pattern indicates a single insurance claim cannot be both an “Auto” and a “Renter” insurance claim. Instead it means that the claim can be either an “Auto” or “Renter” or “Home” or “Life” insurance claim. The instance leaving the Exclusive Gateway goes through only one of the sequence flows.
Note the “Handle Exception” activity in the Supervisor role. A recommended practice is to have a default “unconditional” sequence flow leaving one of these activities. This is the sequence flow taken if none of the business logic inside the activity’s conditional sequence flow are true.
In the Exclusive Choice pattern shown below, the sequence flow to the “Handle Unknown Claim Type” activity is important. Even the most experienced business analysts cannot predict when new data might cause none of the conditional sequence flows to fire – resulting in a process bottleneck. The one unconditional sequence flow leaving an activity keeps this from occurring. If none of the conditional sequence flows are taken, the instance will always flow through the one unconditional sequence flow. If there are many conditional sequence flows leaving an activity, always use the one unconditional sequence flow as an error handling activity.
Simple Merge Pattern
The power of patterns in a process becomes clearer when one pattern combines with others to form processes. Simple Merge is one of the many examples of this. Anytime an Exclusive Choice pattern occurs, somewhere downstream in the process there will almost always be a Simple Merge pattern. Simple Merge combines several sequence flow back into a single activity or gateway.
As shown in the example the “Close Claim” activity merges the sequence flow coming into it. The insurance claim instance coming into it came from only one of the activities upstream in the process.
Parallel Split and Synchronization Pattern
If parts of the current “As-Is” process look like the Sequence pattern shown below, evaluate the process to see if it can be improved using a Parallel Split and Synchronization pattern. For example, if the first, second and third activities in a sequence of activities take 2, 3 and 4 hours respectively, the total time elapsed time to execute all three activities is 9 hours (the sum of the individual activity times).
An improved “Should-Be” process might be able to use the Parallel Split and Synchronization pattern to speed up the process.
In this example, an Exclusive Gateway activity was used to simultaneously ensure:
- an order can be reviewed (taking 2 hours), while
- the customer’s credit is being checked (taking 3 hours), while
- the inventory for the items ordered is being checked (taking 4 hours).
Instead of taking 9 hours, the order now takes the 4 hours to complete the three activities (the longest of the three activities in the parallel paths). The Parallel Split and Synchronization pattern speeds up the process by having the instance travel all the parallel paths through it simultaneously. The order the activities execute is not important in this pattern.
Using the above example, an instance might execute the activities in the process in any one of these sequences:
|
(a) Check Inventory |
(b) Check Credit |
(c) Review Order |
|
(a) Check Inventory |
(b) Review Order |
(c) Check Credit |
|
(a) Check Credit |
(b) Review Order |
(c) Check Inventory |
|
(a) Check Credit |
(b) Check Inventory |
(c) Review Order |
|
(a) Review Order |
(b) Check Credit |
(c) Check Inventory |
|
(a) Review Order |
(b) Check Inventory |
(c) Check Credit |
This execution of activities in any order is sometimes referred to as an Interleaved Parallel Routing.
If one activity must be done before another, the two activities can still be placed sequentially in one of the parallel branches of this pattern.
As shown above, an order’s shipping charge now can only be calculated after it has been reviewed.
Advanced Branching and Synchronization Patterns
Multiple Choice and Synchronizing Merge Patterns
Conditional sequence flows play an interesting and important role in a Parallel Split patterns when Inclusive Or Gateway activities are used.
In the above example the middle sequence flow going to the Check Credit activity was changed to a conditional sequence flow. Now the instance will flow to the Check Credit activity during runtime only if the order is a credit order. Because the other two sequence flows going to Review Order and Check Inventory must always be taken the logic in the conditional sequence flows going to these activities needs to be set to true.
In the example there are 4 sequence flows coming into the Join activity at the bottom. The sequence flow shown on the left with the hash mark through it is the one mandatory unconditional transition that always comes out of an Inclusive Or Gateway. This transition is taken only if all of the conditional sequence flows (the ones going to Review Order, Check Credit and Check Inventory) evaluate as false.
The default behavior is to have the instance not continue beyond the Join activity until all the valid sequence flows leaving the Split activity reach it. This marshaling point is called a Join or Junction activity. Once again, suppose that the order is not being paid using credit. During runtime, the BPM server automatically detects this and knows to wait for only 2 out of the 3 sequence flows coming into the Synchronize activity (the sequence flows coming from the Check Inventory and Calculate Shipping Charge activities) before continuing. If the order is being paid by credit, the Synchronize activity will automatically wait for all three sequence flows during runtime.
Discriminator and N-out-of-M Join patterns
The Parallel Split and Synchronization pattern can be extended to offer some flexibility as the sequence flows marshal in the Complex Gateway activity shown here.
In this example, if an order’s credit check fails, there is probably no need to wait for the sequence flows coming from either the Check Inventory or Calculate Shipping Charge activities. If the credit check fails, an indicator can be set in the Check Credit activity so that once it reaches the Complex Gateway activity in the process the instance is immediately released. If this occurs, the BPM Server automatically removes the instances left stuck in the Check Inventory and Calculate Shipping, and the instance immediately continues on through the rest of the process.
Multiple Merge Pattern
Any branch leaving the Split activity in a Parallel Split and Synchronization pattern can be merged back into a single sequence flow before it reaches the Join (Complex Gateway) activity. In the example below, the Calculate Shipping Charges activity serves as a merge activity and three of the four sequence flows go through this activity before continuing on to the Complex Gateway activity. Note that an Exclusive Gateway was added to ensure that the shipping charges were not calculated if the credit was not ok.
Structural Patterns
Arbitrary Cycles Pattern
When discovering an “As-Is” process, you sometimes hear “We currently are able to go from any activity to any other activity in the process.” It is tempting to carry this forward into the “Should-Be” design. End-users sometimes appreciate that they will continue to work ad hoc. Work done upstream in the process does not have to be done particularly well or checked for completeness because it can always be “fixed” later by returning the instance back upstream.
Sequence flows headed back upstream should be closely examined because:
- Instances take longer to complete the process – chances of streamlining and improving the process are greatly reduced.
- This might indicate a root problem upstream that should be resolved.
- This discourages the consistent and organized best practice execution of processes that BPM is meant to enable. This process pattern is more of a democracy than a process.
Collaboration Pattern
Sometimes there are valid business reasons to send the instance back upstream. Collaboration patterns are quite common in BPM processes.
Here the instance continues in a loop until the purchasing agent decides the negotiations are over either because they have the lowest price possible or they decided to purchase from another bidder.
Implicit Termination Pattern
The End events are sometimes seen as a funnel out of the process to do a final merge of the various sequence flows.
Although this can sometimes be the case, the Implicit Termination pattern provides an alternative to forcing sequence flows directly through an End event. This is sometimes necessary because a process might need to reach the End event from many activities in a process.
The Terminate End event shown above is especially useful inside Parallel Split and Multiple choice patterns. Instead of merging to the Join activity, if one of the paths flows to a Terminate End event, the instances in the other paths are also automatically terminated.
Multiple Instance Patterns
The patterns discussed to this point all deal with a single instance throughout the life of a process. Suppose now that each instance of a process handles a batch of insurance claims. Sometimes instance batches contain 40 claims and sometimes they contain 4000.
Multiple Instances without Synchronization Pattern
This pattern takes a batch job and processes each individual item in it without worrying about synchronizing them back into the process. It is usually modeled as shown below using the Subprocess’s Multi-Instance loop characteristic designated by the three horizontal bars at the bottom of the Subprocess activity.
Here, depending on the number of claims in a job, the Subprocess activity is set to handle multiple instances. It simultaneously parses each claim and each claim is then individually sent without synchronization (asynchronously) to a web service activity. While and individual claim is sent to the web service, the context in the parent process the original batch job. For every claim in the batch job, a new instance is created in the Subprocess activity. Although there is just the one sequence flow drawn leaving the Split-N activity, the power of this pattern rests in its ability to dynamically spawn new instances based on something known only at runtime (number of insurance claims in the batch job in this example).
Multiple Instances with Design and/or Runtime Knowledge Patterns
Processes often need feedback from the instances spawned by the Multi-Instance Subprocess activity. In this example, a purchasing agent decides at runtime how many suppliers will be allowed to bid. This number is used in the Multi-Instance Subprocess activity to spawn that number of instances in the synchronous Request Quote from Supplier subprocess call activity. As each supplier bids in the child subprocess, the bid information is carried back into the Multi-Instance Subprocess activity.
When the same number of bids reach the number specified in the Pick Number of Bidders activity, the instance continues on and the bid is awarded to a supplier. In this example the bids of the individual suppliers are compared and the contract is awarded to the lowest bidder in the Award Contract to Lowest Bidder activity.
State Based Patterns
State based patterns show how to receive notifications from events outside the process and how to set Service Level Agreements (SLA) for activities in a process.
Deferred Choice Pattern
Processes sometimes need to wait for an event outside the process to occur before continuing.
These events are fired from:
- Notifications from other processes currently running and
- Notifications from outside applications or web pages. This friction built into the process is handled using an activity called a Message Catch event.
In this example, the instance in the process will remain in the Wait for Supplier Ok activity until it has been notified from outside the process. The event causing the notification sends in information in this example to let the process know if the product was in stock. Based on this, the instance will travel through either the conditional sequence flow to the Request Substitution activity or the unconditional sequence flow to the Sign Contract activity.
Milestone Pattern
Sometimes, a Timer Event can help keep a process instance moving along. Think of the Milestone pattern as a way to set an SLA for an individual activity. If an instance sits too long in the activity, it is automatically transitioned through the sequence flow another activity.
Here the purchasing agent will award the contract to the lowest bidder if either one of two things occurs:
- All of the spawned requests for bids are completed in the Multi-Instance Subprocess activity or
- If not all the suppliers have placed their bids, the Timer Catch event (note the clock on the right edge of the Multi-Instance Subprocess activity) times out after the designated time interval.
Timer Catch events are sometimes used when Parallel gateways, Inclusive gateways, synchronous subprocess invocations and Message Catch events might cause bottlenecks in processes.
Cancellation Patterns
One of the things quickly discovered when delivering a BPM solution is the need to cancel instances in individual activities and the process as a whole.
Cancel Activity Pattern
Individual activities can sometimes create bottlenecks in a process. This can cause a problem in a process if the activity causing the bottleneck cannot be accessed by participants of the process. In this example, the Wait for Supplier OK catch event has no human interaction and is waiting for an external notification that might never come.
Adding a Discriminator and N-out-of-M Join pattern helps solve this problem for individual activities. The upper leg inside the Parallel/Complex gateway in this example has the sequence flow with the long running activity with no human interaction. The lower sequence flow was added here to:
- Give the Purchasing Agent the chance to view the bids that are pending in the upper leg and
- Allow the Purchasing Agent the chance to cancel any orders that are pending in the upper leg. Once the clerk cancels an instance, it reaches the Join activity. The instance is removed from the Wait for Supplier Ok activity and it continues on through the rest of the process.
Cancel Case Pattern
Customers can call at any time and cancel their entire order no matter where the instance is located in the process. A cumbersome way to handle this is to have cancellation sequence flows in each activity of the process leading to the End.
Instead, consider this pattern. Here the Event Subprocess appears to not be part of the process flow. Once a message is received that initiates the subprocess, it interrupts the instance in any activity of the process and direct it immediately to the Cancel Order activity. Notifications cause instances sitting anywhere in the process (Review Order, Check Inventory or Ship Order) to immediately and automatically move to the Customer Cancellation activity. Sequence flows do not need to be drawn to this type of activity.