Automation is a hot topic when it comes to business process improvement. This is completely understandable, after all, a well-designed and appropriately automated process can often deliver more accurate, consistent outcomes for customers whilst being cheaper and more efficient to operate. Process automation typically starts by examining the most common scenarios and once implemented frees up time for staff to carry out more valuable activities and empathetically deal with tricky situations that occur. Some situations will always benefit from the human touch, for example, helping the family of a deceased customer, or helping the family of a customer who cannot operate her account as she has dementia. With the most common cases automated, there can be more focus on these important cases that occur less frequently.
Yet automation is no panacea, and is certainly no "silver bullet". If an inefficient and ineffective process is automated, you will more than likely end up with a bad process that continues to produce the wrong outcomes for customers—but now it does so in a rigid and faceless way. Complaints will rise, and it'll be necessary for staff to develop local "workarounds" to ensure that the customers’ needs are actually attended to. It is in these situations that local spreadsheets and databases start to proliferate, as well-meaning staff do what they can to build an "unofficial" semi-manual version of the process that actually works. Costs and inefficiencies increase, but the cause is hard to see without deeper analysis—I suspect many people reading this article will have seen situations similar to this.
Cutting Through Challenges with a Provocative Question…
It can be even more challenging when looking to improve or automate a process that has existed for a long time. People might be used to their existing ways of working, and might look to replicate the checklists, spreadsheets and other artifacts within the new automated system. It is worth working with the teams to look beyond the current process, and see how it can be improved—to simplify before we automate—so that we end up with a slicker, quicker process that is more effective. An excellent question to ask, particularly if the existing process has some level of automation (even if that is through the use of desktop tools such as e-mail and spreadsheets) is to ask the question "How would you do this on paper?". Or put differently, if all of the computers were switched off and we needed to undertake the process entirely manually, how would we do it?
These questions act as deliberately provocative "thinking tools" to help us and our stakeholders think about the process in a different way. When thinking about a manual process, the handovers and flow of data become more explicit. Whereas our stakeholders might currently say "We have to click the approval button in the accounting package", when thinking about a manual process they might say "We'd have to sign off the invoice and send it to someone to initiate the payment". We can think more about the workflow, and less about the technology, this will allow us to spot gaps and inefficiencies, and will allow us to think about the logical dependencies and flows.
Of course, it is important to think about any constraints or rules under which the process must operate. These can be taken into account as the discussions evolve. The process can be finessed, and discussions can take place over which parts are most feasible to automate. It is useful to source data on the types of cases that the process has to deal with so that those that are most common (and simplest) are automated first. Process pilots can be a useful way of testing in a smaller scale before rolling out across the organization.
In summary: automation (and process improvement more generally) can be extremely beneficial, but it is all too easy to build assumed constraints into the new process. Going back to basics, and asking how we would undertake the process manually, is an excellent way of starting to break this pattern.