Month: March 2021

RPA Glossary: Your Ultimate Guide to the Robotic Process Automation

Posted on by admin

Industry 4.0 manufacturing

RPA Glossary: Robotic Process Automation Guide that provides valuable insights into RPA

Thank you for clicking on this article.  Enclosed in this article is our comprehensive point of view for all things Robotic Process Automation (RPA) that you may have heard about, may have wondered about, or it will be new concepts for you.  We hope this provides valuable insights into RPA and gives you help on your journey.  If we are missing any term or concept you wish to learn about, please let us know and we will share with you our insights and keep this article updated with the feedback we receive.  Thank you in advance for sharing your RPA journey with us and please let us know how we can help.

Topics Covered:

What is Robotic Process Automation (RPA)?

Understanding Process vs. Task Automation

Common RPA Evaluation Criteria Used to Identify Good Automation Candidates

What tasks can digital workers perform?

Where is RPA used?

Benefits of RPA

What is Intelligent Process Automation (IPA)?

Attended vs. Unattended Automation

What is a Citizen Developer?

Creating a successful automation program

What to know about RPA tools

What else should I be aware of?

What is Robotic Process Automation (RPA)? 

In simple terms….Robotic Process Automation (RPA) is a computer software (aka “robot” or “Digital Worker”) that emulates the actions of a human interacting with a computer.  RPA is best used to perform any series of manual tasks that are repetitive, easily defined, and high volume.

Understanding Process vs. Task Automation 

  • A task is a single isolated step or function, like downloading a bank statement from a bank website. A business process consists of several tasks that work in conjunction to complete a process.  For example, a bank statement reconciliation process might have the steps of 1) download the bank statement from the bank website, 2) run an account balance report from the General Ledger, 3) perform a reconciliation between the two files, 4) Create a journal entry for any reconciling items found in the reconciliation.

Common RPA Evaluation Criteria Used to Identify Good Automation Candidates

Rule-Based Activities that can be described with well-defined rules
Easily Described Activities that can be easily articulated, explained, and documented
High Transaction Volumes Tasks that have a high number of volumes typically have many people performing the manual steps, therefore the process has an increased probability of a strong ROI
Low Exceptions Activities that have little variation from the standard process path will create a lower number of exceptions that require manual intervention
Stable and Well-Defined Processes Processes that are mature will typically have minimal volatility to account for in an automation
Minimal System Changes Stable and mature systems require less maintenance for ongoing automation support
Structured Data and Readable Electronic Inputs Structured, digital data is easier for the robot to read, extract, manipulate, and process in the subsequent process steps.  Unorganized data requires more effort and time to identify patterns and develop to structure (if possible), which erodes your ROI
People are Passionate About the Process Automating processes that team members don’t care about can take away from an automation program’s momentum.  Automating processes that people care about can create internal advocates that help promote the automation program benefits, which helps minimize employee concerns about the program and facilitates the identification of new process candidates to automate.

 

What tasks can digital workers perform?

  • Log into any application
  • Open emails and attachments
  • Read and extract data from documents, PDFs, emails, and forms
  • Enter data into applications
  • Copy and paste data
  • Move files and folders
  • Scrape data from a web page
  • Make calculations
  • Connect to system APIs
  • Read and write to databases
  • Run macros, execute formulas and lookups
  • Assemble reports from various data sources

 

Where is RPA used?

RPA can be applied to any process where a user is actively engaged in manual, repetitive, standardized tasks that engage a computer.

Finance Human Resources Legal Supply Chain Insurance
•    Process Invoices

•    Account Reconciliation

•    Reporting

•    Bank Statement Reconciliations

 •    On/Off-Boarding Employees

•    Payroll

•    User Profile Management

•    Provisioning/ Deprovisioning

 •    Bots document every action for traceability

•    Reduces risk of fraud and security exposure

•    Hardwires procedures in place for compliance

 •    Vendor Management

•    Process Work Orders

•    Bill of Materials

•    Item Setup in system

 •    Processing Claims

•    Policy Entry

•    Generating Reports

 

 

Benefits of RPA

Operational efficiencies across the enterprise

EFFICIENCY

  • Dramatically improves processing speeds
  • Improves accuracy of processing
  • Identifies anomalies quickly for human intervention

 

OPERATIONS

  • Easily scales up/down to meet demand
  • Collect processing data for analysis
  • Repatriate outsourced business processes
  • Let bots work in the slower, outdated legacy platforms
  • Pathway to advanced technology (e.g. OCR, NLP, ML, AI)

 

LABOR

  • Reduces FTEs in business processing
  • Allows human workers to do more creative, engaging value-added activities
  • Reduces department turnover
  • Digital workers can work 24 hours a day
  • Decreases recruitment and training cost

 

LEGAL

  • Capture transaction details for traceability and auditing
  • Reduces risk of fraud and data security exposure by minimizing human contact with data
  • Reduces risk of non-compliance by hardwiring processes in place

 

TECHNOLOGY

  • Less IT support needed to oversee bots than custom automation programs
  • A robust RPA system can deliver greater security, with less human Interference

 

Not all benefits are guaranteed.  Read our article to learn more about RPA benefits: RPA Benefits Exposed

What is Intelligent Process Automation (IPA)?

Intelligent automation is the combination of artificial intelligence (AI), machine learning, and robotic process automation that is used to create smart business processes and workflows that think, learn, and adapt on their own.   Technologies often used in intelligent automation are Desktop Process Automation (DPA), Robotic Process Automation (RPA), Computer Vision, Process Intelligence, Advanced Analytics, Machine Learning (ML), Natural Language Processing (NLP), and Cognitive Agents.

Attended vs. Unattended Automation

Below offers a simple explanation of Attended RPA and Unattended RPA, which are terms often used when discussing RPA processing.

Attended RPA Principles Unattended RPA
RPA automations that execute on the computer desktop under supervision of the human Simple explanation RPA automations that execute the automation on virtual desktops without human supervision
Started with human engagement How it works Started with a predefined schedule, event, or by a human action
Processes that include steps that require human intervention, like entering credentials into a system where is robot privileges are restricted. Best use Any process that can be automated and does not require human intervention or supervision to execute.
•      User passwords exposure can create risk and compliance issues

•      User training

•      Establishing and enforcing guidelines

•      User support

•      Monitoring user work

 Biggest Considerations •      Attended automation use cases might be overlooked because of the required user involvement

•      Not delivering “lower value” automations to the staff (e.g. report automation, daily downloads, etc)

What is a Citizen Developer?

Gartner defines a Citizen Developer as:

 

A citizen developer is an employee who creates application capabilities for consumption by themselves or others, using tools that are not actively forbidden by IT or business units. A citizen developer is a persona, not a title or targeted role. They report to a business unit or function other than IT.

 

All citizen developers are business technologists.  However, all business technologists are not necessarily citizen developers.  There is no required designation of proficiency or time allocation for citizen developers but they must be legal employees of an organization.

 

Citizen Developers can create risk for enterprises by having unskilled developers creating automations against core operational and financial systems that are not aligned with CoE standards.  These automations could expose passwords, enter invalid data, or create issues for IT by bogging down networks, etc.  We recommend having a policy in place to govern Citizen Developers by ensuring your operational risks are being monitored and accounted for.  That being said, Citizen Developers can help you scale the efficiency of your operations and can help you key team members help the teams they serve.

Creating a successful automation program

Achieving maximized value from your automation program is a balance between prioritizing business needs, highest ROI, and using building blocks for a tactical approach to delivery.  Every organization will have to decide which path is right for them, but having a strategy defined is critical for fastest path to value.

 

Business Needs vs. Building Blocks
Pros

•        Gives immediate satisfaction to business process owners

•        Accelerates the addressing of known issues / opportunities

Cons

•        Higher development costs compared to Building Blocks approach

•        More complexity (typically)

•        Bigger risk

•        Longer path to value

 

 Pros

•        Lower delivery costs

•        Less complexity

•        Reduces risk

•        Shorter path to value

•        Business process owners understand and appreciate path to value

Cons

•        Slower path to addressing notable opportunities

 

 

 

What to know about RPA tools

Fundamentally, all RPA tools are designed to automate business processes.  Some tools go about the automation differently, but they accomplish the same objectives.  Our point of view is that each tool architecture aligns better with certain organizations.  Meaning, tools like UiPath or Automation Anywhere are much more technical and require development skills when you get into more advanced automations, therefore an organization with a strong IT presence and an established software development lifecycle (SDLC) would be best suited.  Organizations that are more business led, with less IT presence and no established SDLC, tools like Blue Prism are most effective because there is less development required and most users with advanced Excel training can learn the tool.

 

Debugging an automation is a consideration for RPA tool platforms, but typically not a significant reason people will select an RPA tool.  Good architects can reduce the pain of debugging by separating out parts of an automation to minimize the difficulties with debugging an automation.

 

Cost is another consideration when selecting an RPA platform.  Our point of view is that RPA should not be expensive, so an expensive RPA platform takes away from the ROI on your automations.

 

Robot Management, Scalability, Reporting, and Monitoring are all factors in deciding which platform is right for you.

 

Security used to be a primary driver, but most platforms are developed with industry standards and compliance certification and best practices.

 

System and workforce integration must be a consideration because RPA through the user interface is prone to failure, so the ability to make API and database calls, et al, is critical for developing automations that are resilient and have maximized throughput.

 

Lastly, it is acceptable to have a multi-tool approach to automation.  If one tool works better for the enterprise and one tool is better and less expensive for task automation, it is an acceptable solution to have multiple tools to support automation.  The key is really making sure you can support your enterprise across both task and process automation with an effective ROI, from the initial build perspective, but also the total cost of ownership (TCO) with the ongoing expenses of support and robot licensing.

What else should I be aware of?

  • RPA is just a tool in your transformation toolbox, but not your only tool. Don’t get sucked into thinking RPA has to solve all of your processing problems.  Look at the opportunity and desired outcome, then work to determine the right technology.
  • Use building blocks to execute your automation program to take advantage of components built in earlier steps to reduce the risk and complexity of certain automations. The alternative approach is to automate the biggest opportunities, but then you are likely to be absorbing high risk and complexity, whereas the building block approach is not as flashy, but slow and steady wins the race.
  • Solution architects can make or break your automation program. Good solution architects will know how to leverage technology and not just follow what the business process owners are doing today.  Too often, we see many automations that follow the human path, which harden bad business processes and practices.  Architects will work to help the organization transform to create impactful automations that truly transform the way business processes are executed.
  • Be wary of automations that create data debt. Often, organizations buy into the illusion that certain processes will have a significant ROI, so they neglect to look at the process inputs to see if they are standardized to address a root cause issue with the data onboarding.  For example, AP invoice registration automations utilize vendor data, but typically vendor data is not governed and therefore vendor tables are known to have duplicates and incorrect information on the key vendors.  The bad vendor data causes everyone downstream to have to build their own mapping tables or workarounds for the inconsistent vendor data, whereas if the automation team worked on standardizing the vendor data onboarding to ensure it follows standards, then every process downstream that leverages the data is easier to automate with less variations and less hard coding.
  • Have a development methodology. Organizations that allow developers to follow their own paths will pay more for support in the long run than organizations that use a standardized methodology for development.  Standardized development is critical for accelerating troubleshooting and debugging in production.  Standardized development also speeds up quality control and development reviews because the reviewer knows what to expect and can read through the code faster than having to decipher how a developer coded their automation.

Process Automation Approach

Posted on by admin
Navigating the Automation Roadmap Blog Series

Your Automation Approach is Adding Data Debt to Your Organization!

Process automation positively impacts businesses in many ways, including the elimination of human processing errors, faster processing, 24×7 work time, and the scaling of capacity to flatten peak workloads.  With so much goodness, what could be bad?  How about the data debt that is piling up with each process automation?

With all the talk of robotic process automation (RPA), intelligent process automation (IPA), Hyperautomation, and other fancy terms, at the most basic level of a business process is the movement of data.  Data moves from Point A to Point B, PDF to system, system to system, system to report, etc.  The ultimate purpose of these data movements is to support data-driven decision making at various management levels.  If all goes well, captured data is mined for insights that improve the customer experience.

What is data debt?

Data debt is the cost that comes with a decision to choose fast solutions over the longer, more technically correct solution.  Sometimes these decisions are known at the time or origin, but they can also get established over time, unknowingly.  A relatable example of (inadvertent) data debt is the unstandardized practice for name and address entry.  Also related is the implementation of name and address entry standards after the process has matured, but a decision is made not to clean-up and align legacy data with the new standards.

In both situations, unstandardized name and address databases force downstream processes to contend with data variations.  Now, consider the processing impacts of name and address variations across Procurement, Accounts Payable, Accounts Receivable, Accounting, Sales and Marketing, and Reporting.  Human accommodations for these data deviations might not be fully understood or realized, because it is easy enough for an employee to perform a lookup and use historical processing knowledge to make the right selection.  The fact is, these accommodations are process deviations.

Process deviations across downstream processing create process waste and complexity, but also adds to the data debt that is unrealized by most organizations.

Fast forward to the future when you upgrade your name and address system to a new CRM system.  The organization is now confronted with the decision to standardize the data or convert as-is.  Standardizing the data increases the costs, time, and risk of the project, whereas converting as-is maintains (or increases) the data debt in the organization and perpetuates bad data practices.

How automation contributes to data debt

Automation backlogs consists of process candidates that are typically isolated functions (or tasks) within a larger process (e.g. invoice registration).  Decisions to “green light” or automate a process from the backlog are based on priority, projected returns on investment (e.g. hours, FTEs), and if the ‘gating’ qualifications have been met.  Most qualification guidelines include the identification of ‘known’ process deviations at a higher level (Levels 0 to 3), but it is easy to miss process deviations resulting from human accommodations to support bad data practices at the desktop level (Level 4).

To the trained and untrained eye, a business process might look to be standardized and consistent at the higher levels and even during a process (desktop) walk-through.  Automation development teams will define the process definition document and scope the business process based on the business team walk-through.  Depending on your development methodology (e.g. agile or waterfall), process variations caused by inconsistent data are identified during development reviews or during user acceptance testing (UAT).  Accommodating process variation within the current phase of the automation project might seem insignificant, but they will often add up and expand the scope of the project and in many cases increase the project duration.

Project scope creep and longer project times aside, the deeper issue is that process variations are often solved with hard-coding unstandardized data or by utilizing lookup tables, which really means the automation has now established the bad data practices as standards.

Data debt in practice

An example that exemplifies the data issues is starting with invoice registration for automation.  The AP invoice registration team receives an invoice and manually keys the invoice into the registration system.  Data entry usually entails straight entry and the utilization of field lookups to select and ‘connect’ the invoice with the vendor data and required internal coding structures.  From a top level, the process looks to be consistent and repetitive, but it is easy to miss that the processor is performing multiple lookups to identify the correct vendor or business unit entries for selection because of data inconsistencies.

It is commonplace for the lack of governance over vendor name and address entry or Purchase Order entry, therefore resulting with inconsistent data being keyed into supporting systems.  The issue this causes is that the information is a critical input for many downstream processes that will require process variations to support (subtle variations or more pronounced) the unstandardized data.

Eliminate data debt, create business agility , and transform your organization!

If you are thinking, “It is impossible and impractical to map out every process scenario,” then you are correct, but you are not addressing the root cause of the process variations, which are usually the result of inconsistent data entry standards.  To dig deeper into the issue, we need to examine where the unstandardized data originates from and address at the point of entry into the organization (where possible/practical).  From an automation perspective, this means that automating the process with the highest ROI might not be the right process to start with and you might need to start reengineering for automation further upstream to bring ‘real’ transformation to the organization.

We recommend examining all process inputs during the scoping phase of an automation, then ask if the inputs have a standardized process at their point of entry.  The Yes/No answer will help to determine if an investigation is required to examine the quality and consistency of the data.  Based on the outcome of the analysis you can determine how to best address for your organization.

Parting thought

Transformation of an organization usually does not come from the shiny object in front of you but comes from establishing the right practices to guide an aligned organization.  It is also important to note that transformation occurs though many available tools (levers to pull), such as system upgrades, reengineering, expansion of system functionality/parameters, or automation.  Too often, people want to believe automation is the only answer for transformation, but it highlights an organization that is not aligned on transformation initiatives.

In future articles we will address the important of an “aligned organization” for transformation, but for now I hope this article has been informative and thought provoking.

Please reach out on automation@vigilant-inc.com. We would appreciate hearing your feedback or having discussions to learn how we can help support your data governance implementation and execution, or automation initiatives.  Thank you for reading.

Author:

Joshua Gotlieb

Intelligent Automation Practice Director, Vigilant Technologies