(800) 286-4232 info@ratchetsoft.com
 

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