Being a kid of the 90s, I have fond memories of the choose your own adventure books. As much fun as those books could be, that same type of experience in process management is not ideal. Processes which are broad in scope and contain numerous exceptions quickly render themselves useless for the front line workers in the business who rely on concise and accurate knowledge to perform their jobs well. Below we will identify various categories of exceptions and propose exception management techniques specific to Process Manager – the process management platform by Nintex.

Categories of exceptions

Given the reality that exceptions occur in all but the most basic of business processes, it is incumbent upon us to determine how best to handle these exceptions. I would like to submit three categories of exceptions for examination in this article. These are not exhaustive but represent most exceptions you will encounter. The first category is a single step exception also known as a loop back. This occurs when a process reaches a point of decision typically around an approval, sign off, or verification. At this decision point the process could continue if approved or loop back to a prior step if not approved. Most process exceptions are single step exceptions. The second category of exception is an independent multi step exception. This occurs when a process reaches a point of decision or a condition occurs that would redirect the user to a separate standalone business process. The final category of exception is a dependent multi step exception. These are also known as variations. Variations occur when certain process steps or tasks vary from an agreed upon standard based on outside conditions or factors such as geographical location, business unit, product type, customer etc. These outside factors are known before beginning the process.

Simplicity above all

Before we investigate these categories of exceptions further, I want to spend a moment and emphasize the importance of process simplicity. As a business sets out on a process management journey, one of the primary outcomes is end-user engagement with process documentation. This engagement cannot be achieved when process documentation becomes overly complex, requiring the end-user to invest significant amounts of time and energy interpreting the flow of the process, finding their involvement in the process, and consuming information that will help them perform their responsibilities. If our process documentation places a large burden on the end-user, we can rest assured that they will only refer to that process when there is no other option of finding the information they need. When this happens, our processes are not actually impacting the way value is being delivered. And if our processes are not impacting the way the value is delivered, we have to ask: why do we even have them?

Therefore, regardless of the type of exception we encounter, how we deal with them is of critical importance. We must be careful to not compromise the simplicity and usability of our process documentation when handing process exceptions. This is where many traditional documentation methods fall short. An over reliance on decision diamonds, the incorporation of multiple parallel paths of activities, and never-ending process maps only serve to decrease end user engagement with the process content. We must be able to find a middle ground that will allow us to accurately represent the flow of the process yet without compromising the simplicity or usability of that process. This is what we will seek to do below.

Single step exception

As we mentioned above, single step exceptions are by far the most common type of exceptions in a process. These typically occur around approval steps in a process, where the traditional solution is to insert a decision diamond posing a question and have alternate paths of logic flowing from that diamond – one for a “yes” answer to a question and one for a “no“ answer to the question. As you can see in the diagram below the “no” logic typically loops back, directing the process performer to return to the previous step. This type of exception technique highlights one of the key deficiencies to mapping processes in a basic charting tool: that being the inability build procedure level detail into a process map.

Because the map is one dimensional, every exception must be addressed on the “face” of the process map. Furthermore, it becomes almost impossible to provide additional context or instructions for the process performer if they must loop back to a previous step. As these exceptions begin to accumulate on a map, the main flow of the process becomes distorted. This makes the process harder to comprehend and, since the “yes” and “no” paths of logic are not typically equal in frequency, does not allow the map to communicate to the user what happens most of the time when performing the process.

In contrast to this approach, users of Nintex can leverage the ability to capture procedure level process information and employ “Notes” to handle these single step exceptions. As you can see in the diagram below, the decision diamonds used in traditional maps have been replaced with process steps written to capture what happens most of the time when the process is performed (i.e.: most of the time, the change request is approved in step 2.0 and the MOC plan is approved in step 4.0). This approach allows us to simplify the look and flow of the process map while utilizing the procedure level detail embedded in steps 2.0 and 4.0 to provide detailed instructions to the user if the exceptions were to occur.

Independent multi step exception

Our next category of exception is an independent multistep exception. These types of exceptions happen when a process reaches a point of decision or a condition occurs that redirects a user to a separate process. Depending on the scope of said process, there may be a “re-entry” into the main flow downstream. As you can see in the Advertise Position process example below, there is a decision point that asks the question: “Working with Ad Agency? “– If the answer to this question is “yes”, the user follows a parallel path of process steps for contracting with an ad agency. In this case the sub process is performed by two parties absent from the main process flow (the HR Manager and the Ad Agency).

As we discussed in the introduction, traditional mapping methodologies like this introduce unnecessary complexity for the individual who is using the map. They no longer have a clear “main flow” path to follow. As a result, the process becomes less of a straightforward guide and more of a choose your own adventure experience. That slows down the ability of the user to consume the information presented in the process, rendering the process a stumbling block and not a help. This type of process design also increases the burden related to process governance. Instead of having a narrowly scoped single process to govern, the company now has a broadly scoped process with multiple exceptions that need to be governed as one. Finding qualified process owners with the appropriate expertise across that broad spectrum now becomes harder. Ultimately, this leads to processes that become out of date quickly because the burden of managing them is too great for any one person.

To avoid these dangers, users of Nintex can create a separate process for the independent multi step exception and link to that in the main process flow via a decision diamond (shown below), conditional process link, or within a task-level note of step 3.0 (shown below).

Dependent multi step exception

The final category of process exception that we will discuss is a dependent multi step exception. As mentioned in the introduction, these types of exceptions are often referred to as variations. Variations are changes to a common process flow based on predictable factors. Common variation factors include things like geographical location, business unit, product type, customer, etc. Variations are known by the user before beginning the process. This is a key distinction between a variation and an independent multi step exception where the user encounters a decision or condition within the process flow prompting them to navigate away from the original process.

Let us imagine that our previous process example “advertise position” is a process containing variations based on geographical location. This means that the process, although common across the entire company, is performed uniquely depending upon which office in the organization is performing it. Traditional mapping methodologies would require an organization to create separate processes for each geographical location or even worse, map multiple paths on the same map to capture each variation. For example, if an organization had seven different office locations, they would have seven unique advertise position processes or seven paths of logic on a single process map.

This could become a problem when common components within those seven unique processes need to be updated across-the-board. In this scenario, each individual process would have to be updated one at a time. This method may be sustainable for managing a small number of processes, but as a business grows and expands, maintaining variations in this way becomes very difficult. Often organizations will find that certain variations get updated while others do not, exposing the company to the risk of certain locations functioning with an out-of-date playbook.  

To help alleviate some of these pitfalls in managing process variations, users of Nintex can leverage the process variant management (PVM) feature. PVM allows users to create a single global process standard and then produce variations identical to the standard managed underneath the governing authority of that standard process. They can then assign specific experts to each variation to tweak the global standard and capture nuances of the process based on the factor of variation. All the while, universal changes to common parts of all the process variations can be made in the original governing global standard. This means updates that should impact each of the processes only have to be made in a single location as opposed to being made individually in each of the variations. This makes managing common process changes simpler and more consistent. You can see in the example below how Nintex organizes variations within a common process.

Choose wisely

As we have already stated, process exceptions are realities that organizations must deal with. Since process usability and simplicity is primary, we must be extremely careful how we manage any exception. Proper process scoping – defining the specific conditions to be mapped – will narrow the process down before you even begin a mapping exercise and reduce the number of exceptions you might encounter. For example, instead of trying to map a single process to capture how to onboard all new employees (full-time employees, contract employees, and interns) – start first by selecting a single process condition (one of the three types of onboarding scenarios) and mapping that. Any exceptions remaining in the final process can be identified and addressed following the best practices outlined above. Although process exceptions can be a headache to manage, doing so well will help provide your organization with a foundation for ongoing process excellence.