When Benjamin Franklin said “an ounce of prevention is worth a pound of cure,” he wasn’t referring specifically to Robotic Process Automation (RPA) and the importance of the Robotic Operating Model (ROM). But he might as well have been.
RPA is implemented best when the complete journey is defined upfront, rather than waiting until you discover an error and then correcting it.
Blue Prism’s ROM was founded to serve this exact purpose and is broken down into seven pillars:
- Vision
- Organisation
- Governance and Pipeline
- Delivery Methodology
- Service Model
- People
- Technology
Each pillar encompasses the various considerations you need to make when implementing an RPA solution.
Adherence to the Blue Prism ROM ensures an RPA Centre of Excellence (CoE) thrives and grows organically, rather than stagnating. It’s what makes RPA easily scalable and prevents a company from running with RPA before it can walk.
Vision
You need to first consider the strategy and purpose of your RPA implementation. Are you looking to improve the quality of your data, save costs or enhance user experience by providing quicker, more accurate responses?
Whatever your reasoning, it’s important to understand how your strategy for RPA aligns to that of the wider business. This way, when you’re ready to scale, you’ll already have the backing.
Once you’ve established your vision – get out there and make yourself heard! Secure the buy-in from the top of the organisation and check it’s being cascaded downwards in a positive way.
Scaling RPA: before automating processes, improve them
Find a Head of RPA with an infectious enthusiasm for your organisational goals who’ll host roadshows, workshops and other initiatives to engage people across the business. RPA Champions can also spread the good word and identify further opportunities for automation.
The earlier you get the right people on board, the better!
Organisation
The next step involves planning your organisational model. Where will RPA sit within the business and what are your plans for growth? A centralised approach encompasses the entire organisation. It may be beneficial to embed this into an existing CoE. However, if you have a limited delivery team, you’ll need to manage expectations when all corners of the business are knocking at your door for their process to be automated!
A federated approach is where the RPA capability sits within a particular function but is scaled across the business, with the central team controlling standards and best practice. This is achieved by creating delivery pods throughout the organisation, responsible for identification and delivery of their own automated processes governed by the CoE.
A divisional approach is least favourable. This is where multiple RPA functions run separately across the organisation with separate infrastructure, separate governance, and separate teams. It’s not cost-effective and prevents true scale.
Governance and pipeline
Not everyone in RPA knows what a ‘good’ process is. Some are developed with little-to-no business benefits or built with complex logic destined to cause problems later down the line.
It’s important to be clear about what makes a truly good process. Binary logic, as well as highly transactional and reliable target applications, are just some of the things you ought to be looking for.
Once you’re clear on the definition of ‘good,’ you can identify processes fed through governance. This way, you’ll ask the right questions to the right audience.
Don’t be an RPA tourist, implement effective change management
For example, you could’ve found a seemingly ideal process for automation but the IT representative on your governance board informs you there’s a scheduled patch for the target application due in two months’ time. You’ll need to re-spy your elements and put the process on hold until the patch has been carried out.
Amongst other topics discussed at the Governance Board, you’ll cover demand generation i.e. how are you going to generate demand for RPA within the business? Employee incentives for identifying suitable processes, internal comms, and running workshops for engagement are just some of the techniques that we’d recommend.
Delivery methodology
Now you’ve identified all these processes, how are you going to deliver them as automated solutions?
Capturing incorrect information (or forgetting to capture it at all) in the define phase can have catastrophic impact, so you need a knowledgeable SME to capture process information. It’s also worth holding a process walk-through for the right audience.
It’s all too tempting to have your developer automate the solution in Blue Prism as quickly as possible. In the long run, though, you’re going to wish you’d taken a little more time.
First, document the “to-be” process. How will the robotic process differ from the human process? What is the blueprint for building in Blue Prism?
RPA: the key players, and what’s unique about them
Outline the Business Objects you need for this solution and compare them to Objects that already exist in your environment. This will eventually bring your development times forward as you expand your reusable object library. Development can begin once the “to-be” has been agreed with the business, and your design authority/lead developer has approved the proposed blueprint and conducted the necessary peer reviews.
Sign off testing and ensure that the business is satisfied. There are other key deliverables that need to be produced in the test and release phases – and it’s crucial not to neglect them!
Service model
Once your processes are in production, you need to get the right support around them.
Are your robots handing back business referrals to the operational team for manual keying? Are developers on hand in case the robots don’t act as expected? Do you have disaster recovery plans in place to prevent loss of robotic resources?
The last thing you need is to lose your robotic resources due to a poor service model.
People
All great teams plan for future success from the outset. If your developers aren’t experienced though, they’ll struggle to deal with the inevitable RPA pain points. Appointing a high-quality lead developer is essential, but these people can be extremely difficult to find in the current market.
Developers will need to be trained to the highest standard in both Blue Prism development and process analysis. This way, they’re ready to perform in a hybrid role, all the while receiving on-site support from an experienced consultant.
“It’s about augmenting people,” says NICE, a leading player in RPA and software robots
As your development team continues to grow, you should look to appoint a Design Authority to ensure standards are maintained and a Control Room Monitor to manage your production robots.
Lastly, plan when you’ll need to hire. This can help maintain continuity and quality throughout your delivery team.
Technology
The seventh pillar involves considerations regarding which technical approach you take. Virtual machine setup, license provisioning for future scaling, and disaster recovery should all be contemplated, as well as choosing between a cloud-based solution and on-prem host.
A common problem is failing to build virtual machines against a common image, meaning that development techniques such as Surface Automation pose a larger threat of failing.
Getting each pillar right is essential for success in any RPA solution.
Written by Rob Dawson, principal consultant, Robiquity
