“Should I redesign my process before I automate it?”

By Katie Sotheran

As automation programs gather steam, the question of how automation fits alongside existing improvement initiatives often comes up. Should you attempt to automate the existing process – mess and all – or improve and redesign it first?

Unfortunately, it’s not a simple yes or no answer. Depending on your objectives and process complexity, you could take either approach. For example, you could:

  • Automate a couple of bottleneck or error-prone tasks, making the process more customer-pleasing. By digitizing those parts of the process, you’ll generate meaningful data that can support more in-depth analysis and understanding of where and how the process can be improved overall.
  • Entirely reengineer a process to create a new, automated, intelligent workflow. In this case, improvements likely won’t be incremental but exponential, with a new distribution of labor.

Either way, determining the right approach comes down to answering the following two questions:

1. How broken is the process?

A standardized and relatively efficient process may not need redesigning and could be automated entirely with technology standing in for human activity at each step – from data entry or document ingestion to decision management, task execution and communication activities. The result will be a change in the way work is distributed between people and technology (for example, bots, data capture tools, rules engines and so on).

At the other end of the “not broken to broken” spectrum are workflows where the only way to deliver value is to completely reimagine it for automation. This is often the case when the process is designed around a set of human or system constraints that are no longer needed, such as a process that was designed with legacy systems in mind, where new microservices can remove those constraints. Tinkering with task-level automation in these cases will deliver only a small portion of the potential benefits – and, as Mike Hobday, VP of IBM Automation in Europe puts it, you run the risk of embalming a dated operating model by removing the need for more radical changes.

2. What’s the business case for improvement?

Whether you automate or redesign your process first also depends on understanding the strategic purpose of the change. Will improvements reduce operating costs or affect customers and drive growth? Is it part of a department-sponsored improvement initiative or a broader enterprise-wide digital transformation?

Here are some quick, general guidelines:

  • If the process is part of an enterprise-wide digital transformation with potential for high financial impact, the business case for entirely redesigning for automation can be made more readily.
  • If the process is part of a department-sponsored initiative to reduce costs, you might consider making some small-scale process improvements first, including task-level automation. This will enable you to standardize, capture some improved performance data, and pave the way for more extensive reengineering using automation as a next step.

When weighing the merits of incremental changes versus fully fledged redesign, bear in mind that an automated workflow – done right, with appropriate orchestration, flexible hosting and scalable tools – is an agile one, ready to change as business conditions evolve. The question of whether to improve or automate won’t need to be answered again as the automation will drive the improvement.

A quick client example

We worked with a global automotive manufacturer to assess the feasibility of, and optimal approach for, introducing robotic process automation (RPA) into a back-office finance process. Process discovery highlighted some issues around the use of scanned images within the process that suggested optical character recognition (OCR) might deliver further improvements. Additionally, unstructured data was found to be inhibiting quality and flow, pointing to the need for a cognitive rules engine.

By identifying these two additional areas for improvement, we changed the business case for automating the process first. By adding two additional automation capabilities to RPA – OCR and a cognitive rules engine – the client could potentially quadruple the business benefit, necessitating a more significant process redesign than had previously been considered.

Note: The process discovery wasn’t a series of lengthy mapping workshops. It was a rapid, automated approach that helped uncover the complexity of the process, range of improvement opportunities and the potential impact of recommended technology solutions.

Three final thoughts

  1. Technology runs more efficiently on an optimized process.
  2. A low-tech improvement to rebalance workload or reduce process exceptions might be a good way to deliver an initial business benefit while grander plans are being made.
  3. Before you determine whether automation should be introduced with incremental improvements or as part of a radical redesign, get to know the process first.

To learn more about how other companies are approaching automation, take a look at our case studies at www.ibm.com/automation.

Upcoming ROI webcast

Building the business case for an automation platform solution

Join special guest, Sean Owens, Principal Consultant at Forrester, on 1 May 2019 at 1 PM EST. 

Sign up for the IBM Automation Insider

What automation opportunities are out there? How do you get results?
Every other month our experts share five pieces of strategic content to help you drive growth through automation.