(800) 286-4232 info@ratchetsoft.com
 

RatchetSoft Blog

 

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...

RPA vs. Native Integration

For years, I have told our integration partners and customers; “Don’t let RPA become the hammer that makes every integration project look like a nail. If you can natively integrate applications through APIs, data exports and imports, or direct writes to backend databases, that is the way you should integrate.” While I still believe this in theory, hundreds of real world projects have educated me on the delicate balancing act most organizations engage in when integrating systems. More often than not, realities on the ground lead us down the path of IT practicality rather than IT purity. So what are the factors we should consider when trying to decide whether to go with an RPA or native integration solution? Let’s start with availability. Well this seems kind of obvious. In order to integrate applications natively, native interfaces need to exist. However, the definition of the term “exist”, can vary based on the eye of the beholder. It is one thing for a vendor to provide product native integration interfaces, but another thing entirely as to whether those interfaces can be used in a given situation. Here are the factors I consider when trying to decide which way to go: 1)   Is there a cost associated with using the interfaces? While many vendors license its APIs as part of its product license, many do not. In fact, in some cases, those additional licensing fees may be quite high. Further, there may also be additional runtime fees associated with any solutions you create using a given vendor’s API. Make sure you read fine print in the EULA before you decide.   2)   Does...

Attended Versus Unattended Bots…Aren’t They All Just Bots?

Well, in a word, “yes”. However, they usually serve different purposes, are deployed, administrated and monitored differently, and are often licensed differently by RPA vendors so understanding the differences between the two is important. What is an Attended Bot? An attended bot is a bot that executes its automation on the user’s local workstation. Attended bots can be invoked in any of the following ways: 1) Via the RPA product’s client tool. This method is most often used by general purpose bots that can be invoked regardless of the user’s desktop state. In other words, the bot does not rely on the user’s desktop or applications to be in a specific state to run properly. An example of this style might be a bot that extracts the value of highlighted screen text and performs a Google search. It doesn’t matter which application is loaded. As long as text is highlighted, it can run. However, there is no hard and fast rule that mandates a bot invoked in this fashion be general purpose or even desktop state independent. A bot invoked in this fashion may be highly dependent upon state, but requires the user to establish that state before invocation. While this latter method is valid, it is not advised and method 2 described below should be considered when desktop state is an issue. 2) Via an embedded screen button. Embedded screen buttons, or what we call in Ratchet-X, magic buttons, allow the user to invoke a specific bot only when the workstation is in a state that warrants its execution. We call this the “context”. The context is defined...

RPA and Document Management – A Quick and Powerful Win

One of the use cases in which our Ratchet-X RPA platform has gotten the most traction is in the area of document management and image enabling core systems. Using RPA as a way to bridge the gap between the entities core systems track (e.g., accounts, vendors, products, etc.), and the documents and scanned images to which they relate can be a quick and powerful win that serves the needs of users across the enterprise. When an organization implements a document management system (DMS), the plan is always ambitious. Get the software in house, design the document capture and filing schemes, and integrate the document repository with every existing system that could benefit from document management. But then reality sets in. Can the existing systems be integrated? If so, how does it get done? How much will it cost? How long will it take? Despite the most noble of intentions, in the end, most organizations barely integrate only the most mission critical core applications with the new DMS. That is unfortunate because the more applications that get integrated, the greater the productivity increases for more users and thus a better return on that investment. So how are these integrations typically accomplished using RPA? Well, it depends upon what one means by, “DMS enablement”. We typically see the following four common use cases. 1)   Document Retrieval (we call it “JumpTo”). For example, a user navigates to a purchase order in the accounting system and then wants to retrieve, or “jump to”, the actual scanned image of the original purchase order in the DMS. Usually, all the information needed to issue the query...

Evaluating an RPA Project – 10 Factors Automation Architects (AAs), Should Consider When Assessing Project Feasibility And Complexity.

Whenever we engage a new customer, users spend a lot of time in the initial exploratory meeting talking about what their RPA targeted applications functionally do (CRM, ERP, EMR, etc.), rather than what they are. When I say, “What they are”, I mean how does the application look to the operating system? If we’re talking about a PC environment, which operating systems run in production? Is the application DOS (believe it or not), or Windows-based…16, 32 or 64 bit? Is the application browser-based? If so, which browsers and which versions need to be supported in production? If the system is a legacy application hosted in a terminal emulator, which emulator is being used? Does the emulator have an API for screen element access and remoting? Is the application being served up in a virtual environment like Citrix or RDP? The bottom line is most AAs don’t really care what the RPA involved applications functionally do or what the process is because those details will be hashed out by the Process Designer and cataloged in the specification document. Rather, the AA needs to know which tricks in his bag he’ll need to use to reliably read screens, write to fields, click buttons, extract data from grids, etc. The only way for an AA to fully understand a project’s complexity is to spend some time with the applications. At RatchetSoft, we call this step in our methodology, “the screen test”. We usually require a screen test be performed in order to produce an automation feasibility statement and estimate for a given project. We do this because most users don’t know the answers...

RPA Projects – Roles and Responsibilities

No doubt RPA is a liberating technology. Liberating in that RPA allows users to automate existing manual processes or create new composite processes that users were traditionally told could not be done, or required unavailable or unaffordable domain specific expertise. RPA is truly a step forward. However, despite RPA’s ability to bridge the integration digital divide, it is by no means magic and successful projects still require the right people, in the right places, doing the right things. Who are these people and what should they be doing to support a successful RPA project? Let’s take a look. Process Designer. The Process Designer is usually a business user who understands the existing process, the rules of lore and a vision of the desired process. While this role should ultimately be handled by one person for accountability purposes, it is important the Process Designer works closely with all who perform the current process in order to accurately capture the nuances of the process. Understanding and incorporating these nuances can make or break a project. Knowing and understanding that user 1 does something one way, while user 2 does it another way is critical. Ultimately, the Process Designer needs to learn about and understand these nuances and then either institutionalize or consolidate them. The Process Designer is the keeper of the specification for the RPA project and should be responsible for looping back into the specification feedback and changes made during the development and testing phase. Good RPA products should help facilitate this feedback loop. Automation Architect. The Automation Architect is the person who actually builds the automation using the RPA...

Square9 Action Pack

Today we have officially released our Ratchet-X Action Pack for Square9. This action pack allows SmartSearch/GlobalSearch users to integrate any windows, browser or legacy application for the purposes of scanning and indexing documents, or retrieving and document directly from within the context of an application record. And as always, no changes to your application are...

Upcoming Events

There are no upcoming events at this time.

Top Ratchet-X Benefits

  • Increase leverage from existing applications
  • Reduces error rates and keystrokes
  • Streamline business processes and workflows
  • Maximize IT spend ROI
  • Liberates precious IT resources
  • Promotes user self-sufficiency