At its best, robotic process automation (RPA) transforms the customer experience, cuts cost and increases employee satisfaction. Apply it to predictable, rules-based processes – especially high-volume data operations running 24/7 – and it will reduce both cycle times and per-transaction rates and introduce consistency. Crucially, it relieves human operators of humdrum tasks, giving them an opportunity to do more fulfilling work. Robots also don’t need to relieve themselves… or take breaks of any kind.The result? Consistency and more predictable outcomes.
If the benefits of RPA are clear, the path to successful implementation is paved with obstacles. Choose the wrong business routines to automate, fail to architect better processes, or neglect to manage expectations, and RPA will flop. That’s why we recommend applying the Clarasys Agile Method (CAM) to any prospective RPA project. CAM takes agile project management principles and applies them business-wide, to identify and resolve process dysfunction.
Fundamental to CAM is the scenario or slice – a single route through the business that defines a customer relationship. A slice might, for example, be an order renewal process for an existing customer.
To demonstrate the synergy between RPA and CAM, let’s look at automation from selection through to delivery.
Creating an RPA proof of concept
Depending on how well your organisation understands RPA you may need to run a proof of concept in order to gain buy-in and sponsorship. Key to earning this will be the ability to demonstrate the efficacy of RPA and its ability to deliver return on investment (ROI). The proof of concept is likely to work best where there is a compromised customer journey that can be rectified.
By applying this approach, you will highlight any need for an operating model redesign, the creation of new roles, and an overhaul of governance. It will also help you secure buy-in for RPA, demonstrating business value to senior management, and improved job satisfaction for employees.
When choosing the candidate for the POC you should adhere to the same set of rules you would use for a full implementation.
If you haven’t already done a technology selection, now is a good time. We suggest that each of the platforms offer slightly different capabilities and are evolving quickly, so it may be necessary to have a shortlist that you allow your projects to choose from.
Choosing the right processes for RPA
Not every part of your business is ripe for automation. CAM suggests starting with a slice – so perhaps just one route that you identify as your top opportunity. When considering RPA, businesses should look for situations where:
An existing manual task requires minimal process re-engineering
Data input or output is batch-processed by humans
Linking systems cannot be achieved in other ways (e.g. there are no available connectors or APIs)
There are few, if any dependencies on concurrent major system integration projects or application deployments
The business rules are well defined and are based on clear logic
Individual ‘shadow’ or ‘citizen IT’ desktop automations are being developed in preference to enterprise-wide automation
A legacy system is about to be retired
Applying this logic to selection will leave you with a handful of processes to choose from. To prioritise, determine the value derived from each, while taking into account the amount of computer processing power and human resource each uses up. And remember the value of stability and knowledge: the fewer unknowns, the greater the chance of success.
Start thinking about the change impacts on your team
There will be employees fearful that automation could take away their jobs; while some leadership teams will have widely differing understandings of what automation means, and where RPA fits into the spectrum. These concerns are often misplaced. RPA frees up resources, including people’s time, allowing companies to concentrate on value-added activities. It also increases employee empowerment, often leading to greater staff satisfaction and motivation. By setting RPA within a change management context, an organisation can communicate with all stakeholders before, during and after deployment – to allay staff fears and manage leadership expectations. Use the analysis and design process to help manage some of the change.
Framing the customer journey
It is essential to correctly define the customer journey so that all project participants are clear about outcomes and measures of success. To that end, formulate a problem statement and test your framing against the following questions:
Does the statement provide a clear view of the customer and business outcomes that the journey is seeking to achieve?
Is there a fundamental reason for the customer journey not working that requires more than process re-design and automation?
Does the statement show the pain points, and highlight the difficulties contained within the journey?
What is the view of customers and employees on the journey, and how can their situations be improved?
Does the statement show the ‘sunshine path’ processes that support the customer journey and desired business outcome, mapped against systems, data and people?
If the problem statement still isn’t clear, it may be necessary to interview customers and employees, to better understand where the underlying pain points lie. But, by following this process through, the business will be able to get much more value out of the project. It will also be able to build a foundation for future work.
Design the new customer journey and underlying process, identifying the opportunity areas for automation
Automating something that is fundamentally flawed isn’t a good idea! Make sure that you define the journey and process steps clearly. Be careful not to be diverted into a complete re-imagination of the process if you’re targeting tactical gains. Create a backlog and include the benefits and costs to support prioritisation. Then work through the opportunities for automation and start defining user stories to address them. Make sure you define business rules clearly and simply.
If you’re early in your journey with RPA, then this might be quite tactical, but if you’re further down the path then it will be critical to ensure that you treat your robots a little like you would treat your staff when it comes to making sure they are up to date with the latest process changes and if one of them fails you have a fallback in place.
Deliver the automation using a cross functional team
Once you’ve defined the new process and initial backlog, you’re ready to start working on the technology implementation.
Ideally, you co-locate a small team with business representatives, analysts, developers and testers and work through the stories testing as you go in an Agile method. This way the development team has ready access to the people who currently perform the tasks, in order to be able to deal with unusual scenarios and any other ambiguity quickly. Bear in mind that it is still technology delivery, and not something you can just deliver as a side of desk activity – it needs testing to ensure it will work reliably. Using Agile means that at the end of every sprint you should be aiming to deliver a production ready solution – so if you get to the point of diminishing returns you can refocus the team on a different opportunity.
Development and testing take place in a suitable environment. Depending on the scale, this could be a desktop computer, an in-house server, or a cloud solution. In our experience, early engagement of IT prevents avoidable delays that can result from adopting this new technology – particularly those created by misconceptions of risks created by RPA.
Provision of licenses for software used by the Robot
Available infrastructure to build, test and deploy the robots, and the risk management that accompanies the use of any third party platforms (e.g. Amazon Web Services, Microsoft Azure)
Secure storage of passwords used by the Robots (e.g. use of CyberArk)
Capability to configure the robots (development of in-house or use of 3rd party providers)
System logins and password, profiles that the robot will require to login to systems.
Communicate the change and go-live
Let your people know what’s changing for them and how they can help. Monitor the deployment of RPA closely; initially to make sure it’s functioning as expected and is delivering the benefits you expected.
Make sure that you monitor performance over time. Increases in failures might mean a change in screen real estate. Don’t lose the knowledge of how the robots work or what they’re doing, or you’ll be in the news for the wrong reasons!
There are many ways to approach RPA, but the Clarasys Agile Method (CAM) is the most effective we have seen. By applying the project ‘slicing’ principle, real business value is generated quickly. Moreover, fast wins ensure business buy-in, while learnings from earlier stages of a project can be used to inform the later stages. Put simply, the first slice is the foundation for future work.
Ultimately, because automation can be applied initially to time-consuming processes, it soon frees up time to tackle other areas that have greater business value.
In short, when thinking RPA, don’t forget CAM.