The first step you take in a project is always the most important one. Depending on how that step is taken, some outcomes will become more likely to happen, whilst others less likely. Options will start to be limited, whilst others will open up. The success of the project will never be more controllable than on Day One of your project.
So, when you start your RPA journey, the initial decisions you make will have a huge influence on how successful your project will be. This article examines what decisions are needed on Day One, and what are the key things you need to consider as you take that all-important first step.
The very first question that you will need to ask, and get consensus on, is what are you trying to achieve. This may sound obvious, but it is surprising how many organisations walk blindly into an automation program because they ‘want to do some RPA’. Whilst there is some merit in testing out this transformative technology, if you really want significant and sustainable benefits then your automation strategy needs to align completely with your business objectives. Do not do anything else until you have figured this one out.
As an extension to that initial question, you will do well to understand, and agree, what your automation ambitions are. How far do you want to take this? Do you intend to just implement RPA in a few processes around the business and grab some efficiency gains, or do you see automation as a fundamental part of how your business will be run in the future? Or is it somewhere between these two extremes? These are important questions because they will determine what sort of organisation you will need to build to support your automation efforts.
Another choice to make is how you will approach the first phase of your RPA journey. This can be expressed simply as whether you are going to plan everything first, or just get on and do stuff. The right answer is usually somewhere between these two, but most companies will choose an approach that is weighted toward one or the other. A ‘plan’ approach ensures that you have as good an understanding as possible of your environment, the opportunities, the benefits and the risks before you commit yourself to automating anything. The downside is that all of this takes time and effort, and many of your stakeholders want to see something tangible happening quickly, rather than the creation of a big report or presentation. Which is why many organisations go straight in with a Do approach, carrying out a proof-of-concept by automating one or two processes to test the software and get stakeholder buy-in.
One nuance of the initial automation that is sometimes over-looked is whether you should do a proof-of-concept or a pilot. Although it may seem pedantic, these are two quite different approaches and can have a big impact on the early success of the program. A proof-of-concept only automates the basic process (the ‘happy path’, as it is called) and ignores any exceptions. It is not run on production data, and is discarded once the concept has (or has not) been proved. This makes it quick to deploy and will be relatively cheap, but there will be no tangible benefits at the end (apart from stakeholder buy in). A pilot, on the other hand, automates a complete process, including all exceptions, and can be run on production systems with production data. If the pilot is successful then it will continue to be used in a live environment. This will obviously take longer to deploy and the costs will be proportionally higher, but there will (likely) be savings at the end of it, which can potentially be used to fund subsequent stages in the project. The final choice will be down to a number of things specific to your own organisation’s culture and needs.
The final question to ask on Day One is what sort of eco-system you will need to build. An automation eco-system will consist of all of the different technologies, resources and partners that will be needed to support the automation journey. It will be something that will evolve and grow over time, and will depend very much on your automation ambitions, but it is important to consider this as early as possible. What capabilities do you already have in-house? Where are the strengths of your incumbent service Providers? What additional capabilities will you need to bring in, either through recruitment or third parties? The main elements to look at are the software vendors (RPA and associated technologies such as AI), the automation implementers (process mappers and software configurers, such as Roboyo), automation strategy advisers, change management and, finally, support. Some third parties will be able to do a range of these activities, but you may choose to go ‘best of breed’. Finding a good strategic adviser and implementation partner are probably your two biggest priorities on Day One.
So, before you have even picked up the phone to an RPA software vendor, there are plenty of things to consider on Day One of your automation journey. All of the questions described above are extremely important to get answers to if you want your program to deliver sustainable success. Make sure that you spend the time considering each one carefully.