Indeed, not everyone who (re)designs business processes is aware of the importance of Managing Process Exceptions. Even though paying more attention to Process Exceptions during process design & redesign pays off on the longer term.
In this blog, you will read what Process Exceptions actually are, why they deserve more attention, and how you may save lots of time and money by managing process exceptions, already during the (re)design.
What are Process Exceptions?
Generally speaking, a process exception is a deviation from the optimal flow – often called happy path. Process Exceptions most often prevent the delivery of process outputs (e.g. products or services) with the desired – or agreed – quality.
Mind that quality may also be cost- or time-related. E.g. when the product or service is more expensive than expected by customers ; or when it is delivered later than agreed with them.
Your company always lets sign customers to agree with sales conditions, stipulating that they have to pay 30 days after the invoice date. Even if the signed conditions apply as a contract, is it realistic to assume that all your customers pay on time, according to the agreed sales conditions?
Why do Exceptions deserve more attention?
Process (re)designers usually focus on (re)designing the “happy path”, say the process as it should be executed. This is also named “normative path”, as it is (supposed to be) the norm.
On the other side, deadline pressure – or at least the wish – to implement the new process as soon as possible, since it is supposed to create even more value, often causes them to overlook or to forget paying attention to exceptions.
The cost of ignoring Process Exceptions
When not anticipated, exceptions
- require labor-intensive (unautomated) resolution; hence, they increase costs
- usually occasion long(er) delays
- impair product and/or service quality through inaccuracies
- actually (too) often cause customer dissatisfaction
Moreover, when exceptions are not managed systematically, they will occur more frequently, though will be dealt with in an ad hoc way, so people will each time reinvent the wheel. Is this not a waste of time and money…?
Benefits of managing Process Exceptions
Let’s now look more positively: which advantages and benefits can you take from managing process exceptions (more) systematically :
1. More predictability
By identifying potential exceptions at (re)design time, you will be able to minimise their occurrence at runtime, i.e. when the process will be executed. Or at least, you will be prepared for when they yet occur.
2. Better standardised processes
By preventing exceptions you will decrease process variability and thus increase the process performance. Indeed, when exceptions will occur, you can make sure that everyone meeting the same (kind of) exception will handle it – more or less – the same way, instead of each person dealing with it his/her own way.
3. Knowledge management
By defining solutions to exceptions before they occur (thus at design time), certainly when you involve people who may have been confronted with those exceptions in the past (i.e. in a previous version of the process), you build process exception knowledge within your organisation.
And as this knowledge is shareable, rather than in the head of workers who solved exceptions ad hoc and their own way, it will not only help to standardise; you will also find solutions faster and thus you will save time and money.
4. Reducing labor costs
While anticipating exceptions, or at least by managing them in a more systematic way, you will decrease labor costs to solve them, as the respective stakeholders know what they should do, instead of improvising solutions.
5. Automated solutions
When exceptions can really not easily be prevented – say excluded – then you may automate the ‘exception solution’ by designing the ‘exception process’. Process modeling notations like BPMN 2.0 – which can generate executable processes – have specific symbols for this purpose. In such a case, as soon as the exception has been reached, the process engine then starts an Exception workflow, which can be an entire (sub)process – that was obviously designed upfront. More about this at the end of this blog.
Why knowing Exception types?
Comparably to solving structural (process) problems by identifying and managing their root-cause and type, knowing the exception’s type & cause will help to detect, to solve, and even to prevent the exception to occur.
Here are 5 main types of Process Exception (to their cause or source), according to Wil van der Aalst & Arthur ter Hofstede. And how you may manage them, including some examples.
1. Resource unavailability
When a process step (activity or task) cannot access the needed resources, then the activity cannot be executed. Some examples of resource unavailability are
- lacking (input) material needed for the activity,
- missing data or information which are necessary to proceed
- the absence of human resources, needed for manual or user tasks
Although the occurrence of such exceptions can easily – even automatically – be detected, they usually cannot be resolved ‘at runtime’, i.e. during the process execution. However, exceptions of the Resource unavailability type can often be anticipated by taking specific measures.
So, for people and for data required at runtime, you may foresee a “backup”. While for (input) material, you may foresee some inventory ; not too much, as it quickly becomes a waste… When you could not prevent the exception, you may think about urgency solutions which might be more expensive though less expensive than not executing the process at all. E.g. call on interim workers or hire a device or machine, etc.
Take a Transmission System Operator (TSO), that must operate main power lines, as an example: could it afford that the persons responsible for grid-balance are absent? Should the organisation not foresee a continue occupation for this job, e.g. by planning a backup for possible absence due to sickness?
2. Activity failures
This can be a technical exception, like a system failure during the execution ; e.g. due to a machine breakdown, a software failure or bug, etc.
Preventive – and more an more predictive – maintenance to machines or systems is a typical example to avoid failures to occur. Though even with highly effective preventive measures, you will not be able to prevent 100% of possible failures. Hence, you might also foresee measures for when the failure yet occurs.
Taking again the TSO as example: assume that an essential high-voltage line unexpectedly gets out of service. Wouldn’t it be wise to foresee an alternative circuit for the energy to compass the defect line?
3. Deadline expiration
This is obviously typical for processes and activities which are subject to deadlines. Such an exception will be raised when, during the execution, deadlines are neglected.
To prevent deadline expirations of an overall process, have a look at the activities and identify those which could take more time than expected. For those activities, foresee an alert or escalation, so to minimise the chance that the process expires the deadline. A modeling notation like BPMN foresees specific events for this : timer events, escalation events, etc.
Even when a deadline cannot be respected, you may foresee specific actions. E.g. informing your customer that the product or service will not be delivered ‘as expected’.
4. External events
Unlike internal exceptions, external ones are (most often) unpredictable, as they are caused outside of the business process.
Even for external events, organisations (can) take measures to avoid damage. Think for instance about a no-break or UPS (Uninterruptible Power Supply) to avoid an essential information system to go down when there is a power outage.
5. Unexpected constraints
This is for instance when the process is not executed as defined, or when business rules are not followed. To ensure that constraints like conditions, rules, etc. are enforced, ongoing process monitoring with dedicated control points is usually the most recommended approach.
Assume that the process requires that a (digital) approval should be given by 2 different persons – the so called 4 eyes principle. Could you blindly trust that for each approval it will happen correctly if you do not foresee any control?
Overall measures to manage Exceptions
On top of above type related measures, following – more generic ones – will also help to identify, to prevent, or to solve process exceptions.
1. Reviewing process diagrams with ‘exception glasses’
After you have (re)designed the ‘happy path’ for your process, review the process diagram thoroughly to find any exception. From beginning (start event), to end (end event) of the process, consider each process step and ask yourself what can happen differently than hoped for.
If you had not yet involved the stakeholders of the process with the (re)design – or at least all process actors – then you should certainly do it now; possibly in the form of a brainstorm session, after which you qualify the relevant exceptions.
2. Knowledge management
No doubt that some exceptions will only arise after the process has been implemented, despite all thinking exercises upfront. Though isn’t it important to manage those systematically as well?
Indeed, also after a process implementation you should manage exceptions as structurally as possible. Hence, developing and maintaining knowledge about process exceptions, shared across the entire organisation – e.g. through an intranet for operations management – will avoid people to reinvent a solution to a same exception. This will not only save time, though it will also standardise process exception management activities and thus the business processes.
3. Process Mining
If process mining is rather new to you, then please have a look at this blog, including its related hyperlinks (particularly to follow-up blogs on process mining).
If you can get reliable event logs from your information systems, then process mining – more particularly Conformance checking – will help you with discovering exceptions which you could not identify ‘from the shop floor’ or from administrative processes. You will find more details about conformance checking in this blog, more precisely the § “compliance / conformance checking cases”.
Modeling process exceptions and exception flows
Like already mentioned, BPMN facilitates the modeling of exceptions during your process (re)design. Here below you see an example of how a company can deal with payments. Something that obviously – and unfortunately – does not always takes place according to the happy flow. The happy flow (= timely payment) is surrounded by a dotted line, while the exception flow (no timely payment) is surrouned by a dashed line.
Do you have further questions or comments about managing process exceptions, or about any other BPM-related topic? Then please post them in below “Comment” box. Or take contact through this contact form.