Connected RPA provides a collaborative platform for humans and automated Digital Workers to deliver business-led, enterprise-wide transformation. Although connected RPA is a business-led technology, it can end up out of control if it’s treated solely as a pure business project. However, it’s not a pure technology project either. If it’s treated as an IT project, it will end up with too much governance and too much control, which prevents it getting done well or at all. The key is to find a middle ground between delivering business- led and IT-endorsed projects.
To ensure that successful outcomes are achieved with any connected RPA program, we created an industry standard delivery methodology that’s broken down into seven pillars: vision, organization, governance and pipeline, delivery methodology, service model, people and technology. The general principles involve putting a structure behind how to identify, build, develop and automate processes. In this article, I’ll discuss what each pillar encompasses and the various considerations required when embarking on a connected RPA journey.
It’s important to first establish the reasons why a connected RPA program is being undertaken and align these reasons to corporate objectives. For example, Teleco’s drive for connected RPA included improving customer satisfaction, operational efficiency, process quality and employee empowerment. Naturally, key stakeholders need to be engaged to gain their backing. If they see connected RPA as a strategic business project, they’ll champion it and help provide the requisite financial and human resources.
Although connected RPA is managed by a business team, it’s still governed by the IT department using existing practices. Therefore, IT must be involved from the start because they can support connected RPA on many critical fronts, such as compliance with IT security, auditability, the required infrastructure and its configuration, scalability and prevention of shadow IT.
This next stage involves planning where connected RPA sits within the business so it can effectively scale with demand. A centralized approach encompasses the entire organization, so it may be beneficial to embed this into an existing connected RPA center of excellence (CoE).
Another approach is the federated set up where the connected RPA capability sits within a particular function but is scaled across the business with the central automation team controlling standards and best practice. This is achieved by creating delivery pods throughout the organization, responsible for identification and delivery of their own automated processes governed by the CoE.
However, a divisional approach is one route that must be avoided. This is where multiple RPA functions run separately across the organization with differing infrastructure, governance and delivery teams. This siloed set up is not cost effective and will prevent true scale ever being achieved.
Governance and pipeline
The next stage is identifying process automation opportunities that will generate the fastest benefits. It’s important to be clear about what makes a truly good process. For example, selection criteria could include targeting those standard processes with a high workload or several manual and repetitive tasks, processes that have quality issues related to human errors or those that require customer experience improvements.
Even if the ideal process for automation has been found, businesses should collaborate with IT to ensure that there isn’t any maintenance planned for the target application. To guarantee the traceability of the automation program, a set of indicators should also be defined, such as financial, process, quality and performance related KPIs, prior to any activities taking place.
Other considerations include how to generate demand for connected RPA within the business. This could involve providing employee incentives for identifying suitable processes, internal communications and running workshops for engagement.
Once these processes have been selected, they need to be delivered as automated solutions. This means capturing correct information in the define phase to avoid problems, which requires knowledgeable subject matter experts to be involved.
It’s also worth holding a process walk through for the right audience. Each chosen automated process must be documented and an understanding gained of how it will differ from the same human process. Once this has all been agreed with the business, and the process design authority has approved the proposed blueprint and conducted the necessary peer reviews, development can begin. Once the business is satisfied, sign-off testing can start.
As processes are in production, they need the right support around them. Businesses must ensure that Digital Workers are handing back business referrals or exceptions to the operational team for manual intervention, and that a technical capability is readily available in case the Digital Workers don’t act as expected. Ultimately, to ensure smooth continuity and availability of automation resources, there must be a robust IT infrastructure.
Appointing a high-quality, lead developer is essential, but people with these skills can be difficult to find in the current market. Developers need to be trained to the highest standard in both connected RPA development and process analysis. This will enable them to perform a hybrid role while receiving on-site support from an experienced consultant. As the development team continues to grow to ensure automation standards are maintained, businesses should appoint a design authority and a control room monitor to manage Digital Workers in production.
There are several technical approaches to examine when deploying a connected RPA platform. For example, considerations may include if it’s a virtual machine set up, how to manage license provisioning for future scaling as well as choosing between a cloud-based solution or on-premise hosting of the platform.
It’s clear that to gain the best results with connected RPA, the complete journey must be defined upfront rather than waiting for mistakes and then correcting them. Once company-wide support is gained and a vision of desired results created, it’s best to start small. Getting this right enables the program to grow and scale organically rather than stagnating.
All IoT Agenda network contributors are responsible for the content and accuracy of their posts. Opinions are of the writers and do not necessarily convey the thoughts of IoT Agenda.