Process analysis is crucial to success, so what’s holding you back?
As organizations strive to become efficient, effective and customer focused, process analysis and improvement lays the foundations for change.
To construct robust foundations, we must also have a deep understanding of all business processes. As such we must set about discovering and documenting existing practices before any decisions can be made. And while documenting the as-is process sounds simple, there are a whole range of potential dangers that can trip us up. In this article, I’ll examine four potential pitfalls and how to avoid them.
When we’re working to determine what our as-is processes look like, we’ll almost certainly use a range of techniques. We might interview key stakeholders, and we might well refer to existing process documentation. In some cases, we might be presented with a huge dusty folder of procedure documentation by a manager who proclaims, “This is exactly how we do things here!”
However, we need to treat assertions like this with a healthy dose of skepticism. Oftentimes, if processes haven’t been designed and communicated well, they end up being ‘informally’ adapted and tweaked by end-users. This is because the previous analysis didn't fully appreciate or understand their needs!
It’s essential to avoid this pitfall, in addition to reading existing procedural documentation, ensure you speak to all stakeholders! Or to put it another way: go and see the work with your own eyes. This helps build empathy with those ‘at the coal-face’ and enables us to understand their day-to-day gripes and issues, as well as how the work is actually undertaken.
Processes typically span multiple departments and teams, and I’m sure we’ve all observed situations where no single stakeholder has end-to-end oversight. Each team works in isolation, carrying out their step before handing over.
This can make it very difficult to discover where the process actually starts and ends. Yet if we misinterpret the boundaries—if we don’t find out where the process actually starts and ends—then we’re unlikely to be able to fully optimize it.
To counteract this trend, it is well worth considering two approaches:
Start the analysis by thinking about the event that triggers the process, and the outcome it achieves. For example, does the process start when a customer places an order? Or is it triggered by time? Or something else? Also consider the outcome it achieves. Does it end when a customer receives their goods? When the invoice is paid? This will help to determine the boundaries.
In addition to thinking ‘top down’ it can be useful, when carrying out the detailed analysis, to think ‘bottom up’. When we are speaking with or observing end-workers, we could ask: “Where does the input to your task come from? Where does the output of your work go to?” This can help us trace the process through from beginning to end.
Whilst in some initiatives we may be focusing on optimizing processes and the supporting IT systems, it’s important not to forget the people side. This is a broad area, but some areas that can be particularly pertinent include:
When documenting and analyzing lengthy complex processes, it’s very easy to lose sight of the customer. Yet, it is well worth asking the question: how does this task add value – directly or indirectly to the customer. If it doesn’t add value to the customer or our business, unless it’s required by law, we can eliminate it completely. Either way, we should keep the customer at the center of what we do.
In conclusion, process analysis is a valuable activity, but there are many pitfalls that can trap the unprepared. By taking the right approach and considering the reasons behind our improvements, we can help drive change and transformation throughout the enterprise.