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.
Believing it without seeing it
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.
Misinterpreting the boundaries
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:
Top-down: Event to Outcome
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.
Bottom-up: Where from/where to
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.
Ignoring the human side
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:
- Fear: The front-line workers we are working with in the business may be concerned that we are there to ‘automate’ their role. Yet often we are actually there to make their lives easier and give them more time to work on innovative aspects of their job. Naturally, it is well worth explaining this from the outset.
- Culture: Different organizations might have different cultures, with some being more open to radical process changes. It’s important to make sure that our suggestions fit with the culture—or, if they don’t, to ensure we have strong sponsorship and good rapport with stakeholders who can champion and encourage change.
- Internalized constraints: Sometimes stakeholders may tell us that a certain process just has to work that way. Yet, if we accept these assertions without question, we might be missing out on significant opportunities for improvement. We should always ask why.
Losing sight of the customer
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.