Avoiding the Automation Trap

venus flytrap

When analyzing a heavily manual process, it is logical to consider whether parts of it can be automated. In a manufacturing environment this might involve machinery that cuts out manual steps and increases throughput. In an information processing environment this might involve the automation of routine decision making and the introduction of ‘straight through processing’. Whatever the context, and whatever approach is adopted, the benefits can include faster processing with reduced effort. Done well this can result in lower costs and a slicker service that customers enjoy—this can create a very compelling business case indeed!

Yet organizations that jump upon automation without fully understanding (and optimizing) their existing processes can find that they actually make things worse. We have probably all experienced these types of processes in our own lives as consumers—perhaps you ring a company and find you are faced with a barrage of automated menu options (‘Press 1 for sales... press 9 for service’), and when you finally get to the end you hear a recorded message advising you to visit the website (which you’ve already tried). All of which can be very frustrating when you are trying to get a response to a query that doesn’t fit one of the cookie-cutter options. You end up having to traverse a confusing landscape of processes, looking for an unofficial ‘way in’; often finding the one member of staff that cares enough to take ownership of your issue, acting as your advocate and guide. 

Of course, this is just one hypothetical example, but it highlights a broader underlying pattern. When an organization automates a process without analyzing it first, there is a real risk of ‘baking in' all of the existing processes’ problems. We are now left with a process that does the wrong thing quicker, often with little or no flexibility! 

Avoiding the Trap: The Importance of Analysis 

Even when processes appear efficient and effective, there is often an invisible mess hiding just beneath the surface. A ‘dispatch order’ process might show as green on an executive dashboard, showing that 98.5% of products leave the warehouse on time, but viewed in isolation this metric might hide issues that have crept in and now seem ‘normal’. There might be unofficial workarounds that are pinning up the process, none of which are documented but all of which act as sticking plasters to a partially broken process. These workarounds may have evolved over years, and be very difficult to see from a distance. 

Understanding these ‘band aids’ starts with elicitation and analysis. This includes working with stakeholders to understand the types of customer demand that the process has to respond to, the specific steps in the process and the exceptions that occur. Of course, formal process documents are useful but there is nothing like going and seeing the work with your own eyes. So often this exposes additional steps, workarounds, and even spreadsheet /data stores that aren’t documented anywhere. 

This type of analysis enables us to understand what really happens, and helps us gain the perspective of the people who do the work. We should also, or course, inject the voice of the customer into our analysis—ensuring we understand what they value and how this process relates to their goals. With this enhanced view of the process we can then look to simplify and improve the process before we automate it. In doing so we iron out the problems and gain incremental benefits, which we can pilot, before we invest in automation. We ease the route into automation, and we have the opportunity to liaise with and gain insight from those involved in the process along the way. 

In summary: automation can be an extremely useful and viable option for improving a process. Yet it is crucial that we fully understand the process, the customer and any existing problems before striving to automate. In doing so, we'll avoid ‘baking in’ existing problems, instead creating a process that meets the needs of our internal and external stakeholders.