By Leo Luis
RPA is generating a lot of hype in federal spaces and not all of it is unfounded, so we hypothesize. According to the National Association of Software and Services Companies (NASSCOM), RPA implementation can provide companies with a “cost reduction of 35-65 percent for onshore process operations and 10-30 percent in offshore delivery…[and] an investment recovery period as short as 6-9 months…” This is a stunning statistic!
As IT budgets shrink and operational functions increase, it forces government agencies to focus on non-mission critical functions, which could be automated. RPA might be a good tool for pivoting and focusing more human effort on strategic, mission critical objectives, and less on labor-intensive, tactical, and repetitive tasks.
Pyramid Labs is experimenting with RPA in the federal sector to determine if it warrants the hype or if we are just in the honeymoon stage with this emerging technology. This blog defines RPA, provides an overview of what we’ve discovered, explores RPA implementation, and reviews the lessons we learned.
What is RPA?
If you want to understand RPA, you must understand the definition/concept. According to Wikipedia, “RPA is an emerging form of business process automation technology based on the notion of software robots or artificial intelligence (AI) workers.” Pyramid Labs defines it as streamlining enterprise operations and reducing costs by automating mundane, rules-based business processes, enabling business users to devote more time to higher-value work.
The Benefits of RPA for Federal Agencies
RPA allows enterprises to implement technology quickly and efficiently, without changing processes. Most agencies are understandably anxious about altering large enterprise systems because of complexity and cost barriers. RPA avoids reworking systems and new integrations by working through a system’s interface.
When it comes to the Open Systems Interconnection Model (OSI Model), RPA only touches the application layer—the user interface of an application. The OSI model is a conceptual model that characterizes and standardizes the communication functions of a telecommunication or computing system without regard to its underlying internal structure and technology.
Since the bots are only touching the user interfaces, the RPA bot can act as a broker between different systems that can transform, aggregate, or do anything a person can do in a typical desktop environment.
Federal Use Cases
RPA is looking more and more attractive, and some agencies have jumped on the bandwagon to start experimenting. We’ve complied a few federal use cases of RPA:
- NASA’s Shared Services Center automated the creation of personnel cases in its human resources system for new hires and position transfers within NASA. The bot receives an auto-generated email message when a new action is required, copies personnel data, and creates a new case in the system to initiate subsequent processing actions.
- DISA’s first bot is being used to gather information and financial data required to present an “accurate and reliable” financial picture of the agency. This information is needed to support financial decisions and current compliance auditing. Moving the data-gathering responsibilities to the bot will allow the human workers to conduct more analytic analysis rather than data gathering.
- The USPS has rolled out its first bot, which automates the process of supplying missing information on packages. When a package is shipped into the U.S., weight information helps determine its shipping cost. If that weight information is missing, then USPS retrieves it from an international system that contains the weight tables for the packages.
Where RPA Falls Within the Automation Spectrum
There are several methods and approaches to achieving automation and they are typically measured against the spectrum of complexity, level of effort, and value provided. Until recently there were two major classes of automation:
- Macros, Screen Scraping, and Scripting—Is positioned at the lower end of the spectrum in terms of complexity, level of effort, and short-term value delivery
- Custom Software Development—Is positioned at the higher end of the spectrum because it requires more investment, solves more complex problems, and delivers a higher value through digitization of business processes
As shown in the diagram below, RPAs occupy a sweet spot that is in between primitive macros and scripting, and expensive custom software development. RPA is a low-cost and rapidly reproducible solution that glues together interactions across disparate applications to fulfill a higher-level business process without considerable investment in custom software development.
Typical RPA Team Members
RPA solutions teams are very similar to that of a typical software development team.
Typical RPA Terms
Typical RPA glossary terms are:
- Back Office—Not customer facing, mostly internal functions/processes
- Front Office—Customer facing, mostly external functions/processes
- Shared Services—Consolidation of support functions such as human resources, finance, information technology, and procurement from several departments into a standalone organizational entity
- Swivel Chair—Processes in which humans take input from one set of systems and processes and move it to another system such as an Enterprise Resource Planning (ERP) or Customer relationship management (CRM)
- Robotic Desktop Automation (RDA)—First step in the evolution of AI-then comes RPA and so on-RDA has manual interventions, while RPA has digital triggers or is completely self-service (see associated diagram)
Criteria for Choosing the Right RPA
As with any new technology, RPA requires an investment in time and resources. Choose processes to automate that have the most return on investment. Pyramid Labs recommends you apply the following criteria when getting started:
- Is the task performed digitally?
- Is the task performed by humans?
- Is the task highly repetitive?
- Is the task performed frequently?
- Is the task performed in large volumes?
- Are the task processes consistent?
- Is the task template-driven?
- Is the task rule-based?
Pathways for Implementing RPA
We recommend federal agencies adopt a pilot model applying Lean Startup and Agile practices to experiment, prototype, and evaluate RPAs in a one-to-two-month period before making any large investments. Before any development can commence, the agency should identify a set of use cases to prototype; this is typically the most difficult and time-consuming stage of the life cycle requiring deeper analysis on feasibility and return on investment. Use cases can be scored against metrics such as “Feasibility to Implement,” “Man Hours Saved,” and “RPA Payback Period” to identify a few high-value candidates for prototyping. It is essential to define a minimally viable product and focus on producing a functional prototype in the order of few weeks.
Agencies may have to select an RPA vendor and Artificial Intelligence/Machine Learning (AI/ML) services offered by popular cloud vendors for the prototype, but they can use this exercise to measure and test the capability of those platforms. RPA development is like conventional software development and requires careful attention to concerns such as source control configuration, automated testing and validation, and security control and deployment scalability all of which have to be appropriately addressed for enterprise adoption. Through this pilot model, agencies can quickly prove feasibility and shape a data-driven enterprise implementation strategy with a higher probability of success.
Experimenting with RPA: First Impressions and Findings
Pyramid Labs has been conducting RPA experiments and prototypes to learn more about the practicality of the technology. We want to share our experience with federal agencies interested in applying the technology.
In a matter of a few days, we created and deployed a Meeting Minutes Bot RPA prototype using UIPath’s community edition platform and Azure Cognitive Services. The Meeting Minutes Bot transcribes and summarizes business meetings into readable text. The bot also provides speech-to-text and sentiment analysis transcriptions, as well as a summary of the meeting minutes. You can view a quick demo here.
Lessons Learned
We learned five important lessons about RPA development during this process:
- Windows licenses could add to the total costs when creating RPA solutions.
- Developing RPA solutions can be constraining because you must work around a problem you might not be expecting in an application environment.
- Applications that have a canvas—such as Microsoft Word, Excel, or OneNote UI elements—are not easily identifiable for automation.
- Automation processes that have a lot of edge cases are hard to develop because maintaining the workflow will be painful if business requirements have changed.
- RPA solutions are extremely dependent on the user interface. If the user interface changes, then expect your RPA solution to break
Overall, RPA is a viable solution to help federal agencies improve performance by automating simple tasks, so the workforce can focus on delivering the mission. With every technology there are pros and cons and it’s about evaluating if the pros outweigh the cons, as well as the how much tolerance agencies have for learning RPA and understanding how to best wield its power.
If your agency is interested in exploring RPA, contact us at labs@pyramidsystems.com. We’d love to take the journey with you!