As any business analyst will tell you, having a decent set of business processes can really help an organisation to excel. When organisations have efficient and effective business processes, supported by the right people, technology and organisational structure, there is the best possible chance of sustained success. This applies to organisations of all sizes, from huge multinational to small or midsize enterprises. Accordingly, many organisations spend time mapping out, analysing and measuring the efficiency of their processes. By building in regular measurement and feedback, it’s possible to improve continuously.
Yet there is danger waiting for the unwary. When thinking about processes, it is extremely easy for our business stakeholders to get blindsided by the “Fire and Forget” fallacy, and end up tweaking and changing processes in a way that might make them worse overall. Let me explain…
Don’t “fire & forget”
When mapping out, analysing or improving processes, often our end-users and stakeholders will immediately want to dive into the detail. They’ll talk about the individual steps that they undertake for a particular task. They might be brimming with ideas for improvement – but there is a danger that the improvements that they bring to us are extremely localised. Each stakeholder might be telling us about only part of a wider, underlying end-to-end process.
For example, we might initially see “Capture Customer’s Order”, “Manufacture & Ship Order”, “Invoice Client” and “Receive & Record Payment” as wholly independent and separate processes. Yet in reality, all three need to happen for us to be operating successfully – and not only this, the work needs to flow smoothly and steadily between each department, process step or task. If we view the processes in a compartmentalised way, we are asking for trouble.
So often, if we’re not careful, our view of business processes is truncated we end up encouraging people to fire and forget. Imagine the following hypothetical situation:
- The sales team considers that their process has ended when they send an order over to manufacturing. They are incentivised on numbers of orders, and can’t understand why manufacturing is forever taking so long.
- The manufacturing team receives orders from the sales team – yet they find that often the forms aren’t completed correctly – meaning they have to contact the client themselves. This is a source of much annoyance.
- The finance team sends invoices once the goods are dispatched. Often, they find that the manufacturing team has agreed to changes directly with the client that weren’t budgeted for in the original cost.
- The finance team also track payment – but find that many clients pay late – and annoyingly the sales team continue to accept new orders from some of the ‘worst’ offenders.
In this hypothetical example, each department may have created its own very efficient sub-process–yet the overall end-to-end process is actually highly inefficient! Each department is worried about getting its task completed, without worrying about what happens further downstream. In effect, they are ‘firing and forgetting’. They complete the work, the form or whatever and ‘fire’ it on to the next team. Once it has crossed the border to the next team, it is no longer their problem.
Thinking end-to-end
There is a significant benefit in understanding the end-to-end process. This involves understanding where the process actually ends. This probably won’t sound controversial; much has been written previously on this subject. Yet finding the real end of a process can be tricky. Consider the following hypothetical scenarios:
- For an online retailer, does the Fulfil customer order & take payment process end when the order is dispatched? Received by the customer? When the payment is made? Or is it conditional on the order being received, the payment being made and 30 days passing (so that we know the customer won’t be returning their goods for a refund)?
- For a service provider, does the Resolve complaint process end when the complaint is closed? When the customer has confirmed they are happy? Or, when the root cause of the complaint has been nailed and changes have been made so it won’t happen again?
In both cases, it would be important to nail this down before optimising the process.
Finding the end of the process
When considering processes, it is worth following the work to find the true end point. In most cases, the end point will be where we have delivered value to the customer (e.g. met their needs), value to the business (e.g. received payment), or both. Alternatively, it may be when an external, contractual or regulatory need is met. We should also ensure that feedback loops are built in so any process problems can be addressed, and this will involve ensuring that adequate and appropriate metrics are tracked. As business analysts, we can help ensure end-to-end thinking by asking the right questions, observing carefully, and keeping a keen eye out for any evidence of the ‘fire and forget’ fallacy.
How do you help your stakeholders avoid process problems? I’d love to hear your views and insight, so please keep the conversation going add a comment below. And if you like my blog, don’t forget to subscribe!
This post was written as part of the IBM for Midsize Business program, which provides midsize businesses with the tools, expertise and solutions they need to become engines of a smarter planet. I’ve been compensated to contribute to this program, but the opinions expressed in this post are my own and don’t necessarily represent IBM’s positions, strategies or opinions
