Seven perspectives on what’s required to ensure business users can easily and effectively build software robots.

Robotic process automation (RPA) tools are often described as no-code or low-code automation software. While this may be true, it doesn’t necessarily mean they’re easy for business people to use (or use quickly) to build bots to automate business processes. We decided to validate the “anyone can use these” notion by asking a handful of our automation experts and business partners to respond to this question: Can business users easily build software robots using RPA tools?

The following seven perspectives—from people who regularly work with companies using a variety of RPA tools—can help set the right expectations for what’s required to ensure business users can easily build the software robots they need to work more efficiently and effectively.

Perspective 1: Business users can build software robots to automate business processes, but there are two dimensions to consider

First, not all business users are the same. Our work with customers confirms that. Some business users—like financial analysts—regularly use advanced software, so building an RPA bot to help automate time-consuming, repetitive tasks may be easier than working with some of the spreadsheets I’ve seen floating around finance departments. Others who come from industries just beginning their digitization journey may find climbing Mount Everest easier than building a software robot. 

The second dimension to consider is what you want the software robots to do. RPA bots can perform all sorts of front and back office tasks, from simple to complex use cases. Determining what you want your bot to do will have a big impact on how much expertise you need to build it. Do you want it to do something simple like pulling data out of a spreadsheet and loading into your CRM system? Or do you want it to do something more advanced like classifying incoming emails, routing work, or making complex decisions? 

We’ve found that simple RPA bots are a great way to introduce most business people to this automation software. As people gain experience, they’re able to tackle more complex front office task automation with more advanced robotic process automation capabilities. Generally speaking, a good barometer for knowing the kind of business user that can easily build a software robot is this: If you regularly use functions in spreadsheets or if you’ve set up a simple in-home automation routine, then building an RPA bot should be relatively easy.  

Jim Casey, Director, IBM Digital Business Automation

Perspective 2: Business power users can build software robots, but IT should always be involved

Yes, business power users—those who know the systems, processes, and tools comprehensively—can build simple unattended RPA and attended RDA (Robotic Desktop Automation) software robots after a couple of weeks of RPA training. However, IT should always be involved in reuse, design, and testing (especially for unattended bots) and must be included in hosting and maintaining the bots. IT would also maintain and upgrade the underlying platform that runs the RPA and RDA bots. In other words, business users can’t perform the full, end-to-end RPA lifecycle without IT support, but they can design and build software robots and collaborate with IT to add significant value throughout the lifecycle. 

Ben Chance, Partner, IBM Automation, Offering Leader

Perspective 3: It’s about more than building RPA bots

Usually the answer to this question is no, and I say that for two reasons:

  • For the business, it’s about more than building the RPA bots. It’s understanding how they work, too. Most of the time, it doesn’t fall to the business to build the software robots. It falls to them to determine the need, opportunity, and case for the automation solution. A good RPA tool should allow them to understand how it works at a technical level and be able to visualize the capabilities. 
  • At the tactical level, some level of moderate technical resource usually creates the software robot, whether that’s a hybrid business/IT user or a purely technical role. The technical expertise is needed to do the best-practice tailoring, error handling, resiliency, and optimization. Business users typically don’t have exposure to these technical nuances.  

 Zach Silverstein, IBM Cloud Technical Engagement, Worldwide RPA Tech Lead

Perspective 4: Business users run into some risks building software robots without IT

Yes, in theory, business users can build RPA bots. It’s becoming easier to do so with available RPA tools. But, they run some risks automating business processes without IT. There’s more to building software robots than being able to code or write a script. IT functions have deep expertise and years of experience managing compliance, especially in highly regulated industries. A banking client recently told me that their business users were able to successfully develop dozens of RPA bots, but they lacked a full understanding of the access constraints around Sensitive Personal Information and Personal Information, which required IT to rework some of the automations in order to comply. 

Business users may also benefit from a wider perspective when it comes to prioritizing use cases, which requires a good understanding of the system landscape and what’s feasible. Even though business users are well placed to write scripts for the transactions they execute regularly, a fresh pair of eyes from IT could find and propose a way to radically reengineer the whole business process. With a blue-sky approach, the repetitive tasks the business user wants to automate could be removed altogether.

Don’t get me wrong, citizen developers are a valuable resource for any business process automation program, but I’d recommend they’re supported by IT and a strategy or transformation team in order to get the lowest-risk, highest-return automation software deployments.

Katie Sotheran, Strategy, Marketing and Communications, IBM Automation

Perspective 5: To create useful RPA bots, business users need good guidance and responsive bot-build support

Here’s a classic systems engineering answer—it depends. It might help to start with a few definitions in the context of automation:

No-code refers to somewhat mythical automation tools that require no programming language (code) to build relevant artifacts, such as applications, robots, processes, decisions, chatbots, and so on. Any no-code automation software is often difficult to deploy, operate, or extend later. 

Generally speaking, a no-code environment is narrow in scope and therefore good in specific vertical or horizontal problem resolution but shouldn’t be applied to areas outside its scope. Often, with any automation tool—but especially no-code tools—I see teams get excited to expand a tool’s scope from what it does best (e.g., manage project tasks for teams of two to six people) to an adjacent area that’s not a good fit (e.g., integrating project tasks with roadmap management for traceability).

Low-code refers to more realistic automation tools that generally require no code to start building relevant artifacts, which can then be extended by developers without starting over.

RPA robot refers to one type of automation artifact that often combines low-code and user interface-based automation to interact with applications like humans do.

What does this mean for business users who want to build software robots using low-code RPA tools? To increase the opportunities for success, business users need good guidance from a practical team of experts that can provide the following: documented good practices, examples of template bots, positive reinforcement that encourages innovation, and responsive bot-build support. With this kind of guidance and support, business users can easily create useful software robots while ensuring the deployment and maintenance of the bots doesn’t outweigh the benefits.

Finally, it’s important to run RPA bots through quality checks just as you would any code development. While a software robot might work for one user on one machine in one use case, it may not work for all.  Hardening for security, logging, and quality of service (e.g., retry on error) is expected from cloud software today and, in most cases, isn’t automatic or low-code. If you plan for hardening in your RPA software projects, success will be significantly higher.

Jeff Goodhue, Worldwide Executive IT Specialist, Business Automation

Perspective 6: With a week of training, business users could build a simple RPA bot

Almost all RPA vendors today market a low-code, easy-to-use RPA platform meant for business users. But, realistically, how many business users are able to use the platform at scale to automate business processes? 

I agree that with a week of training, business users could build a simple RPA bot. However, when it comes to complex business processes or automating at scale, someone with an IT background and past experience developing automation software is essential. 

Currently, you’d be hard pressed to find a standalone RPA solution. Robotic process automation capabilities will be in workflows and combined with technologies such as Business Process Management (BPM), Optical Character Recognition (OCR), Machine Learning (ML), and Artificial Intelligence (AI). Bringing these technologies together requires strong architectural skills. This doesn’t mean that business users don’t, or shouldn’t, own RPA programs. The most successful RPA programs are owned by business and executed by a combination of business and IT users. 

Divya Rajagopal, IBM Automation Service Line Leader, India

Perspective 7: RPA has come a long way, but it’s not where to find the real ROI

We’re constantly debating this question. Here’s my view: Is it possible? Absolutely! (With enough time and effort.) 

RPA tools have come a long way in enabling business users to automate simple, repetitive tasks. And they’re a good start. For us, the real value and ROI is delivered through integrated, intelligent automation across the entire business ecosystem. While these automations can be more complex, they don’t eliminate the need for business user participation. The business user plays an important role in dreaming up the art of the possible. But I would watch this space—robotic process automation—as the tools and platforms are evolving fast to become more user-friendly for business.

Chett Carmichael, Business Development, RPA, at i1solutions, South Africa 

Conclusion: Business users can easily build software bots using RPA tools, with some caveats

Based on the perspectives above, it’s okay to say business users can easily build software robots using RPA tools if you also explain that it takes some level of support—from training to governance—to be able to do it easily, quickly, and safely, especially if you’re building something more than a simple RPA bot and intend to scale your automation solution. 

My takeaway? It’s a buyer-be-aware situation where asking the right questions of RPA vendors upfront can increase the likelihood of reducing total cost of ownership and achieving expected ROI. With 50+ RPA vendors to choose from, team decision-making skills could be put to the test or taxed. 

Asking a prospective RPA vendor the following eight questions can help ensure you have the right collaborator.

Eight questions to ask any RPA tools vendor

  1. Are you a pure-play RPA provider or do you consider RPA to be part of a larger automation solution strategy?
  2. How extensive and integrated is your automation platform?
  3. Can you help me find the best integration opportunities and recommend the optimal course of action?
  4. Do you have a clear roadmap that can show me how to become more automated in the future?
  5. Do your offerings meet my requirements for security and compliance?
  6. Do you have the expertise to help me map, prioritize and document my tasks and processes?
  7. Does your RPA solution offer tools to develop and test bots, manage deployment, and monitor and handle exceptions?
  8. Do you have a good track record in business process optimization and enterprise computing?

These questions are excerpted from the Robotic Process Automation: A no-hype buyer’s guide

What about the RPA tools offered by IBM?

IBM acquired an RPA solution in July of 2020. Similar to other RPA tools, IBM RPA as a Service with WDG Automation (IBM RPAaaS) is a low-code automation solution for building, running, and monitoring software robots. It comes with some unique features, such as intelligent chatbots and concurrent bot execution (i.e., you can run multiple software robots on the same virtual host). 

In the spirit of full transparency, I asked Zach—one of our technical leads featured above—if he thought business users could easily build bots using this RPA solution. He offered this evaluation: 

IBM RPAaaS exceeded my expectations in its ability to provide a powerful development environment while maintaining the context needed for business users to understand and deploy automations. All the features—ranging from the dual script/designer view, the easy to build and use chatbots, and impressive command count (600+ out-of-the-box commands)—make it a strong platform for high-level business stakeholders and experienced IT and RPA developers.

A business user with moderate to strong technical aptitude and no prior RPA experience could grasp the automation software in around two weeks to start building it out and making things happen effectively with the bot. To make the RPA bot production-ready, resilient, deployable, and robust is where IT resources come in handy, given their deep familiarity with those general development concepts. 

In reality, regardless of the RPA tool, it’s the business who often assigns tooling to a developer resource because it’s usually easier and faster to teach a technical resource a business system than it is to teach a business user development practices and concepts. Also, business users often staff and use RPA software for a domain-specific opportunity. Technically, upskilling a business user for only one or two RPA use cases isn’t always a logistically sound idea. However, that trend is beginning to change with the growth of hyperautomation as businesses realize the value of addressing whole business processes, versus parts of processes, with enhanced RPA solutions.  

Finally, the development of an RPA Automation Center of Excellence (COE) can allow for native upskilling, continuous improvement, and growth of expertise as RPA gets picked up throughout the enterprise. This allows business users to organically increase their comfort and skill level with the automation software as it grows in importance and business priority. 

Getting started with RPA software

If you’re trying to decide where to start with IBM RPAaaS, or how to ensure a successful deployment, or where to find targeted training to fill skill gaps, these four services can help

Learn more about IBM RPA as a Service with WDG Automation.

Was this article helpful?
YesNo

More from Cloud

IBM Tech Now: April 8, 2024

< 1 min read - ​Welcome IBM Tech Now, our video web series featuring the latest and greatest news and announcements in the world of technology. Make sure you subscribe to our YouTube channel to be notified every time a new IBM Tech Now video is published. IBM Tech Now: Episode 96 On this episode, we're covering the following topics: IBM Cloud Logs A collaboration with IBM watsonx.ai and Anaconda IBM offerings in the G2 Spring Reports Stay plugged in You can check out the…

The advantages and disadvantages of private cloud 

6 min read - The popularity of private cloud is growing, primarily driven by the need for greater data security. Across industries like education, retail and government, organizations are choosing private cloud settings to conduct business use cases involving workloads with sensitive information and to comply with data privacy and compliance needs. In a report from Technavio (link resides outside ibm.com), the private cloud services market size is estimated to grow at a CAGR of 26.71% between 2023 and 2028, and it is forecast to increase by…

Optimize observability with IBM Cloud Logs to help improve infrastructure and app performance

5 min read - There is a dilemma facing infrastructure and app performance—as workloads generate an expanding amount of observability data, it puts increased pressure on collection tool abilities to process it all. The resulting data stress becomes expensive to manage and makes it harder to obtain actionable insights from the data itself, making it harder to have fast, effective, and cost-efficient performance management. A recent IDC study found that 57% of large enterprises are either collecting too much or too little observability data.…

IBM Newsletters

Get our newsletters and topic updates that deliver the latest thought leadership and insights on emerging trends.
Subscribe now More newsletters