Exceptions In Software
As clients purchase a software application or begin an outsourcing experience with a service provider, the expectation is that manual processes will be transitioned to an automated solution. During the implementation, subject matter experts (SME) attempt to remove all human intervention within a process and as a result get hung up on the exceptions. It is these exceptions in a business process that all too often derail the timeline and drive initial costs through the roof. The desire to resolve an exception, even when data isn’t present and the process or the overall impact is unknown, often results in an incomplete or compromised solution.
What Is An Example Of Software Exceptions?
I worked with a client who had the requirement to ‘modify images and be able to add a note’. Their process was to submit images to a state government with a note in a specific location on the image. Simple enough right? The solution was to procure a specific image viewer that would annotate (add the note) the image and fulfill this requirement. After several rounds of testing; Success!
Yet, as the client went into production, latency (system slowness) occurred that was not seen in testing. As the teams began to analyze the problem, it was discovered the root cause was excessive system memory usage. The standard process required approximately 50 people to concurrently open anywhere from 75-100 documents at a time with multiple image of varying file sizes. The viewer would cache the images and as a result the memory usage required to support the large number of images caused the latency. As we evaluated the viewer and explored alternatives, it was discovered that only 10% of the volume required the annotating process or use of this specific viewer. Of the identified 10%, only documents that were submitted in the past 30 days required the annotation. The solution put forth for all processing was negatively impacted by a small subset of documents that deviated from the standard process.
So how do we manage these process exceptions?
Managing The Exceptions
1. Isolate the exceptions and treat them as mini projects running a parallel path.
Often times processors know they have an exception, but they aren’t sure why it occurs or how to address it in a standard manner. The decision making process associated to the resolution of the exception isn’t documented or may vary. Leveraging the 80/20 rule, you can proceed with 80% of the processes, and move forward defining a solution for the bulk of the volume, keeping the majority of the project on track.
Exceptions can be implemented within the same time-frame of the “normal” processes leveraging a blended approach between a automated and manual solution. Alternatively, they may be implemented post production.
By isolating the exception, the majority of processing efficiencies offered by the solution can be implemented on-time and within budget and the overall solution won’t be negatively impacted by the exception processes.
2. Identify the root cause – don’t stop at the surface, dig to the root.
Early on in my career, I sat with a manual processor and if she could not complete the entry she created a stack of “exceptions” on her desk. As we implemented the automated solution, we created a virtual ‘stack’. Other than identifying it as an “exception”, we had no information or understanding as to why it was in the stack. I needed to take the time to ask questions to gain a thorough understanding of the issue and identify the root cause. Although an exception might exist today, with the implementation of a new system it may be inherently resolved. Yet, if you don’t know the cause of the exception it is difficult to create a workable solution or take advantage of a new applications functionality.
3. Be willing to transform.
In the beginning scenario, during the discovery process with the client, it was asked if rather than an image providing the note, is it possible to submit a data file to the state government agency. The SME indicated it was a contractual obligation and it couldn’t be altered. After the problem was exposed and alternatives explored to resolve the latency issue, it was identified that it was a contractual requirement to provide the ‘note’, but how it was provided could be defined by the provider. As a result, the specific image viewer was actually not needed and the exception could be addressed through the standardized solution.
Don’t be afraid to transform how the process occurs; rarely is a like-for-like solution viable. Systems are upgraded, regulations are changed, and policies are altered. Look for the opportunity to transform a process to reduce exception processing and increase efficiency.
All business processes have exceptions. Just buying software or outsourcing to a service provider does not equate to processing efficiencies. Creating exception handlers can be a lengthy and costly development cycle reducing the benefits to a systematic approach. The key is to manage those exceptions by isolating them from the majority of work, assessing the root cause, and being willing to transform to seize the benefits of a systematic approach.