There are many reasons why we might analyze and document a process. One common reason is that a problem has emerged – perhaps a process is taking too long, is error prone or is generating a high volume of customer complaints. In situations like this it can be very valuable to model the process and determine exactly how the work flows through the organization. A process model can visually show where there are handoffs, and when used alongside other investigative techniques can be used to spot inefficiencies, bottlenecks, unnecessary looping and other types of waste.
A well-defined process model can act as a useful visual ‘map’ to help us direct our investigative and diagnostic efforts. Sometimes the cause of our process woes might be process related, but in many cases there will be a combination of contributing factors that require our attention. Even if something looks purely process related, it might have a deeper root-cause. If we do not address the root-cause we may find that our ‘improvement’ does not have the desired effect – and in some situations it might simply move the problem elsewhere!
Let’s imagine that we are investigating what initially appears to be a process performance problem. Imagine a call center where agents respond to as many queries as they can straight away (around 80%), and arrange for a call back for any that they can’t deal with effectively (thought to be around 20%). When a call center agent receives a query that falls outside of their prescribed area of expertise, they make a note of the problem or question and pass it on to the relevant team via email. However, it seems that these queries are getting lost, and customer queries are not being resolved.
Examining the process model would help us to identify this handoff, which would be an important first step. However, in order to understand the problem further we’d need to delve deeper. This would involve looking at data, but also speaking with and observing stakeholders and ‘following the work’. In doing so we might find that there is no dedicated resource allocated to solving the exceptional problems: for example queries related to billing are dealt with by the Finance team, but these need to fit alongside their day-to-day activities. This might cause particular problems towards the end of the month when the team are focused on finalizing the ‘month end’ figures.
A potential solution to this might be to increase resource and to formalize the process for resolving these types of query. Yet, further investigation may uncover a deeper route cause. Other questions to ask would include ‘why isn’t there sufficient resource?’ Along with ‘why does the work need to be handled by another team?’ These questions might uncover a multitude of other organizational and political reasons that cannot be readily shown on a process model.
Perhaps the Head of Finance is reluctant to allow call center workers access to particular systems and databases – meaning that even simple queries that really ought to be solved by those on the front line have to be referred. It might transpire that the Finance team was not involved in the design of the original process, so feel the queries are ‘dumped’ upon them – a feeling which is exacerbated as their workload is extremely high already. We might find that this is made even worse by a recruitment freeze which means it is not possible to increase the staffing level, even though resource is thoroughly stretched. Further examination might also lead us to discover that the call center workers are assigned unrealistic (but strictly enforced) targets – and it is often easier (and quicker) to simply ‘bounce’ a problem to another team rather than deal with it. This behavior has been incentivized by the managers who designed the system; it is those that show the highest activity levels that are rewarded.
What this further investigation uncovers is a rich and complicated situation. Creating improvement will require a series of carefully coordinated interventions – these will of course includes changes to the process, but may also include changes to structure, job roles, levels of authority, automation and many more things beside. Stakeholder consultation and engagement will be crucial, and understanding the set of circumstances that led to the original systemic failure will be crucial.
Achieving this more holistic and systemic view of the situation will help us to propose changes that address root causes, that deliver benefit and that ‘stick’. It is often more complicated to do so, but it is well worth the investment in time and effort!