Does a process need to be improved before migrating it to a new technology platform or operating model (fix-shift)? Or should the process be moved to the future environment and then fixed (shift-fix)? That choice, long debated in the business process outsourcing (BPO), offshoring, and shared services worlds, is now confronting decision-makers as they deploy robotics and cognitive automation (R&CA).
Drawing parallels between R&CA and BPO/offshoring/shared services is common. They are significant and potentially disruptive changes typically undertaken for cost reduction and efficiency gains. But when it comes to R&CA and shift/fix vs. fix/shift, there really is no real debate – you should fix it first.
Here’s why: You can move a process that has problems into a BPO, offshoring, or shared services environment, and it will likely carry on no more or no less broken than it was before migrating. And, bonus, costs will likely be lower. But R&CA is different: the cost differential between automating a process that’s clean and one that’s broken is real and potentially large.
What constitutes a broken process in the R&CA world? There are two types. The first is if the process is generating erroneous output at a level that’s causing business problems downstream – for example, an IT system pumping out purchase orders with incorrect coding. Someone else will have to deal with the problem at some point if it’s not fixed first.
The other kind of brokenness is when a significant number of exceptions occur relative to the number of transactions or work tasks that are completed cleanly. Exception management requires custom handling. Trying to automate it can create a chronic problem. Every exception has to be codified explicitly to effectively automate the work that’s being done when those exceptions occur.
The bottom line: If you try to apply R&CA to a broken process, you’ll end up with a process that is both broken and automated. It simultaneously becomes both more opaque and more easily scalable, which means you can create a bigger problem faster. Automating a broken process is also expensive. The development and, especially, maintenance costs can outweigh the potential savings.
Is your organization facing a shift-fix/fix-shift decision? I’d like to hear about it.