For those who have been in the field, it’s sometimes hard to believe that Robotic Process Automation is still relatively new compared to other automation technologies available on the market today.  There is still a fair amount of uncertainty generated when first introducing RPA within an organization. The first concern is understanding the viability of the technology and it’s value compared to other solutions already available. We discussed this in more detail in The RPA elephant in the room. Next, the question arises when to apply RPA vs other options. This is not an easy discussion as it enters into the age old conflict area between Business and IT/Product and the changing landscape of organizational structures and business operations. Worthy of a separate blog on it’s own (forthcoming), suffice it to say that Business doesn’t always speak IT and IT doesn’t always understand business operations speak.  For those organizations that can see past these differences and see the benefit of exploring the journey, a new challenge awaits them right around the corner. The seemingly conflicting paradigms of RPA with business nature itself. You see, when first exploring RPA, one thought is to focus on business processes that do not change frequently. Infrequent changes to RPA automations mean low maintenance and reduced risk of failure. But as we all know, that does not jive with todays reality where business changes faster everyday. What’s more, processes today rely on solutions that are delivered in a SaaS, PaaS or IaaS model. These solutions are known to change frequently. In fact, part of the value of organizations moving to these solutions is predicated on the ability to absorb more easily and more frequently application enhancements. In short, we look to automate things that do not change while we desire changes faster and more profound than ever before. This kind of thinking could make one conclude that RPA is doomed before it ever got started.


RPA Misconceptions


To understand why this reasoning is flawed. We have to take a critical look at the those that have been responsible for promoting RPA in the first place.


There are two culprits, each coming from a different perspective.


Software providers: RPA has risen in market adoption at such as fast pace that many software providers have jumped on the bandwagon calling their solution an RPA solution. Many of those organizations have been around for a long time doing automation and as the industry landed on the term “Robotic Process Automation” it only made sense that these solutions that bared close similarities at first glance leveraged the market momentum to cross-promote their offerings as well.

But this means that not all RPA solutions are alike. In fact, there are significant differences in applicability of the solutions in the market and this variability can cause confusion to potential buyers and stakeholders. As a quick example, some solutions that have been designed for desktop automation have been rebranded to be RPA solutions. A savvy IT executive will immediately see the challenges with applying such solutions as part of their larger technology stack and is likely to quickly abandon the RPA model as a whole.


Service providers & Internal stakeholders: Yes, those that have been praising RPA have also, unknowingly, pigeonholed the solution stack in many cases. I take full responsibility and admit that in my earlier days on this journey, I contributed myself to this confusion. In the pursuit of the highest ROI and helping to simplify the RPA message for new entrants, evangelists have often taken a very simplistic approach to describing where RPA fits. Business leaders often ask what the ideal opportunity is for RPA and evangelists will look to answer in the most simple terms possible:

  • Repetitive tasks with high volumes
  • Highly manual
  • Mature process with little changes
  • Structured data in a digital format


I have even seen the below arguments in many articles:

  • No requirement for manual intervention after start
  • Minimal number of systems involved
  • No legal or compliance driven requirement


While the above guidelines can help uncover the nirvana process, it doesn’t do RPA any justice. Of course, if you have a swivel chair activity that checks all the above boxes you likely have a fantastic ROI on your hands and it could be a no brainer for RPA. Unfortunately, the statements above undermine the long term potential and value of RPA and with that the reasoning of implementing RPA enterprise wide. In reality, you don’t need any of these statements to be true to have a valid reason for using RPA. Let’s examine them for a moment:

  • Repetitive tasks with high volumes: RPA can be very successful without tackling the process variations as part of your automation. Both in ROI it develops and in the business’ ability to gain operational transparancy.
  • Highly manual: RPA can be effective in highly automated processes to manage exceptions.
  • Mature process with little changes: Adjusting RPA is far more easily accomplished than traditional system configuration or product feature development (including API’s) and can be owned by the business.
  • Structured data in a digital format: The combinatory factor of RPA with OCR and other digitization solutions make this statement obsolete.
  • No requirement for manual intervention after start: RPA is a perfect fit for assisted automation where parts of the process need to go back to humans for judgmental intervention.
  • Minimal number of systems involved: The opposite is true. Yes it will cost more to automate on multiple systems but in comparison of building an API library across multiple systems, RPA’s value increases exponentially with every system you add into the process.
  • No legal or compliance driven requirement: Again the opposite is true. RPA reduces data leaks, increases compliance and your ability to audit.


The value of RPA goes far beyond the messages that attempt to give new users an introduction of the concept.


RPA’s application is incredibly versatile with a wide variety of business advantages. This versatility is one of RPA’s major strengths but when considering where to place our new tool in the toolshed it’s harder to find a definitive place. Is it an integration tool or a business configuration tool? Is it a testing tool or data entry tool? Is it business owned or IT owned?

All these questions throw up hurdles for organizations to properly place RPA within their current Business and IT strategy.


The new Enterprise IT


Now consider that most organizations have either moved, or are in the process of moving their business applications to the Cloud. Applications change at a faster pace then ever and both internal IT and the business have less and less control over timing of changes. In fact, most organizations are starting to grapple with the reality that they got what they wished for, an always up to date solution. Now if only they were equipped to properly consume application changes to take advantage of what the Cloud providers are pushing out.


So with little control over application changes combined with an expectation that the frequency of changes will increase over time, how can a solution like RPA even make sense? Doesn’t that go directly against one of the principles we discussed earlier? How could we even begin to imagine to deliver a sustainable automation that is predicated on UI stability?


Sustainable RPA for the new enterprise


While seemingly counter intuitive, the reality is that RPA can deliver an even greater advantage for applications that change frequently compared to more static solutions (read applications that are old and we don’t want to enhance further). How is this possible?


  1. Design driven RPA: As we discussed, not all RPA solutions are created equal. Design driven solutions (easy to spot as they don’t have a recorder button) allow you to deploy your automation with sustainability in mind. Similar to how modern application development is done leveraging today’s tools and concepts like agile development, container deployment and automated testing to mention a few, Design driven RPA solutions have embedded principles for solution architecture leveraging encapsulation, object and process design and both IT and operational governance.
  2. Sustainable solution design: Implementation specialists likewise, have to use a proper implementation methodology that delivers application integration separated from the automated business process and inclusive of a test driven application development design that allows for automation of testing both application consistency and business process adherence separately and combined.


Saying it more concise: you need to pick the right tool and implement the solution the right way.


Doing so will allow you to shift from UI-based integration to API’s at any time (and back if needed), automate testing of application interaction which mitigates the risk of frequently changing UI in Cloud based solutions and build the appropriate governance process that delivers on the promise of RPA being both a business agility solution AND being an IT governed application (so not rogue IT).



RPA is a concept just as program development is. Just because some ways to program and some programming languages may deliver mixed results, it does not mean that organizations should not engage in product development. It does mean that it may take some time to find out how best to apply RPA for your organization. Don’t be discouraged, it’s OK to use multiple tools for different use cases but don’t confuse one as being equal to the other. Do consider using a partner (I know being a service provider that may sound selfish but having been a client myself, I would highly advise it). Don’t shy away from internal partnership (this means business, IT and Product Management need to work together); I know it’s hard sometimes but the magic gets better when you work together.


Lastly, RPA is not only a viable option for organizations that have moved to the Cloud, it’s an even better value proposition. When done right, Cloud changes are caught quickly with minimal to no disruption. Business avoids educating end users where results vary widely, adoption takes a long time and cost is often underestimated, the ability to absorb and take advantage of new and improved Cloud functionality is increased for the very same reasons just mentioned and arguably one of my favorite benefits is the ability to provide data driven information back to internal stakeholders and Cloud providers about the operational impact of changes.

Johnny Ramondino

President, IN-RGY USA

Mr. Ramondino is a leader and change agent on a pursuit of service excellence through innovation. He has spent most of his career working with Global Fortune 1,000 organizations deploying Technology solutions and new approaches to service delivery. Working for and with a number of HR Service Providers in a variety of roles including Product Management, Implementation, Sales and Corporate Strategy, has given Johnny a unique perspective on the market.

With his latest focus on Service Delivery Automation, he is determined to maximize the benefits of the digital economy within Human Capital Management.