Robotic Process Automation (RPA) might sound technical or complex, and that can be true when you’re digging under the hood or talking about wide-scale automation. But in another sense, it’s quite simple: It’s software for automating certain computer-based tasks, like copying data from one source field and pasting it to another.
Since the dawn of the PC age, businesses have dealt with loads of these tasks, and they’re often part of critical processes – such as getting paid or making payments. But it’s not just a finance story: HR onboarding, IT user provisioning, and plenty of other repetitive work across business functions can be a good fit for RPA, which is why the technology is attracting such attention. Even more so when, say, the CFO realizes that not only could RPA be an efficiency lever, but she might not need a multi-year project just to get it off the ground.
[ Want a primer? Read also: How to explain Robotic Process Automation (RPA) in plain English. ]
That attention on RPA comes with questions, concerns, and misconceptions. So we’re here to bring business leaders – whether the CFO or another executive or manager – up to speed on the technology. Among other things you should keep top of mind: You should probably invite your CIO to lunch before your plans get too ambitious.
1. Executives should champion RPA programs
Even if an RPA initiative begins in a grassroots, bottom-up fashion, its long-term success will depend on full buy-in from you and other leaders in the organization.
“Successful RPA projects have strong buy-in from the top management, who will drive the project across the organization,” says Tom Thaler, senior product manager, ARIS, at Software AG. “Employees – and by this, I mean all relevant stakeholders – must be aware of the project’s importance and trust in the direction of the transformation.”
That trust isn’t likely to happen organically, especially with terms like “bot” and “automation” in play. There’s a fear factor – namely, that this will change or eliminate people’s jobs – that can hamper the project if business leaders don’t address it in an open and honest manner.
“Management must also communicate to employees key details so they can understand what is happening – including what is done by robots and how the robots are doing it – since this is crucial for a broad acceptance within the organization,” Thaler says. “They must ensure that automation is used to increase the workforce, not replace it – and that automation leads to better jobs, not less.”
(We’ll share advice for proactively addressing RPA fears – and automation anxiety in general – in a future post.)
2. Cut the CIO out of the loop at your own peril
We asked our experts a straightforward question: Can a non-technical executive run an RPA program without IT involvement?
The nearly universal was: Sure, you can do that, in part because RPA software vendors are keen on making their tools usable by non-developers. That means that with the right software – and perhaps the help of a third-party service provider, at least at the start – a CFO or CMO, for just two examples of leadership positions, can kick off an RPA initiative on their own without asking for software development or other IT resources.
“One of the great benefits of RPA is that anyone – including non-technical employees – can use it by making a simple bot and recording their actions,” says Cosette Dwyer, product manager, RPA, at Laserfiche. “Employees with process design experience can add complexity as needed, but programming skills are not required.”
“Yes” answers like Dwyer’s also came with a nearly universal caveat: Not collaborating with IT leadership is almost certain to cause problems later on, especially if you have grand plans to scale your initiative.
“IT should be involved to consider how and why RPA will be used, vet vendors, and follow any necessary security and information governance protocols,” Dwyer notes. “IT resources will likely be used at the launch of an RPA program, but ideally, business users will be able to design their own solutions based on their unique needs.”
It’s a matter of balance. In the long run, RPA doesn’t need to be a drain on development teams or other IT pros, as Dwyer notes. But the “shadow IT” approach is likely going to cause issues.
“Non-technical leaders can run RPA programs without the CIO, but it’s not recommended,” says Chris Huff, chief strategy officer at Kofax. “Doing so without CIO support adds risk.”
Huff notes that even if a line-of-business leader is driving the RPA program, doing so in collaboration with your CIO is almost inevitably going to boost the initiative’s sustainability and value. Huff points to critical areas such as security, compliance (especially when RPA bots will touch customer data), and ensuring you’ve got the infrastructure necessary to scale your RPA bots.
“While business leaders can drive pilot and proof-of-concept RPA projects, it’s always best to do so by collaborating with the CIO to agree on a clear vision and strategy for driving true enterprise value through a scaled digital workforce,” Huff says.
3. Cross-functional teams can embrace complexity rather than avoid it
Still thinking of going it alone? You should know that plans to scale that digital workforce – which is another way of saying “lots of bots” – will necessarily depend on cross-functional collaboration that plans for complexity rather than hoping to avoid it on the trail.
“An RPA program run by a non-technical leader is absolutely possible, but IT involvement is the key if you want it to scale beyond individual task automation in disparate silos of the business,” says Gustavo Gomez, CEO at Bizagi.
Automating a single, relatively straightforward accounts payable process in your finance department, for example, might not meet the bar for complexity. Hundreds or even thousands of bots working across departments? That’s a different order of magnitude.
Thaler from Software AG points to the Center of Excellence (CoE) approach as one strategy for embracing the complexity that will come with scale, and with automating end-to-end processes – a goal that will likely include complementary technologies, not just RPA.
“A holistic automation approach makes end-to-end use cases available for automation,” Thaler says. “To handle this, businesses require a specialized team at the core via a CoE. These competence teams act as enablers to the business by managing the complexity of the robotic process landscape.”
Other areas this team would be responsible for might include continuous process improvements. (Remember, RPA can automate an appropriate it; it can’t fix a broken one.) Thaler also notes that the CoE and team commonly rely on process management tools. Underlying technologies such as process mining can also be in play here; Huff points to other adjacent technologies, such as process orchestration for exception-handling and AI for unstructured-to-structured data translation, as other examples. But ultimately, people still matter most.
“It’s essential to bring the right people together in the competency team, including the transformation office, the process specialists, [business leaders], and IT,” Thaler says.
[ Related read: How to identify Robotic Process Automation (RPA) opportunities. ]
This also links back to the need for true executive leadership and evangelism.
“To get the most valuable automation pipeline, top management needs to adopt an open mindset in their RPA CoE,” Thaler says. “They need to have a clear understanding of the goals of the RPA program and how to predict and capture its impact, which is increasingly shifting towards core competencies and customer relevance.”
Why do many organizations have trouble scaling RPA? Let’s delve into two other truths:
Comments
End-users that are implementing RPA bots need to understand what is behind Truth #2 (Cut the CIO out of the loop at your own peril). It's not a desire on the part of IT to maintain control. Instead, it's a need to ensure that as RPA activity scales up, it doesn't create consequences elsewhere in the hybrid IT environment. As the article notes, the problems tend to show up when RPA scales up. We are seeing inefficient mechanisms (screen-scraping) used by RPA bots to get mainframe data drive asymmetric increases in mainframe transaction volumes as bots become pervasive. When the IT team understands RPA bot data requirements, they can often suggest better, more efficient means of getting that data that keep costs down and perform better.