When you’re working to document your processes, an initial goal is to map the workflow of the typical, standard task, getting the most common branches outlined. This will comprise of the steps you know well, the steps that already run fairly smoothly. Yes, this will not cover every scenario, but that’s ok at this stage.
An interpretation of Pareto’s Principle, otherwise known as The 80/20 Rule is that 80% of the completed work will come from 20% of the scenarios. It’s important to get the easiest 80% of the work into the process flow quickly, so you must document those most logical, most widely executed steps before beginning to analyze what’s left.
Now that you’ve correctly documented the “standard” portion of the process, the 80%, time to focus on this 20% – the variety of things that cause delays and exceptions.
First you need to identify just what that exception is or what is causing the delay in the process. You have to learn to read between the lines to determine the root cause. Once you’ve identified the delay and/or exception, chart the frequency of each of these. Does it occur once a day, twenty times a day, once a month, only once or twice a year?
For the most frequently encountered delays/exceptions, start there – prioritize which ones you’re going to flesh out to figure out HOW you’re going to further automate that element.
Don’t let the exception – as an exception – become your norm. That’s not productive. The more you can update and automate how you handle a given exception and convert that into a standard process, the better off you will be.
Now that you have this general outline in mind, let’s look at some common root causes of delays and exceptions. Even though there is a lot of cross-over, I’ve broken these down into two sections: human-related and tech-related issues.
- Is it a communication breakdown? Perhaps the transition between process actors or departments is inadequate.
- Not enough resources to manage the load? What resources are you coming short on?
- Did the process map (assuming there is a map) not clearly identify what the next step is? Incorrect person, department, transaction?
- Did the process change recently? Is everyone current on the new procedure? Is it a training (or re-training) issue?
- Do other people/departments realize they ARE that next part of the process? That their input is needed?
- What happens with staff turnover and the workflow is not set to ping the new appropriate person? Someone’s on vacation or out sick? Or no one is monitoring a part of the process at all?
- How long will the delay/exception sit unresolved before a different action or escalation will take place? What exactly will that different action be?
- Do people need to be part of this step of the process at all? Is this the opportunity to automate things now?
- If it’s possible to automate this step, which system/application/technology platform will perform that task best?
- Is there a broken or miss-routed API connection between systems/applications/platforms?
- Could a different application/platform perform this task better/faster/more accurately?
- If the work is equally distributed across employees, but not all employees perform at the same speed/rate of completion (for whatever reason) – can you rebalance the workload so that things do not bottleneck for some and not others?
- If the package of information is incomplete, has a message/communication gone out the submitter requesting the missing info?
Minimizing exception handling is a valuable exercise – and you can’t correct what you haven’t yet identified. Exceptions result in a lot of manual, human intervention that sucks up resources and patience. It also damages the relationship with your customers/partners/citizens. By minimizing and even eliminating the delays and exceptions, you will improve turn-around time and experience a win-win for everyone involved.