(800) 286-4232 info@ratchetsoft.com
 

RPA as a Service (RPAAS)…What Does That Mean?

If you look at an RPA ISV or consultant’s datasheet, you are sure to come across the bullet point; “RPA as a Service” (RPAAS). Unfortunately, a bullet point is usually all you’ll get with little to no elaboration. I’m guessing that’s because while many providers in the space feel compelled to advertise an RPAAS offering, very few have solidified what that offering is and are often “winging it”, based on shifting customer requirements and tolerances. As frustrating as such “vapor service” may be to customers, it is not surprising given RPA’s relative nascent stage of maturity coupled with the fact that, by definition, RPA involves automating and integrating internal systems which can make crafting an RPAAS offering tricky. However, as an RPA provider, my company, RatchetSoft, also promotes an RPAAS bullet point so I feel a certain amount of civic responsibility to, if not clearly define RPAAS, at least share some of what we’ve learned as a so-called “RPAAS provider”, pose some real-world considerations, and put some meat on those RPAAS bones. People, Process and Of Course, Robots To some, RPAAS is merely a cloud-hosted RPA stack where bots physically execute automations either in the cloud or on the customer’s servers or VMs. While that is an important piece of the puzzle, it is merely scratching the surface of what RPAAS can and should be. Most of the major RPA vendors have relatively comparable technical offerings because there are only so many accessibility, control injection, screen OCR and UI element manipulation tricks in the Automation Architect’s bag. Sure, some products do certain things better than other products do, but...

RPA: Brittleness vs Durability

RPA brittleness is the tendency for an RPA automation to break/fail after the target application undergoes a version upgrade. Why is this and what can be done? All RPA automations require a consistent way to “target” a given UI element.  In a perfect world, each UI Element would have a guaranteed unique ID that can be used to query that element at runtime. But alas, no such ID exists. Without it, we need a technique to locate that element at runtime when our automation wants to read or write its data. There are a number of techniques based on the specific technology underlying the target application. These techniques include text recognition/mapping, HTML parsing, window enumeration, pixel X/Y coordinates, and many others. But the best and most popular choice is to use the application’s “Accessibility Tree”. Although end users see text boxes, labels, drop-downs and other field types on a 2D surface, the operating systems sees much more. Since Windows XP, the Windows operating system has been able to access a hidden object model that represents the UI elements as a hierarchy of elements called the “Accessibility Tree”.  This feature was added to Windows to comply with section 509 of the Americans with Disabilities Act and enabled 3rd party developers to build applications that communicate with other desktop windows to read field data, write field data and push buttons. This operating system feature allowed for a new class of products called “screen readers” to emerge, enabling visually impaired computer users to access a wider array of Windows applications. Most RPA automations rely heavily on the accessibility tree to find specific fields, read/write data and press buttons. Typical RPA...

RPA: Tactical Solutions With Strategic Implications

Last week, a long-standing prospect asked me, “How does my organization go about developing our RPA strategy. We want to make sure we get it right from the beginning.” Mind you, I have had this same conversation with this prospect for at least the last twelve months and he has yet to move on anything. I think it’s fair to say he is suffering from strategic analysis paralysis. He has identified three processes that are ripe for RPA. The processes are complimentary to each other and if done right, could have in his words “strategic implications” for the organization. And therein lies his challenge. He is afraid to implement a technical solution that may have strategic implications without the backing of a global strategy devised by a smart and sanctioned authority who knows more about integration than he…or so he thinks. If waiting for such a divinely inspired, fine-tuned RPA strategy is significantly delaying his organization’s ability to improve its processes and leverage new business opportunities, that in and of itself is not a good strategy? I don’t see RPA as an offering that requires its own strategic plan (though it probably depends upon how one defines “strategic”). I see RPA as a tactical solution with strategic implications. Organizations are better served focusing on updating strategies impacted or enable by RPA rather than devising new strategies linked exclusively to RPA. While I’m sure there are more, the four most organizational strategies I’ve seen impacted by RPA are as follows: Information Technology Compliance (corporate and regulatory) Business Channels and Models Human Resources   Information Technology Although RPA is touted as...

Forbes: RPA Top Customer Service Tech Trend for 2017

Quoting a Forrester report, Forbes identifies RPA as a top customer service tech trend for 2017. “RPA software robots perform routine business processes and make simple decisions by mimicking the way that agents interact with applications through a user interface. Companies can automate entire end-to-end processes such as account onboarding or insurance claims awards, with humans typically only managing exceptions. In 2017: Expect to see continued focus on RPA for automating repetitive rules-based tasks. Companies will explore the nascent world of cognitive RPA to drive real business value by improving nonroutine tasks requiring judgment.” To view the whole article, click...

Selling RPA

When my company started selling our Ratchet-X RPA platform twelve years ago (long before RPA had a name), we had a tough time marketing the solution for the following reasons; a) RPA is a technology that every organization can use, but apparently, it is very difficult to market to, well, everybody, and b) prospects had become so accustomed to software applications not communicating with each other, they couldn’t understand how what we were proposing was possible. We thought we were clever branding our solution as a “desktop application integration platform”, but that only left prospects asking; “Great, what the heck is that?” Although the term RPA has helped describe what it is we do, we need to appreciate the term is still foreign to most prospects (at least the prospects we encounter). Further, those who are familiar with RPA have vastly different understandings of the term as we vendors, predictably, have tried try to make RPA mean all things to all people. So what’s the point? Well, despite the fact analysts tell us RPA is poised for enormous growth, and RPA vendors’ sales are keeping their boards quite happy, we still find ourselves doing a lot of evangelizing and educating. Though obvious to those of us who live in the RPA bubble, understanding what RPA does, the cost savings it can yield, the new business opportunities it enables organizations to seize, and why it is frequently preferred over traditional integration methods, is a bit more elusive for prospects just beginning to get their minds around the concept.    Relevant Point Solutions Evangelizing and selling RPA successfully, be it internally within...