Robotics Process Automation (RPA)

Robotics Process Automation (RPA) is the latest in software design to take manual work off our hands. RPA can operate at the application level, emulating a human, pointing-and-clicking or at the machine code level dealing with transferring data without a visual interface. Consider this example semi-automate by RPA

Wrote, standard tasks are given to the bot, while human retains the “thinking tasks”.

The benefits from RPA

Cost reduction

If the bots costs less to acquire and develop that the labor it displaces

Customer satisfaction

If customer value immediate processing of their requests or assistance with self-service

Employee satisfaction

If the bot can take over mundane,
repetitive tasks

Bots work well on process that

Are manual and repetitive

Have few variations on the inputs, process steps, and output

Have a high volume

Getting Your First Bot

How much foes a bot cost? That is a usual question. Generally, getting bot available requires

Documented process steps, variations

Example of inputs and outputs

Bot logins/access to the applications involved

Licensing fees for bot

User licenses for bot

Bot management and maintenance

Now, software companies typically focus on the licensing, maintenance, and development costs. Businesses have to consider all the costs. This can fully cost anywhere between $10k and $20k per bot depending on complexity, dispatch functionality, use of a bot library. The rule of thumb that we typically use is that if the bot can save one Full Time Equivalent (2,000 hours per year), in one department, the bots is worth pursuing. Partial FTEs make or small tasks spread across a large number of people (e.g. timesheet ecntry) are hard to see benefits from.

RPA software can be one bot on a local installation supporting one user. In the early days, the user can either initiate when the bot works across multiple tasks or the bot can work to a calendar, automatically supporting one task. These days all the software companies have a “dispatcher”  module, which can identify when processes need to run and assign bot from a pool to a process. The bot returns to the pool when the process or task is done. Pooling the tasks makes for few bot, better utilized, costing less.

Projects and Programs

At HMC we have experience setting up Program to deliver multiple bot, as well methods to lead bot through its lifecycle

Bot Project Methodology

1. Identify

  • Identify Opportunities

  • Capture basic process on video

  • Summarize Opportunities

  • Score Benefit/Complexity

  • Decide to proceed to Discovery

2. Discover

  • Document flow and timing

  • Train Business and Development staff

  • Capture Process Details

  • Define Variations

  • Define process improvement potential

  • Develop preliminary solution architecture

  • Estimate ROI

  • Get Customer Approval

3. Develop

  • Project Preparation (hours/timeline)

  • Define Key Business Requirements

  • Define RPA Scope

  • Detailed As-Is Documentation; To-be design

  • Develop Bot

  • Run Unit Testing

  • Run UAT

4. Deploy

  • Plan Conversion

  • Communicate to staff

  • Train Users

  • Go live

5. Realize Benefits

  • Track satisfaction, defects, hours or cycle time

It is much like other IT configuration and deployment processes, but a couple of key distinctions:

1. The timeline should be much compressed, weeks, not months.

2. There are more dependencies on outside systems and processes (e.g. at customers/suppliers)

Bot Program Methodology

1. Build bot portfolio

  • Identify Opportunities

  • Approve scope, resources; set timing against other projects

2. Oversee projects

  • Track milestones

  • Sponsor decisions

  • Assist in risk management

  • Track Benefits

3. Build delivery capabilities

  • Capacity plan licenses, hardware, support

  • Develop support for operational bots (troubleshooting, upgrades, access, etc.)

  • Establish Bot library, Project Body of Knowledge

  • Build skills to support projects and operations

Lessons Learned

Some, seemingly obvious things that you have to be aware to deploy and sustain bots

1. Know all the variations

The bot is a simple machine, it can only do what it is told. Variations that experienced humans will learn to do instinctively, are often not documented, e.g. know that an order from ABC co., shows up as ABC, inc. in the order management system.

2. Find the process holes early

Humans most important role in mundane, repetitive processes is dealing with slight variation in the data. Some real examples:

  • An order that comes in from Slage Industries is in the customer master under the parent, United Industries.

  • A part number is a six-pack for independent retailers, but a singe for mass retailers.

  • A domestic customer cannot buy a part built for European power.

3. Syncing calendars

Bot operations have to be synced with IT updates. For example, we can’t expect the bot to run when the ERP system is refreshing. Any system updates have to be tested against the bot. A client had a bot fail because the customer website it was accessing changed color pallets.

4. Bot categories

Two categories of bots are “unattended” and “attended”. Unattended bots start themselves and run an entire process, including all variations. Attended bots interface with a human, who starts, check QCs, and/or deal with exceptions. Unattended bot are best very basic transactions, but be advised they require more software to do the dispatching.

5. Dealing with variation costs money

Use the 80/20 rule for the initial deployment of what is scope for the bot. Will it process 80% of transaction types or put the less frequent items into queue? Will it be self-repairing, fixing data errors or adjusting to system changes? Our recommendation is to start basic, then add more functionality or change the process to eliminate variations or failures as the ROI warrants.