When analyzing and documenting processes, our focus often starts with understanding how a process is triggered. Often there will be a whole range of ‘business events’ that our processes need to respond to, and ensuring a common understanding of these events can help ensure that our processes work well. Processes often have various triggers: Perhaps an IT support process is triggered either by a user calling in, or by a user logging a call via a website. Each of these will kick off the process, and there may be subtle differences in the workflow depending on how the process is initiated.
However, as well as thinking about where a process starts, it is also crucial to think about where a process ends. In doing so, we’re considering what we consider to be a successful (or unsuccessful) conclusion, and what sort of outputs or outcomes are we expecting the process to produce. In fact, examining potential end points for an end-to-end process can be very illuminating and will often uncover multiple perspectives. We might even find that we have the opportunity to improve our process and reduce waste by ensuring that our perception of where the process ends matches that of the customer.
This probably sounds rather abstract, so let me give you a hypothetical example. Let’s imagine we’ve decided to push the boat out and order ten shiny new laptops for our team. We place the order directly via an IT supplier’s website. We sit back and wait for the delivery of our new items with much anticipation, and the supplier’s team starts to order/pack/dispatch them.
But where does that ‘fulfill order’ process end?
In reality, there is a danger that different stakeholders might have a different view, and this could have a knock-on impact on how the order is handled. Potential examples could include:
| Stakeholder | Perceived end-point |
| Sales Team | Once the order is dispatched |
| Warehouse/Dispatch | 14 Days after the order is dispatched (to allow for returns & items damaged in transit) |
| Customer | Once the order is successfully received, installed and working |
| Finance | Once the customer has accepted the item and has paid the invoice |
These differences in perspective often highlight that some teams have an interest in a particular part of a larger end-to-end process. Someone in the sales team might consider an order to be complete once it is dispatched—after all, the order has been validated as genuine by this point, and their role is likely to have concluded. Yet as a customer, I won’t consider that my order has been fulfilled until it arrives. Therefore even if the supplier has chosen to outsource delivery to a courier, as far as I’m concerned, my order isn’t complete until the items have arrived on my doorstep.
The finance team is likely to have an even broader perspective, focusing not on just the successful delivery of the item, but also the client’s acceptance of it—and crucially the payment of the invoice.
Whilst we may decide to model the process at different levels of abstraction, it is crucial that this end-to-end view is considered. If we compartmentalize the process and lose the end-to-end view, we could end up with each part of the process seeming to work extremely efficiently in isolation, but in reality problems are being passed down the chain. After all, there really is little point selling items that we don’t (or can’t) stock. And selling to customers that don’t settle their invoices is certainly not a successful conclusion.
With this in mind, carrying out stakeholder analysis and understanding the entire stakeholder landscape is crucial. Stakeholders include those who are involved in the process as well as those that have an interest or who are impacted by the process. Having identified key stakeholder groups we can clarify the potential process end-points by asking them “What outcomes would you expect this process to achieve” and “when would you consider the process to have concluded”.
In summary: It’s crucial that we understand the views of a range of stakeholders to get a true end-to-end view of our processes. Focusing on end-points, as well as triggers, helps us avoid process problems.