Process automation, especially in its most currently identifiable form of robotic process automation (RPA), has been the poster child for business-led digital transformation over the past few years. However, despite continued adoption, various “myths” about the power of process automation continue to percolate. Inspired by our 2018 automation myth-busting blog, we decided to crack open this topic to further this discussion.

The 2021 edition of HFS process automation myth-busting, as showcased in our recent webinar, put the enterprise spotlight on a little firm called Google: Program Manager Edward Dinh discussed with us how Google’s teams have been making use and, more recently, RPA (on the Google Cloud Platform) from its partner Pegasystems, represented by Intelligent Automation VP Francis Carden. Here are four myth chestnuts to be roasted over an open fire as we take on 2021:

1. “Digital natives live in happy vacuums with no legacy systems, so they don’t need automation.” Wrong. Even if your company is thankfully modern, someone in your ecosystem is not.
2. “Process debt is unique to business operations.” Nope. Process debt, the creation of awkward and often manual processes designed to buttress aging technologies, exists wherever aging tech does. It is in no way unique to business operations.
3. “RPA alone can drive digital transformation.” Incorrect. It’s the combination of technology that drives value; combined solutions are advancing at a pace far greater than standalone technologies.
4. “Process automation is stuck on-prem.” Certainly not. Process automation is wherever the process (and systems) reside—cloud or on-prem.

You might be modern, but that doesn’t mean your ecosystem is

Myth-busting #1: “Digital natives live in happy vacuums with no legacy systems, so they don’t need automation”

Google’s global network supports all manner of household names like Maps, YouTube, and “classic” Google search. As well as supporting all adopters of Google Cloud, Google’s engineering team supports Google apps, networking infrastructure, and business operations across the board—Google is often its own best customer. The bottom line of Google’s automation and broader transformation work with Pegasystems is helping Google’s engineers do their jobs better—and part of that is alleviating them from low-value, repetitive support tasks.

When Google first embarked on this journey, its engineers were faced with manual toil throughout its partner ecosystem full of “legacy” enterprises—they would have to navigate hundreds of websites, apps, and systems and transfer the same information over and over to deal with the variety of tickets falling at their feet. Then came the opportunity to automate and Google went for RPA on top of a broader low-code BPM platform called Moose. To-date, it has achieved some clear benefits:

• Scalability: 80% of ticket volume fully automated.
• Cycle time: 10x improvement in ticket transaction cycle times.
• Data integrity: Improved accuracy and system alignment for requests and external services.
• Resource efficiency: Google engineers are free to focus on complex issues and innovation.

The sheer number of tickets that the engineering team dealt with meant that hiccups would occur no matter how good they were. Requests are now sent by bot or API to other systems when they come in—meaning Google engineers are free to manage escalations, innovate, and build more complex solutions.

Automation is moving beyond just being a toolkit; it’s something businesses need to do. Google had several engineers, tools, ecosystem partners, and systems working together, and it needed low-code apps to be able to tweak functionality to business process needs and play well with different Google tools.

Google’s Moose program acts as a management app for the engineering team. Engineering identifies the problem, then Moose takes in parameters about the problem and broader context to be able to schedule delivery on time, including artificial intelligence (AI)-based scheduling; we’ll touch on that later. Moose runs on the Pega platform, and it’s the functionality between Moose and other systems where RPA finds a sweet spot for Google.

“The majority of external partners don’t have the APIs and technology capabilities we’d want—so we’re leaning on RPA to engage externally. We don’t want our engineers to manually open and populate websites hundreds of times a day.”

 Edward Dinh, Program Manager, Google

Success in the ecosystem has prompted other teams to reach out from inside Google. It’s a goal that everyone in a business can get behind: the automation program supports other teams that now also have more free time alongside better cycle times and accuracy. Google puts a strong focus on employee experience (EX), with Dinh adding, “We want teams to love the apps they’re in, even if they’re in backend support.” Dinh’s team is also looking upstream in the workflow, with scale defined, as we’ve seen in so many of our enterprise conversations, wherever Google finds opportunity and value. Rather than being constrained to IT, engineering, or business, automation is a native part of Google’s structures.

Process debt—originally designed to prop up aging technologies—has created both business and IT process pretzels with new, manual, and awkward processes added at the expense of long-term transformation

Myth-busting #2: Process debt is unique to business operations

RPA can bridge the gap between new and legacy systems, but you still need to figure out how to retire these legacy processes. Piling RPA on top of legacy just means you tax yourself and create “process debt”—and the cost of this is going up.

“Are we trying to automate the “as-is” on the journey to digital transformation? No one really wants to automate old processes—but transformation takes time. You need to rethink processes.”

Edward Dinh, Program Manager, Google

When you bring RPA on top of processes, the process doesn’t change. It just gets heavier and more expensive. This problem is by no means unique to business processes.IT is an equally drastic—if not more—process-debt offender. Business leaders often just see the people cost, but the bulk of the iceberg is underneath the surface, and it’s exponentially growing. Francis Carden, VP, Digital Automation and Robotics at Pegasystems, cited, “One bank found that 94% of its IT budget went on process debt to keep the lights on!”

Tactical technologies like RPA have a place—but it’s the combination of technologies that transforms

Myth-busting #3: RPA alone can drive digital transformation—because it’s magic

To automate complex workflow threads, you need technologies to work in combination. Exhibit 1 represents executives’ realization of value from combining technologies and that these technologies are converging into platforms there for the taking; our separate piece explores the power of “AND” in more detail.

Exhibit 1: The power of “AND” for the win. Enterprises see greater value from using emerging tech in combinations versus piecemeal—and the convergence will only continue.

Sample: 600 executives across Global 2000 enterprises

Source: HFS Research in conjunction with KPMG, 2020

Firms often go in head-first into siloed technology projects when they need the return on investment (ROI) and don’t think about any underlying process debt they have or are about to create. But if you bring technologies together on platforms alongside automation, analytics, AI, and other emerging technologies, you can come to the digital revolution party.

Solutions based on combinations of technologies have advanced far more in recent years than the individual technologies that have existed for decades. Businesses want to capture all their work in a single entity—building it out from the core into all processes to become closer to what could be considered a version of a “new digital native.” It’s now a matter of weeks and months to build and replace processes versus years. Realizing this is key to surviving and thriving during this pandemic. The power of “AND,” alongside outcomes, brings speed to the table.

RPA is one tool in Google’s automation journey. With project Moose, Google has greater visibility of the vast number of apps that need support and management. One example of “AND,” analytics reporting on Google Cloud, helps with this support. Google has clear goals with its apps all working together to support business processes. Take AI as another example. Google uses AI to determine the best options for a particular ticket, and if they’re not available, it can follow the chain down from that… a huge time saver. But AI can’t be in a silo—rather, it must be, as Google’s Edward Dinh described, a “central brain” where you can bring data together from all over for new and improved predictions and insight.

Pega applies the same thinking to the rise of process intelligence tools (HFS’ combination of process mining and discovery):

“Many organizations don’t know what processes they currently have, yes… but actually, what happens if we reimagined a new process, versus just mining to try and optimize the old? You can now re-invent that new process super quickly with low-code…”

Francis Carden, VP, Digital Automation and Robotics, Pegasystems

Like RPA, process intelligence is another valuable tool,but you don’t want the analysis paralysis that results from constantly focusing on finding broken processes. Discovery needs to be in parallel with reimagining.

You can build and automate new processes before deciding where to run them. But just how viable is it to transfer legacy processes onto cloud and put RPA on top of it?

Myth-busting #4: Process automation is stuck on-prem

Despite cloud-first organizations embracing RPA, our research suggests that over 95% of RPA is still on-prem. Every form of RPA can run on cloud—even the apps. If your apps and processes are on-prem, then that’s where RPA will run. If they’re in the cloud, then RPA will run in the cloud. It’s about the processes you want to automate, not RPA itself. The sheer volume of on-prem RPA implementations reminds us that much of what is being automated is on-prem.

Build and automate new processes before deciding where to host them, and consider just how wise it is to move legacy processes onto cloud and put more RPA debt on top of it rather than redesigning the process.

The Bottom Line: Automate the as-is for short-term value and to plug gaps, but do it alongside broader outcome-focused transformation.

Tactical automation tools have their place—and some value—but they’re not new and have not seen scale. Digital transformation used to be expensive because you’d have to manage and maintain legacy systems, monolithic apps, and code .Now, with low and lower-code platforms, you can eliminate the underpinning iceberg. What you build on top, you now build for change, and you can change it in minutes, hours, and days—not years. Use the power of “AND” to transform and use RPA to plug any gaps where you need to connect the new to the old backend systems. Circling back to Google, the legacy systems of many partners are not open and not in Google’s control, so Google uses RPA to connect to them. Don’t use RPA as the front end to transform the business—that’s when you just might topple the legacy iceberg of process debt.