There are many reasons why modeling an "as is" process can be useful. Sometimes we might be aiming to achieve consistency, or to ensure that accountabilities and responsibilities are clearly defined. Other times we might be impact assessing potential changes against the existing situation, or even carrying out a gap analysis to establish where changes might be feasible and necessary. Whilst process and business improvement are likely to be our ultimate aims, there is another important and inherent reason why modeling and analyzing the "as is" process can be beneficial—that is to diagnose problems. And diagnosing root causes is crucial before we seize upon the solution.
In reality, we probably all find that potential change initiatives and ideas for change hit us from all angles. We may have a senior stakeholder who has seen a particular IT system in use in other organizations, and is keen for us to understand whether it can help streamline the workflow in our organization. We may have workers on the front line coming up with useful, incremental, actionable suggestions for tangible improvement too. All of these ideas warrant consideration (senior stakeholders often have a way of creating urgency and getting these things firmly on our radar!). Yet, so often what we are presented with is a solution, rather than a problem. Imagine we were examining the processes in a call center and the following idea was raised:
Call center worker: "We often find that our clients want to change their payment details, but only the Finance team has authority to take new card details, so we have to transfer them. Couldn't we just take a note of the card number and pass it over?"
Of course, this suggestion is very interesting, but implementing it exactly as described may cause more problems (imagine if card details get lost or compromised between teams). Perhaps a better question to ask is "Why are customers changing payment details so much?", "How frequently does this occur?" and also "Why do the finance team need to be the exclusive gatekeepers".
Perhaps an alternative solution would be to adapt the process whilst empowering the call center workers to take and input the payment details, which may of course involve providing additional training, system access and so forth. Or even to provide a Web portal where the user can conduct the change themselves. Mapping the as-is process will help us understand the current constraints, handovers and inefficiencies. We can use this to probe and question, and to understand (and challenge) any business rules that the process enforces. It may be, for example, that ten years ago there was legislation that mandated only certain staff can handle payment details. If this has now changed, the process is ripe for change.
Clearly this is just a hypothetical example, but it illustrates a common pattern: that often as human beings we problem-solve too early. We seem to be wired to jump on the first feasible and actionable solution that we find. Yet, working to understand the "as is" process and the current business situation and context will help us get closer to the root problem. A process model can help us know which questions to ask, as we consider factors including:
- What are the events that trigger the process? Are there others that we should consider?
- What are the goals of the process? How are we measuring it? Are the measures still appropriate and useful?
- What are the demand levels? Are there requests that we don’t/can't meet?
- Where does the process end? Is part of the root cause of the problem that we consider our process ends at a different point to the customer? (e.g. we consider it ends at "goods dispatched", but the customer considers it ends at "goods received and accepted”)
- How does the work flow through the process? Are there any redundant or unnecessarily complicated tasks or pathways?
- Can any work be eliminated?
- Are accountabilities and responsibilities clear?
- Where do exceptions happen? Why? Can they be prevented? How often do they occur?
- What complaints have been received relating to the process? How were they resolved? Was the underlying issue resolved? Are there common themes?
- How do we compare to other organizations?
- What external factors (political, social, legal/regulatory, economic, etc.) constrain or otherwise affect the process?
The answers to these and other questions will provide us with valuable insight. Importantly, an end-to-end process helps us to see a stated problem in a much broader context. So often, the primary effects of a problem are felt far away from the root cause. An end-to-end process enables us to trace back, understand any constraints, and work with our stakeholders to ensure we diagnose the root cause. Then, once we have diagnosed it, we can work with our stakeholders to truly resolve it.
Of course, working with your stakeholders towards resolution is a whole other hurdle to overcome – learn about the importance of feedback by downloading our eBook below!