Sign Up for Our
Spotting patterns is a large part of my work in translating business needs and processes to technical requirements. As a happy side effect of this, I have come to notice some common pitfalls repeated in automation deployments (and attempted automation deployments!). These can cost an organisation dearly at a very early stage and sour the stakeholders on a tool that should be making their lives easier. I am putting together a series of blog posts in the hopes that a decision-maker, who is considering automation and is potentially not aware of them, can avoid them and increase the chance of a successful project.
Process Engineering for RPA and Integration
This article outlines some easy steps to take at the beginning of your automation and integration journey to avoid these common pitfalls and save you time, effort and tears. It is a broad overview and is intended for someone who is considering investing in an automation solution, or has bought an automation tool and is looking to gain more value from it. Let’s begin!
Investing in Automation without a Firm Problem in Mind
Automation presents an exciting opportunity to free up the human workforce from repetitive tasks and leave more time for creative, collaborative and valuable work. This opportunity, along with promises of an easy development cycle, makes it tempting to jump in and buy a tool, jumping into the driving seat and learning through experience.
An organisation purchases an automation solution before a firmly defined process is chosen.
Most automation solutions are licensed, rather than bought. This structure means that you are paying for the solution time, whether or not you are using it. The return of a well-designed automation will likely far outweigh the outlay, but it cannot do this sitting in its metaphorical box. This mistake is especially harmful to future team buy-in for potentially highly beneficial projects.
There is a myriad of complex processes in almost any organisation. This complexity can become challenging to navigate by any single domain expert in an organisation, especially as the business grows in size and increased specialisation becomes necessary to scale. The first step in identifying the best choice of process to automate is to develop a macro scale map of the functional area in which you're interested. To do so will likely require the formation of a cross-functional team, similar in concept to the Multi-Disciplinary Team (MDT) in medicine. It can be beneficial to get the expertise of a managed service provider at this stage, as they will have experience communicating across functions and building a comprehensive understanding of your team's workload to match up to the capability of a specific tool.
Once you have developed a high-level understanding of the organisational unit, choosing the best candidate process for automation will be your next port of call. This step is where a more granular understanding of your workflows will come in, potentially via Process Mining tools. This stage will involve detailed discussion with subject matter experts to find the real bottlenecks in your process.
While the promise of low and no-code platforms in making automation accessible can make it tempting to learn at the wheel, a firm understanding of the detail of the problem you would like to solve is vital to ensure a successful and impactful project. I hope my experiences can save you some difficulty in your deployment.
Join me next time for the next article in my process engineering for RPA series, Mistake 2: Misidentified Bottleneck!