Start with the business process

To discover and document the decisions within a process, you need to have a process definition to begin with. If you do not already have a process diagram for the business area of focus, you will need to initiate a process discovery workshop to discover and document the process related to the decisions that you want to discover. For example, if you are having issues with pricing of insurance policies, you will want to discover the process related to pricing policies to find the appropriate decisions. This kind of decision-driven process discovery effort can take as little as a few days of working sessions with the process owner and other process experts. It is important to also invite decision experts to the workshop to facilitate the discovery and initial documentation of the decision points within the process.

Once you begin decision discovery, you may find that you need more process information to appropriately identify the decision points. It is essential to continue to engage the process experts to expand the process until the key decision points can be highlighted.

Your decision discovery effort may also take place as part of a full scale process improvement project with the goals of process improvement and automation. This type of project involves extensive process documentation and analysis, and will likely follow a process improvement lifecycle like the one shown in Figure 3-1.

Figure 3-1 Process improvement lifecycle

As you can see in Figure 3-1, process discovery in a process improvement project consists of four stages:

1. Identify: This stage requires a few hours to interview the process owner and create the initial process definition in IBM Blueworks Live.

2. Assess: This stage requires a few days to conduct a Process Improvement and Discovery Workshop and propose a solution to the process owner and other stakeholders.

3. Document: This stage requires a couple of weeks of workshops with the process owner and participants to model the current state process and validate any integration or technical requirements.

4. Analyze: This stage involves a few more weeks of workshops to analyze the current state process and design the future state process in IBM Blueworks Live. The Analyze stage ends with a validation of the proposed solution in the form of a Playback - a formalized walk-through of the potential process solution conducted by the process owner and other process experts.

Often, in a process-driven improvement effort, it is not until the Analyze stage, during the analysis of the current state process, when the process team discovers that decisions may be an important source of the process issues. At this point, the process documentation will be at a sufficient level of detail to facilitate effective decision discovery.

For more information about discovering your business processes, see the IBM Redbooks publication Scaling BPM Adoption: From Project to Program with IBM Business Process Manager, SG24-7973.

3.1.1 Review of key process elements

There are a number of useful techniques for finding where the decisions are made in your business processes. We look at these in the next section. But before doing that, we review some of the fundamental process elements and naming conventions that you will need to pay particular attention to when applying these techniques. Processes in IBM Blueworks Live are drawn using Business Process Model and Notation (BPMN). Within that notation there are constructs to represent different elements within a process. This is not intended as a comprehensive overview of all the BPMN constructs, but merely an introduction to those constructs relevant to decision discovery.

Milestones

Milestones represent important stages within the process, as shown in Figure 3-2. Milestones are not a BPMN construct, but they are used in both Blueworks Live and the IBM Business Process Manager process definition tool, Process Designer. Activities that occur within a milestone are usually related in some way, and the entities they act upon may transform from one milestone to another. For example, an insurance application received in a milestone Application is simply an initially filled out insurance application. During the Qualification milestone, the application is validated, so it becomes a validated insurance application. Later in the process, there might be a Contracting milestone, where the insurance application is transformed into an insurance contract.

Figure 3-2 Milestone

Activities

An Activity is a task that cannot be broken down further, as shown in Figure 3-3. When naming an activity, it is important to follow a standard naming convention in the form: Action (verb) Entity (noun). For example, with this convention, Document Review means document the review and Review Document means review the document. Beware of using generic action verbs, such as perform, produce, complete, as they do not precisely describe the action taking place in the task. Without precise action names, it is hard to identify decision points in a process from task names alone.

Figure 3-3 Activity

Here is an easy formula to remember for naming your activities: Activity name = action + entity

Or:

[action verb] + [business object]

Embedded subprocess

An embedded subprocess is an activity that can be broken down further into a collection of tasks represented by a process, as shown in Figure 3-4.

Figure 3-4 Embedded subprocess

Decision tasks

Decision tasks are a special kind of activity in Blueworks Live. They are an activity that invokes a decision. In BPMN 2.0 this type of activity is known as a business rule task, and represents a task that performs some kind of automated decision, usually through calling a decision service as shown in Figure 3-5.

Figure 3-5 Decision task

Gateways

There are three types of gateways represented in BPMN: Exclusive, Inclusive, and Parallel.

Exclusive gateway

An exclusive gateway includes one or more input paths and multiple output paths. It

represents a point in the process where the process flow can continue only along one of the specified output paths. It typically represents a form of choice, the outcome of which

determines which output path to follow, as shown in Figure 3-6.

Figure 3-6 Exclusive gateway

Inclusive gateway

An inclusive gateway includes one or more input paths and multiple output paths. It

represents a point in the process where the process flow can continue along any number (one or more) of the specified output paths. It typically represents a form of choice, the outcome of which determines which output paths to follow, as shown in Figure 3-7.

Figure 3-7 Inclusive gateway

Parallel gateway

A parallel gateway includes one or more input paths and multiple output paths. It represents a point in the process where the process flow will continue along all of the output paths in parallel, as shown in Figure 3-8. A parallel gateway differs from other gateways in that it does not represent a choice. All output paths are always followed.

Figure 3-8 Parallel gateway