Read Blog Post

Read Blog Post

Contributed on April 12, 2015

11

288

Robotic Process Automation & ITPA: Why the Differences are Important

Blog: UIPath.com

There are two challenges often tied to emerging technologies – initial confusion over what (if anything) the technology name even means, and/or, misidentifying it with other, related technologies. “Big data” is an example of a widespread technology whose name meant little when it first appeared and whose capabilities were initially viewed by many as just a more robust version of conventional business analytics. Today, robotic process automation (RPA) also encounters these challenges, particularly from ITPA (IT process automation).

For many people the term “robotic” immediately brings to mind industrial robotic technology and a physical robot, not the notion of

a nonphysical software robot performing process activities by emulating human activities and interacting – just as humans do – with applications. Once this first misunderstanding is cleared up, a second misunderstanding – based on viewing it as just a new label for an already existing technology – can often take its place. People can be inclined to say, “Doesn’t RPA really mean IT process automation? It’s just a slightly different acronym.”  

It’s no wonder people tend to view RPA & ITPA as one and the same. After all, they both leverage software tools to automate processes – promoting efficiencies, lowering costs, raising accuracy and elevating quality. In fact, RPA & ITPA are different, and those differences illuminate hurdles to RPA’s potential and trajectory over the next few years.

How RPA Differs from ITPA

• ITPA is focused on known problems & quantifiable benefits. For years IT departments have been struggling with the infamous “80/20” conundrum. This term, shown in the accompanying graphic, addresses the fact that 80% of an IT budget is typically linked to doing nothing more than “keeping the lights on.” Only the remaining 20% is available to support and advance

  

  a company’s important strategic and competitive business needs. IT departments have tried many solutions, including the massive shift to outsourcing, to address this imbalance between available budget and prioritized services. Beyond the “80/20” problem, for years IT departments have faced service performance challenges generated by mergers and acquisitions entailing integration with other IT organizations and systems. These challenges go beyond relatively straightforward system integration issues and touch on much more complex problems in the area of operational processes. In response, IT departments across industries have embraced and implemented process disciplines, perhaps the most widely recognized being the Information Technology Infrastructure Library (ITIL).  The ITIL methodology is based upon a comprehensive set of best practices – practices used to guide the implementation of IT service management policies and processes.

• ITPA must deliver robust functionality to handle complicated processes across highly secured environments. For example, a common ITPA functional requirement is the consolidation of all manual steps for the provisioning of a virtual server into a single executable: monitoring for an approved provisioning change request; beginning the server provisioning process; configuring the server settings; initiating the configuration audit; creating a virtual package that meets change for requirements; initiate server deployment; finalize audit; close out the change request. The ITPA tool allows the process to begin and end without any IT resource intervention.

• ITPA has the luxury of user interface tradeoffs in favor of complex capabilities over intuitive and easily understood features. This situation exists because IT department employees have a development background and/or a high degree of familiarity with technical nomenclature, screen content and response logic . Certainly that’s the case when compared to the typical business user environment. As a result, while simplicity and intuitiveness is always favored, ITPA tools can manage risks associated with configuration complexity easier than RPA tools, since those tools are destined for a business user’s world.

What these Distinctions Illuminate about RPA’s Potential

These distinctions matter because they illuminate the gap between current RPA reality and it’s long term potential. Further these distinctions point to who owns actions needed to close those gaps.

• Known problems & quantifiable benefits: beyond a vague sense that things can always be improved, on the business side of the business organization there is often little tangible evidence of what process issues exist and the value of their elimination. It’s not surprising that BPO service providers were one of the first groups to gravitate towards RPA technology – continual cost reductions & operating efficiencies are keys to the success of their fixed price contracts. The business case for process optimization must become easier to make and more convincing if RPA adoption is to accelerate.

• Functionality to handle complicated processes: the lack of any robotic process automation in most business does allow large benefits to flow from relatively simple functionality. However, to warrant attention from senior business decision-makers, RPA capabilities must grow.

• Robust capabilities or user-friendly, intuitive feature interfaces? The answer is, of course, both. There’s no question ITPA has the fortunate circumstance of a forgiving user base. RPA, on the other hand, has no such luxury. Not only does RPA need to grow capabilities, its user base has interface expectations formed by the iPhone. Unless this emerging technology rises to the challenge of making it “easy” for business users to configure process automation software, the future may prove to be disappointing.